Who Is Your Semantic Model Actually For?
A Power BI semantic model in Microsoft Fabric can be tuned for self-service exploration, certified analytics, or AI agents, but not all three at once. Six dimensions pull the model in different directions, and the one-source-three-models pattern resolves the conflict.
TL;DR
A semantic model, the layer that turns raw tables into the friendly measures and names people query, can be optimized for exactly one of three consumers: a business user exploring, a certified enterprise metric layer, or an AI agent querying it. These three jobs pull the same model in opposite directions, so one build cannot serve all three well.
The short version:
- Self-service wants a wide schema, light metadata, and fast cached refresh. It optimizes for breadth: maximize what a user can ask.
- Enterprise analytics wants a narrow, certified schema and locked-down editing. It optimizes for precision: maximize what a user can trust.
- AI agents want the narrowest schema and the heaviest machine-readable metadata. They optimize for programmatic clarity: maximize what the machine understands.
- The three collide on six dimensions: schema width, metadata, refresh mode, security, capacity, and cost.
- The fix keeps one governed source and projects three thin models from it, with security and measure logic defined once.
The one-model dream just broke
A race car, a family van, and a cargo truck are all "a vehicle." Nobody tries to build a single vehicle that is all three at once, because the thing that makes a race car fast is the same thing that makes it useless for hauling a family or a pallet. Semantic models work the same way, and for about fifteen years most of us got away with pretending they did not.
The advice was always "build one great model." One set of certified measures, one home for the truth, everyone points at it. That advice held right up until a third kind of consumer arrived.
The story is familiar. Someone builds a semantic model and it works: dashboards are fast, users trust the numbers, the CFO self-serves without raising a ticket. Then, in a single quarter, the BI team wants to certify it as the official enterprise metric layer and the AI team wants to point an agent at it. The instinct is always the same: "it already has the measures, so let's use it for everything."
That instinct is now wrong, and the damage stays hidden until you are troubleshooting query contention at month-end while an agent hands back 200-column answers that burn tokens faster than your cloud credits. Self-service, enterprise analytics, and AI consumption are three jobs pulling one model three incompatible ways at once. AI did not add a feature to your semantic model. It added a consumer, and that consumer wants nearly the opposite of the two you already serve.
Three jobs, three sets of demands
Most teams know the first two jobs by instinct. The third is new, and it changes the arithmetic. Think of the three as corners of a triangle, the semantic-model trilemma: a single model can sit near one corner only by moving away from the other two. Each corner wants something different.
A model has one center of gravity. Pull it toward any corner and the other two degrade.
Job 1: Self-service, the explore-anything model
Self-service exists so a business user can drag columns into a chart and get a correct answer without asking anyone.
- Schema (the tables and fields on offer): Wide. You cannot predict what someone will ask, so you expose everything that is safe to expose. A large surface area is a feature here, not a smell.
- Metadata (the names and descriptions): Light. Friendly names and folders are enough, because a human hovers, clicks, and infers the rest.
- Refresh: Import, meaning a cached copy refreshed on a schedule. The promise is instant rendering. Users tolerate yesterday's data, not a spinner.
- Security: Row-level security, the rules that decide which rows each person is allowed to see, scoped to the individual user.
- Cost: Dominated by storage plus peak concurrency. Many people asking simple questions at the same time.
Job 2: Enterprise analytics, the certified-metrics model
This model exists so that when two dashboards say "Revenue," they mean the same number. The job is trust at scale.
- Schema: Narrow. Every measure is defined, approved, and documented, so adding a column is a change request, not a drag-and-drop.
- Metadata: Specification-grade. "Revenue" means net of returns after 30 days, matching the definition finance signed off on.
- Refresh: Set by the service-level agreement. Scheduled for daily dashboards, or live (queried straight from the source) for near-real-time views.
- Security: The same row-level security, plus restricted editing rights, because letting anyone author a measure defeats the point of one agreed definition.
- Cost: Dominated by compute, and it is predictable. Known dashboards, known schedules, planned in advance.
Job 3: AI agents, the machine-readable model
An AI agent, software that answers a plain-language question by writing and running its own queries against your model, is the new third consumer. Its needs diverge from the first two on almost every axis.
- Schema: Narrowest and purpose-built. An agent does not browse, it queries with intent. Every extra column is a token it pays for and a wrong-answer risk when a name is close to, but not exactly, the concept asked for. That often means several narrow models rather than one wide one.
- Metadata: The heaviest of the three, and pointed a different way. A person reads "Revenue YTD" and fills in the meaning; a language model has nothing to go on unless you wrote the descriptions, synonyms, and instructions for the ambiguous cases.
- Refresh: Live queries against the source become viable, because an agent has no sub-second render deadline, and it fires more queries per question as it reasons step by step.
- Security: This is where teams most often slip, and it comes down to whose identity actually reaches the data. A Microsoft Fabric Data Agent queries as the person who asked, so row-level and column-level security apply. But a raw service principal, an application's own identity with no user attached, cannot be placed in a security role, so unless the caller passes the user's identity along, it sees every row. The failure is never "an agent touched the data." It is an app that authenticates as itself and forgets to carry the user's identity through to the model.
- Cost: Bursty on the query side, smoothed on the AI side. An agent can fire many queries in seconds on the same compute your dashboards use, so query concurrency spikes, but its language-model work is billed as background jobs spread over 24 hours, so that meter rarely does.
Where the three jobs collide
Line the three jobs up against the dimensions they each care about, and the trilemma stops being abstract. Every row is a standoff.
| Dimension | Self-service wants | Analytics wants | AI wants |
|---|---|---|---|
| Schema width | Wide, expose everything | Narrow, certified measures | Narrowest, minimum surface |
| Metadata depth | Light, humans infer | Specification-grade | Rich, machine-readable |
| Refresh mode | Cached for speed | Whatever the SLA needs | Live queries, no deadline |
| Security | Per-user filtering | Per-user, locked editing | Depends on whose identity calls |
| Capacity | Unpredictable, simple | Predictable, planned | Bursty queries, smoothed AI |
| Cost driver | Storage plus concurrency | Compute plus refresh | Concurrency plus smoothed tokens |
| Failure mode | "I can't find the column" | "Two dashboards disagree" | "The agent made up a number" |
Read down any column and you are reading a set of choices the next column rejects. A wide model that delights a human analyst forces an agent to wade through a 200-column schema and turns near-duplicate names like Amt, Amt2, and Amount (Old) into wrong-answer traps. Narrow that same model to the thirty fields an agent needs, and the analyst can no longer find the columns they have relied on for years.
The pattern: one source, three projections
Stop trying to unify the model. Unify the source instead.
The models differ only in what they expose (see the schema-width bars), how they describe it, and how they deploy.
Layer 1, one governed source. A single lakehouse or warehouse, the governed storage layer where your certified tables live, that all three models read from. Certified, versioned, tested. One home for the truth.
Layer 2, three purpose-built models. Each tuned to its job, as the diagram shows. They are thin projections of the same source, not three separate rebuilds.
Layer 3, shared governance. Security rules and measure logic are defined once, in the source or a shared calculation layer, and every model inherits them. You define "Revenue" one time, and each model exposes the slice it needs.
This is not three times the work. The models share most of their logic, and "one source, three projections" costs far less than debugging one model that disappoints three audiences at once.
The cost question
The pushback is always the same: "three models means three times the bill." It does not, because the three workloads do not stack the way that fear assumes. Self-service is storage-heavy and compute-light. Analytics is compute-heavy and predictable. AI is query-bursty and storage-light.
Put all three on one capacity, the pool of compute you rent, and you pay for the peak of peaks: a month-end refresh, a board-prep spike, and an agent burst all landing at the same moment. Separate them, right-size each, and the total is often lower. Not always, so do the math on your own workload.
When to actually split
One model is fine when you have one consumer. Most teams start there, and they should. You split when the strain starts to show:
- An agent shares the model your dashboards use, and nobody can explain the capacity behavior at month-end.
- Users call the model "too narrow" after you tuned it for AI, or an agent invents a measure on the model you tuned for people.
- Your security works on dashboards, but you cannot prove it holds through the agent's identity path.
- Two teams are fighting over refresh schedules, schema changes, or editing rights on the same model.
Go all the way to the three-layer pattern when all three consumers are live in production, when capacity cost is worth right-sizing per workload, and when governance demands proof that one measure definition reaches every surface.
The bigger shift
None of this is really about Microsoft Fabric. Fabric is just where the tension shows up first, because it puts self-service, certified analytics, and AI agents on the same semantic layer. The same split is coming to every stack that lets a language model read its metrics.
The deeper change is what a semantic model now is. It used to be a reporting convenience, a friendly face over the warehouse. It is becoming the contract between your business and every machine that reads your data, and a contract cannot hold three incompatible signatures at once.
That reframes ownership, too. "Who owns the semantic model" used to have one answer: the BI team. Once an agent is a first-class consumer, the model is also an AI surface, and whoever is accountable for the AI's answers has a stake in how it is built. The three jobs are not only three schemas. They are three teams, three budgets, and three definitions of "correct" that your architecture now has to hold at the same time.
So, who is your semantic model actually for? If the honest answer is "everyone," it is quietly for no one. One model, three jobs, and no chance it is optimal for all of them. That is not a failure of the model. It is a sign that your semantic layer has grown up, and your architecture should grow with it.