Point your Fabric data agent at the semantic model, not the gold lakehouse
The gold layer is where your clean data lives. The semantic model is where your meaning lives. An agent that answers business questions needs the meaning.
Microsoft Fabric lets you attach a data agent to a few different things. A lakehouse. A warehouse. A KQL database. A Power BI semantic model. The first instinct for a lot of teams is to point the agent straight at the gold layer in the lakehouse, because that is where the clean, modeled data already sits. I think that is usually the wrong call. In most cases the semantic model is the better home for the agent. Here is why.
Your measures are already built and tested
A gold table is a pile of columns. Revenue, cost, quantity, a date, a few keys. Correct, but raw. The logic that turns those columns into a number a person actually trusts lives somewhere else. It lives in the measures.
Point an agent at the lakehouse and the agent has to write that logic itself. It decides how to sum revenue, how to handle returns, how to deal with currency, how to treat a partial month. It will get some of that wrong, and it will get it wrong in ways that look right. Point the agent at the semantic model instead and it calls measures your BI team already wrote and tested. Year over year growth is a measure. Net margin is a measure. The hard thinking is done, and it was done by people who own the definition.
The agent and the dashboard tell the same story
Here is the failure mode that kills trust fast. Someone asks the agent for last quarter revenue and gets one number. They open the executive dashboard and see a different number. Now nobody believes either one, and the whole AI effort takes a credibility hit it did not earn.
This happens because the agent computed its own answer from raw tables while the dashboard used the certified measures. Two paths, two results. Put the agent on the semantic model and there is one path. The agent's answer comes from the same measure that feeds the report, so the numbers match. That alone is worth the move.
Security comes along for the ride
A semantic model carries row level security and object level security. A regional manager sees their region and not the others. A salary column stays hidden from people who should not see it. That work is already done and already governed.
When the agent runs on top of that model, every answer respects the same rules, tied to the identity of the person asking. Point the agent at the lakehouse directly and you have walked away from that security layer. Now you are rebuilding row level filtering down at the storage layer, by hand, and hoping you did not miss a path. I have watched teams badly underestimate how much work that is, and how risky it is to get wrong with sensitive data.
The model already knows how the tables fit together
A gold lakehouse hands the agent a set of tables. It does not tell the agent how a sales fact relates to a product dimension or a calendar. The agent has to guess the joins. Guess wrong and you get double counting, or a grain that makes no sense, and once again it can look perfectly plausible on the screen.
The semantic model encodes those relationships. The agent writes a query against a known star schema instead of inventing joins from scratch. Fewer ways to be quietly wrong.
It speaks the language of the business
Gold tables are full of names like dim_customer and sk_product_id and amt_net_usd. A semantic model has Customer, Product, and Net Revenue. It can hold synonyms, so when someone asks about "sales" the model knows that maps to Net Revenue. It can hold descriptions that tell the agent what a field actually means.
An agent grounded on that metadata gives cleaner answers, because it is working in the words the business already uses instead of decoding warehouse naming conventions on the fly.
You reuse what you already paid for
Most organizations spent months building and certifying their semantic models. That is the asset. Pointing an agent at it is reuse. Building a second semantic layer down in the lakehouse just so the agent has something to talk to means doing the same work twice and keeping two versions of the truth in sync forever. Skip that.
When the lakehouse is still the right answer
This is not a hard rule. There are real cases for grounding an agent on the lakehouse or warehouse instead.
- You need row level detail the model does not carry. Models are built for aggregation, so a question about one specific transaction may not be answerable from the model.
- You need a column nobody has added to the model yet.
- The work is exploratory data science, not business reporting. A notebook against raw data is the right tool there.
A rule of thumb has held up well for me. If a person would answer the question by opening the Power BI report, send the agent to the semantic model. If they would open a notebook, send it to the lakehouse.
The short version
The gold layer is the cleanest copy of your data. The semantic model is the cleanest copy of your meaning. A data agent that answers business questions needs the meaning, not just the data, so start it on the model and only drop down to the lakehouse when you have a reason to.
Westark Data builds Microsoft Fabric and Power BI platforms for organizations that want their data and their AI to agree with each other. Questions, or want a second set of eyes on your Fabric setup? admin@westarkdata.com.