One Ring to Rule Them All? Why a Single Enterprise Semantic Model Will Set Your Agentic BI Back, Not Move It Forward

By Marius Moscovici
Founder & CEO at Metric Insights

The One Ring did not work out well for Sauron. If you take the same approach to Agentic AI for BI by trying to build a single, all-encompassing semantic model that covers the entire enterprise, it will not work out well for you, either.

The idea is seductive. In order to deploy AI agents that can reliably answer business questions, a semantic model is absolutely essential. Without one, you cannot achieve the level of quality and accuracy that enterprise users expect from an Agentic BI Analyst. The semantic model provides the guardrails: it tells the AI what measures and dimensions exist, how tables join, which filters apply, and what the business actually means when it says “revenue” or “churn.”

Today, those semantics largely live outside the cloud database. They are embedded in the thousands of reports that enterprises have built over the years, each with its own filters, aggregations, formulas, and join logic. If the next generation of agentic BI workflows is going to be centered around AI agents that query the database directly, then it follows that the semantic model needs to exist there too.

Since it is difficult to anticipate the exact scope of questions users will ask, it is natural to assume that the semantic model must cover everything. That it must be universal. That you need One Semantic Model to Rule Them All.

This is the trap.

Building a universal semantic model means migrating every meaningful business definition from your reporting layer into the database. In a typical enterprise, this means reverse-engineering thousands of reports, each with its own KPI definitions, special filters, table relationships, and calculated fields.

You cannot skip this reverse-engineering step, either. If you build your database semantic model independently of your existing reports, the AI’s answers will inevitably diverge from the reports that users already trust, undermining confidence in the entire system. Making matters worse, you often have no way of knowing which of those reports are truly trusted and which are abandoned, duplicative, or flat-out wrong. So you end up doing enormous work while importing inconsistencies and errors alongside the legitimate business logic.

Even if you had unlimited time, achieving consistent definitions across an entire enterprise is a fundamentally hard problem. Large organizations employ hundreds of report developers across dozens of business units. Each unit has its own vocabulary, its own nuances, and its own way of calculating metrics that may share a common name but carry very different meanings.

“Sales” in the Retail Monthly Snapshot might include only retail transactions. “Sales” in the Board Reporting package might include all channels. Both are correct within their context, but a universal semantic model forces you to either reconcile them into a single definition or maintain a web of exceptions that grows more tangled with every new business unit you onboard. The effort to keep everything consistent increases non-linearly with the size of the model.

The data industry moved away from centralized Enterprise Data Warehouses toward Data Mesh and Data Fabric architectures for good reason. Centralized models were slow to evolve, created bottlenecks, and could not keep pace with the rate at which the business needed new analytics. A single enterprise-wide semantic model that is centrally administered reintroduces exactly the same problem.

The moment a report developer adds a new calculated field, updates a filter, or redefines a KPI in the reporting layer, your centralized semantic model is out of date. Because changes must flow through a central governance process, the model will always lag behind the business reality it is supposed to represent.

When a business analyst needs a new metric for an analysis that is due today, waiting weeks for that metric to be certified and published in a centralized semantic model is not a realistic option. In practice, people will work around the model, building shadow definitions, ad-hoc queries, and one-off reports that exist outside the governed framework. This is exactly the ungoverned sprawl that the semantic model was supposed to prevent.

Centralized governance works when the scope is contained. At enterprise scale, the pace of change and the diversity of analytical needs overwhelm any single team’s ability to keep the model current, accurate, and comprehensive.

The four problems above are real, but they are symptoms of a more fundamental mistake: the assumption that the AI agent handling a user’s question should live inside the cloud database.

When you anchor the agent in the database, you are forced to rebuild the semantic model there, because by definition, a database-native agent has no access to the semantic models that already exist in your deployed BI tools like Power BI, Tableau, or Looker. Every filter, calculated field, and join relationship that a report developer has carefully defined in those tools is invisible to it.

This is why the “One Ring” approach requires such a massive migration effort in the first place. The agent can only use what it can see, and a database-resident agent can only see what is in the database.

The alternative is to build the AI for BI Agent Harness outside the database, as an orchestration layer that can connect to both database agents for direct data access and to the semantic models embedded in your deployed BI tools. This architectural shift changes the problem entirely. Instead of recreating your semantic layer from scratch, you can leverage the one you already have.

In our next post, we will introduce the Composite Semantic Model: a federated, governed approach that treats your existing trusted reports as the semantic foundation of the enterprise, and uses AI to stitch them together into a coherent whole that agentic BI can rely on.

Don’t forge a Ring. We will show you how to build a Fellowship.