Architecture9 min read
Where the Twin fits with Microsoft Fabric
Fabric stores and serves data; it cannot host the Twin. Today the Twin reads Fabric tables read-only. A OneLake replica and an Azure target are designed.
Mercury Labs
Fabric stores and serves data; it cannot host the Twin. Today the Twin reads Fabric tables read-only. A OneLake replica and an Azure target are designed.
A governed AI platform cannot run "on" Microsoft Fabric in the sense of living inside it, because Fabric is a data platform, not an application platform. What it can do is sit beside Fabric and work with it. The Company Twin can now read a Fabric lakehouse or warehouse directly, read-only, through its SQL analytics endpoint, so far tested only on our staging server. We have also designed, but not yet run, a replica of the Twin's own data layer in OneLake, and a deployment of the whole Twin into a customer's Azure subscription so that Fabric mirrors its database natively.
Microsoft Fabric is Microsoft's software-as-a-service analytics platform: one store (OneLake, holding open Delta tables), with data engineering, warehousing, real-time analytics and Power BI built on top. It runs pipelines, notebooks and queries. It does not host containers, long-running services or a Postgres database.
If your organisation has standardised on Fabric and Power BI, the question you will be asked about any AI platform is how it fits with the estate you already have. This is our honest answer for the Company Twin: what works now, what is designed and what we would not do.
The Twin is a set of long-running services: an agent runtime that holds runs open for minutes or hours and streams their progress; a Rust graph engine that keeps each organisation's semantic model in memory and answers queries in milliseconds; a Postgres database that holds sessions, runs, connectors, channels and the access ledger; a model gateway; and connectors that ingest dozens of SaaS sources. Each customer runs that stack on a server of its own (see one customer per server).
Fabric's compute is built for data work: pipelines, Spark notebooks, short-lived user data functions and SQL over Delta tables. Its SQL database is SQL Server, not Postgres, so every migration and query would have to be rewritten. None of its compute is a place to keep a service running. So "the Twin on Fabric" can mean three different things, and only two of them are worth doing.
| Option | When to use | Trade-offs |
|---|---|---|
| A. A data replica in OneLake | You want the Twin's governed data in Fabric beside everything else, for Power BI, notebooks and other tools | Designed, not yet run. The Twin still runs on its own server; Fabric holds a governed copy |
| B. The Twin in your Azure subscription | You want the platform inside your own cloud boundary, next to your Fabric capacity | Planned. Same images and code; Fabric mirrors the Twin's Postgres natively |
| C. A rebuild from Fabric-native parts | Only if every component must be a Fabric item | Not recommended. Loses the agent runtime, the access ledger, certified answers and the clients that use them |
The Twin's Azure SQL database connector accepts a Fabric lakehouse or warehouse SQL analytics endpoint as a source. An organisation admin adds the connection and chooses the exact tables or views the Twin may read; members then need a data-role grant for each relation before their agents can query it. The Twin reads, never writes, and that is enforced at three levels.
Making this work taught us something that is easy to miss. A Fabric SQL endpoint answers every login with a TDS redirect to a regional gateway, and our connector refused all redirects as a security rule. We changed it to follow at most one redirect, and only to a host, port and address that the same destination rules approve, with TLS checked against the host it actually connected to. A second redirect, or one to anywhere unapproved, is refused.
We shipped this in November 2026 and tested it on our staging server against a test lakehouse. One limit remains: the graph engine's own database reader does not yet follow redirects, so Fabric tables are read through the agents' live database tools rather than held in the graph with certified figures. Reading your tables is also not the same as agreeing what they mean, a distinction we explain in a connector is not context.
Reading Fabric covers organisations whose data already lives there. The opposite direction matters too: putting the Twin's governed data (its synced sources, entity layer, governed views and channel records) into OneLake, so Power BI, notebooks and other Fabric tools can use it with the same definitions the Twin's agents use. This is a design. We have not yet run it on our own organisation.
Carefully, and not completely, and it is better to be explicit about which part does not. Inside the Twin, every read an agent or a person makes is checked against their data roles and recorded on the organisation's access ledger before the answer is returned. A Delta table in OneLake cannot reproduce that behaviour, and we would not pretend it can.
| Twin component | Nearest Fabric equivalent | What we would do |
|---|---|---|
| Postgres: canonical state and the access ledger | Mirrored Delta tables; Fabric SQL database is SQL Server | Replicate the governed data; keep the database and ledger in Postgres |
| Connectors and their change history | Data Factory pipelines and Dataflows | Keep ours, which cover the sources that matter; their output is what mirrors |
| Graph engine and certified answers | Direct Lake model, Fabric data agents | Generate the Direct Lake model from the Twin's model; certified answers stay in the Twin |
| Agent runtime and Python sandbox | Notebooks and user data functions (batch or short-lived) | Run in Azure beside Fabric, not in it |
| Data roles | OneLake security: row and column rules | Map each role onto rules per curated view |
| App, desktop, CLI and MCP clients | A Fabric workload built with the Workload Development Kit | Later: a shell so the Twin opens inside Fabric |
So the data roles map onto OneLake's row and column security per curated view: amounts masked for anyone outside finance, for example. The ledger stays where the reads happen. If you query the replica directly, Fabric's own auditing applies, not the Twin's.
This is the answer to "we want it inside our own cloud", and it is a deployment target rather than a new product. The same release images that run on our servers would run on an Azure virtual machine, in the region you choose, with:
Everything else would be unchanged: the same images pinned by digest, the same release path and the same checks that prove what is serving. That matters for assurance, because the code you would run is the code our other customers run.
One comparison we do want to run, once the replica exists: Fabric's data agents against the Twin's certified answers on the same data and questions. The evidence would be useful whichever way it falls.
For a Fabric-centric organisation, we would start with the path that works today: connect the Twin to your curated lakehouse or warehouse tables as a read-only Viewer, agree the definitions of the measures your teams argue about, and let agents answer questions over them. That gives you value without moving any data. If the problem is reporting that disagrees across systems, the pattern in the operational reporting disconnect applies.
If you then want the Twin's governed data and definitions inside Fabric for Power BI, the replica is the next step; if you want the whole platform inside your own Azure boundary, the Azure target is. We would scope either against your security model rather than ours. For how we compare retrieval approaches over data like this, see RAG versus agentic retrieval, and for keeping the model layer independent of any one cloud, see multi-model AI without provider lock-in.
The Twin can work beside your Fabric estate, reading the tables you approve and nothing more. See the Company Twin →