Evolving Your Lakehouse for the AI Era
What actually changes in a Microsoft Fabric architecture, and where agents tend to break.
With Fabric Data Agents now generally available, the question for data engineering teams has shifted from “what can agents do?” to “what does our data layer need to look like for agents to work reliably?” The answer touches every layer of the architecture: ingestion, modeling, the semantic layer, and governance. This article maps those changes concretely, from medallion lakehouse design through Prep for AI configuration, and covers where agent deployments succeed and where they break down.
For years we built reports for one purpose: a human reading a Power BI dashboard and deciding what to do next. That approach works, and it continues to deliver value. The next step is structuring the same data so an AI agent can answer questions in plain language and trigger actions within rules you define.
“Agent-ready” is an evolution, not a switch. It changes the requirements at every layer, from ingestion and modeling through to the semantic layer and governance, and it breaks in predictable ways when the foundation has not been prepared. This piece covers both sides: what to build and what to watch for.
Agent-Ready Lakehouse Architecture on Microsoft Fabric
Read it left to right: raw data comes in on the left, gets refined through the medallion layers in OneLake, picks up business meaning in the semantic layer, and is then served to people and agents on the right. Governance spans every layer rather than appearing as a final step.
Figure 1: Agent-ready lakehouse reference architecture on Microsoft Fabric.
What Changes at Each Layer: Ingestion, Modeling, Semantic, and Governance
Ingestion: An agent is only as reliable as the freshest data it can reach. The ingestion layer must be managed for freshness as much as volume, and the deciding question is how fresh the data needs to be, not which tool to use. Batch handles anything that can tolerate a delay. Real time is reserved for sources where seconds matter. The principle is simple let the freshness requirement pick the route, not the appeal of the tool. Both routes land in Bronze under identical conventions, with every record stamped with its source, load timestamp, and watermark, because the goal is to ensure an agent never answers confidently from stale data it believes is fresh. The streaming path adds deduplication and idempotent writes so replays don’t create duplicates, while schema drift is quarantined in Bronze rather than allowed to break Silver. Finally, ingestion lag is monitored per source with alerts on any SLA breach because the failure this layer exists to prevent is an agent answering confidently from stale data it believes is fresh.
Modeling. A human can interpret messy structure in a dashboard. An agent generates queries from the model structure directly, so clarity at this layer is essential. Keep the medallion flow (Bronze → Silver → Gold) strict, and shape Gold as a curated collection of dimension and fact tables and views built for analytics. Name every table and column in business-readable terms, because those names are the agent’s first clue about meaning. Keep each fact table at one consistent grain, and standardize keys so joins are unambiguous. Flat, wide, or pivoted tables that work in a dashboard will confuse an agent’s query generator. Use dimensional structure instead. Stop at the physical layer here: relationships, hierarchies, and measures belong in the semantic model, covered next.
Semantic layer. This is the biggest change. The Power BI semantic model becomes the data contract between your business meaning and the agent: a formal, agreed definition of what your data means, which both sides depend on. The next section covers this in detail. Direct Lake lets the model read Gold tables at import speed, so this contract sits directly on the curated tables you shaped in the modeling layer.
Governance. The governance question expands from “who can open this report” to “what can this agent see, and on whose behalf.” Fabric Data Agents are read-only and run under the asking user’s Entra ID identity, so they automatically respect row-level security (RLS), which filters which rows a user can see, column-level security (CLS), which hides sensitive columns entirely, and Microsoft Purview labels. This is what makes agents safe to deploy: the agent can never see more than the person asking the question is already allowed to see.
Microsoft Fabric Components for Agent-Ready Design
A handful of Fabric components do the heavy lifting. Here is the role each one plays in an agent-ready design:
| Component | Role in an agent-ready design |
| OneLake | Single logical lake. One open-format copy of the data that every engine and agent reads. This is the agent’s source of truth. |
| Medallion Lakehouse | Bronze / Silver / Gold quality tiers. Agents read Gold; raw stays isolated in Bronze. |
| Semantic Model + Direct Lake | Defines measures, relationships, business logic; reads Gold tables at import speed. The agent generates DAX against it. |
| Prep for AI | The enrichment surface that makes a model AI-ready: AI data schema, descriptions, synonyms, AI instructions, verified answers. |
| Fabric Data Agent | Standalone, read-only artifact (generally available). Turns natural language into DAX / SQL / KQL across up to 5 sources via an orchestrator. |
| Activator (Reflex) | No-code rules engine. Watches data and fires a pre-defined action when a condition is met. |
| Microsoft Purview | Catalog, lineage, sensitivity labels the agent honors at query time. |
Enriching the Semantic Model with Prep for AI
When a Data Agent answers against a semantic model, it generates DAX using almost nothing but the model’s metadata and its Prep for AI configuration. It does not know your business. A column called dt1 with no description is invisible to it. Prep for AI gives you four concrete levers to fix that.
Descriptions put plain-language meaning on every object:
| Object | Weak (agent struggles) | Enriched (agent succeeds) |
| Measure: Net Sales | (no description) | “Total sales after returns and discounts. Use this, not Gross Sales, for revenue questions.” |
| Column: GM_Pct | (no description) | “Gross margin % = (Revenue – COGS) / Revenue, expressed as a value from 0 to 1.” |
| Table: DimCustomer | (no description) | “One row per customer. Join to FactSales on CustomerKey.” |
Synonyms matter because people ask for the same measure in different words “revenue,” “turnover,” “top line.” Map all of them to the actual field, Net Sales, so the agent recognizes what the user means. When that mapping is missing, the agent either cannot find the field or guesses at the wrong one.
AI data schema lets you expose only the tables and measures the agent actually needs plus their dependencies rather than all 200 columns. This keeps the agent focused on the fields that matter. Note that this selection is not automatically carried over: when you later add the model to the agent, you need to select the same tables again.
AI instructions & verified answers round it out. Instructions clarify business terms and split the model into domains, while verified answers pin approved responses to specific questions so they aren’t re-generated each time.
The metadata principle
The quality of an agent’s answer is directly proportional to how well the model describes itself. Enrichment is the build step, not a finishing touch. And because Copilot uses the same Prep for AI configuration, the effort pays off twice.
How Fabric Data Agents and Activator Work Together
This line gets overstated, and it matters for trust. The agent does not decide on its own to act in the world. Two separate things happen:
- The Data Agent answers. It is read-only, meaning it generates only “read” queries and never creates, updates, or deletes data. It retrieves and explains, full stop.
- Activator acts, but only on rules you define. You write an explicit IF…THEN rule, for example “IF stock < reorder point, THEN post to Teams and start the PO pipeline.” Activator watches the data continuously and fires the action only when that condition is met.
The honest framing
The accurate framing: we defined a set of rules, and the system follows them, triggering the pre-approved action when a condition is met. The autonomy is in the execution. The judgment stays with people. Showing stakeholders that every action is an auditable, human-authored rule is usually what turns a “no” into a “yes.”
Dashboard-Ready vs. Agent-Ready: What Changes
Here’s the shift in concrete terms:
| Dimension | Dashboard-Ready | Agent-Ready |
| Consumer | A human reading a report | A human and an AI agent, in plain language |
| Ingestion | Scheduled batch | Batch + streaming where freshness matters |
| Question → answer | Analyst builds a visual / writes DAX | User asks in English; agent generates the query |
| Real-time insight | “Last quarter sales were down 8%” | “North region just dropped below threshold” |
| Response to a problem | Someone notices the chart, then acts | Activator rule fires a pre-defined action |
| Governance | Report-level access | Identity-aware, read-only, honoring RLS/CLS |
A concrete example
Dashboard-ready: A manager opens a report on Monday, sees that North-region sales fell 12% last week, and emails the team. Real insight, but it arrives late, and only when someone is looking.
Agent-ready: The same manager asks the agent in Teams “why did North revenue drop last week?” and gets a grounded answer in seconds. Separately, an Activator rule already fired the moment the data crossed the threshold. The insight arrived on its own.
What Agent Deployments Require to Succeed
Agent deployments succeed or break based on what sits underneath them. The patterns are predictable, and recognizing them early is what separates a real deployment from a demo.
- Metadata drives accuracy. Descriptions and synonyms are how the agent maps questions to the right field. When they are missing, the agent maps to the wrong field, or to none at all, and often answers anyway. A confident wrong answer erodes trust faster than no answer at all.
- Governance must be in place before the agent goes live. RLS, CLS, and sensitivity labels are what an identity-aware agent enforces. When they are configured, the agent respects every boundary automatically. When they are not, there is nothing to enforce.
- Scope: aggregation, not reasoning. Data Agents handle straightforward, aggregation-style questions well. An agent can comfortably answer “What were sales last quarter?” Complex root-cause analysis or predictive modeling (“Why are margins shrinking, and what should our three-year play be?”) still belongs to a human.
- Operational boundaries. An agent can query up to 5 sources and needs Fabric capacity (F2+ / P1). Direct Lake can fall back to DirectQuery on complex queries. After a model change, a refresh is required before the agent picks up the new configuration. A deployment can look current while the agent is still reading the previous version.
Building an Agent-Ready Foundation on Microsoft Fabric
Moving from dashboard-ready to agent-ready touches ingestion, modeling, the semantic layer, and governance all at once. The components are real and available in Fabric today: OneLake, a Direct Lake semantic model, Prep for AI, the Data Agent, and Activator.
The lesson underneath is simple. The technology amplifies the quality of the foundation in both directions. A well-modeled, well-governed lakehouse with strong metadata produces an agent that earns trust. The agent is the last 10% of the work. The foundation is the other 90.
So consider your own model. Is it agent-ready? And if not, what will it take to get there?
If you are designing an agent-ready architecture on Microsoft Fabric, enriching semantic models for Copilot and Data Agents, or building governance into your lakehouse from the ground up, Data Crafters works with data engineering and analytics teams on exactly this pattern. We can help you build the foundation.
