Copilot Studio + Microsoft Fabric: building an agent that reads your data lake
Microsoft Fabric puts your data in OneLake; Copilot Studio lets you build agents on top of it. Here is how the two connect — grounding, the SQL endpoint, Fabric data agents — and the traps to avoid.
- Copilot Studio
- Microsoft Fabric
- OneLake
- AI Agents
- Azure
“Can we just chat with our data?” is the request every data team now hears weekly. Microsoft’s answer stitches two products together: Fabric holds the data, Copilot Studio builds the agent that talks to it. The demo is magic. The production version has sharp edges. Here is how the pieces actually fit — and where teams cut themselves.
The pieces: Fabric, OneLake, Copilot Studio
Microsoft Fabric is a SaaS analytics platform that bundles data engineering, warehousing, real-time analytics and Power BI. OneLake is its single, tenant-wide data lake — think “OneDrive for data” — built on ADLS Gen2 and, crucially, storing everything as open Delta-Parquet. Same format as the Databricks lakehouse, which is not a coincidence: the industry has largely agreed on Delta and Iceberg as the open table layer.
Copilot Studio is Microsoft’s low-code platform for building agents — the descendant of Power Virtual Agents. You give an agent instructions, knowledge sources, and actions, and it answers using generative AI. The question is how you point that agent at the lake.
Where the data lives: OneLake and the SQL endpoint
A Fabric lakehouse or warehouse exposes its Delta tables two ways an agent can use. The SQL analytics endpoint is a read-only T-SQL surface over the tables — anything that speaks SQL can query it. The semantic model sits above that: named measures, relationships and business logic, queryable in Direct Lake mode, which reads Parquet straight from OneLake without importing or caching a second copy. Shortcuts let OneLake reference data sitting in S3 or another ADLS account without moving it, so “your data lake” can span clouds.
The lesson: an agent grounded on a well-built semantic model is far more reliable than one pointed at raw tables, because the model encodes what a “customer” or “revenue” actually means.
Three ways to ground an agent on your lake
- Fabric data agent (the native path). Fabric has its own AI agent — previously “AI Skills” — that you build over a lakehouse, warehouse or semantic model. It translates natural language to queries against your data, and you can add it into Copilot Studio as a connected knowledge source. This is the shortest route and the one Microsoft is investing in.
- Copilot Studio knowledge over a semantic model. Point the agent at a Power BI semantic model as a knowledge source. Good for question-answering over defined measures; weaker for open-ended row-level lookups.
- Custom grounding. Use Power Automate or a custom connector to hit the SQL endpoint, or wire up Azure OpenAI “on your data”. Maximum control, maximum plumbing — you own retrieval, prompt construction and result shaping.
A minimal build
The path that works most reliably, end to end:
- Land data in a Fabric lakehouse and shape a clean gold layer — the medallion discipline applies here exactly as it does in Databricks.
- Build a small semantic model with named measures and relationships. This is where accuracy is won or lost.
- Create a Fabric data agent over that model and test its generated queries against known answers.
- In Copilot Studio, create an agent, add the Fabric data agent as knowledge, write tight instructions, and publish to Teams or the web.
Security is the whole game
The failure that ends careers is an agent that cheerfully returns rows a user should never see. Get this right before you ship:
- Identity flows through. Prefer the agent querying on behalf of the signed-in user (Entra ID), not a fixed service principal with god-mode access.
- Row-level and column-level security live in the semantic model and the lakehouse — enforce them there, not in the prompt. A prompt is not an access-control boundary.
- Least privilege on OneLake. Shortcuts and workspace roles decide what the agent can even reach.
Where it breaks
- Hallucinated or wrong SQL. Natural-language-to-query is probabilistic. Without a semantic model constraining it, the agent invents plausible-but-wrong aggregations. Always validate against a golden question set.
- Direct Lake falls back to DirectQuery when a model gets too large or complex, and latency quietly degrades. Watch for it.
- Cost creep. Fabric capacity units plus generative calls add up. Meter it from day one.
Copilot Studio over Fabric is the fastest way to give non-technical users a real conversation with governed data — if you invest in the semantic model and treat security as a data-layer problem, not a prompt. When your agents outgrow low-code and you need to own the model and the loop, the next piece looks at the open agentic stack — Hermes and NVIDIA Nemotron.
Was this useful?