The modern data stack, a revolutionary approach to managing and analyzing business information, brought forth numerous advancements. Among the most significant was the semantic layer, an abstraction that externalized business logic, ensured metric consistency across disparate tools, and fostered a shared understanding of key business terms like "revenue" and "churn." Tools such as MetricFlow, LookML, and Cube all fundamentally addressed the question: "What does this metric mean, and how is it consistently calculated?" This proved invaluable for human analysts interpreting dashboards. However, as the landscape evolves with the rise of AI agents, this same question becomes increasingly problematic. Agents, unlike human analysts, require a deeper understanding of real-world entities and their relationships, a need the semantic layer, as it currently exists, was not designed to fulfill.
The Limitations of Metric Abstraction for Agentic Systems
The core issue lies in the fundamental difference between an analyst’s query and an agent’s operational requirement. While a semantic layer excels at defining and standardizing metrics for aggregate analysis, it falls short when an agent needs to perform complex, multi-system tasks. Consider an agent tasked with resolving a customer issue. It might need to correlate a Stripe charge, a Zendesk support ticket, and a Salesforce contact to identify a single individual and understand their recent interaction history, including any negative experiences. This necessitates understanding entities—customers, transactions, support interactions—and the intricate web of relationships connecting them across different operational systems.
Weekly discussions with founders and operators building agents on top of established data stacks reveal a recurring pattern. These teams have diligently implemented robust data foundations, including dbt for data transformation, LookML or Cube for semantic modeling, and carefully governed metric definitions. Their dashboards present a unified view of key performance indicators, yet their agents frequently falter in production. The common failure point isn’t in the underlying data models or the prompt engineering; it’s the agent’s inability to reliably resolve that records from billing, support, and CRM systems all refer to the same real-world customer.
This breakdown occurs because semantic layers were architected for a different consumer: the human analyst interacting with BI tools. They address the "meaning" layer of context engineering, ensuring that "revenue" is understood uniformly. However, agents require more than just a shared vocabulary of metrics. They need "structure" (entities and their cross-system relationships) and "control" (permissions, auditability, and defined action capabilities). When teams invest heavily in metric definition and discover that agents struggle with operational edge cases, they often realize the critical absence of structure and control.
The Entity Gap: A Fundamental Architectural Mismatch
The problem extends beyond missing features; it points to a deeper architectural mismatch. For the past decade, the modern data stack has been optimized around the metric as the atomic unit of data infrastructure. Tools like dbt, LookML, and Cube, along with calculated fields in BI platforms, are designed to define, govern, and query metrics. This focus has been immensely successful in achieving metric consistency, enabling analysts to confidently report on figures like Monthly Recurring Revenue (MRR).
However, this metric-centric paradigm has created a significant blind spot: the operationalization of entity identity and relationships across systems. While teams can meticulously define MRR and ensure its consistency, they often cannot definitively state that a customer_id 4821 in Stripe is the same individual as [email protected] in Zendesk. The industry has excelled at standardizing the meaning of aggregate data without addressing the operational consistency of identity across systems. This asymmetry has emerged as a critical bottleneck for agentic applications.
The advent of AI agents necessitates a paradigm shift. If the Business Intelligence (BI) era elevated the metric to a first-class citizen of data infrastructure, the agentic era demands that the entity achieve this status. This is not a mere feature gap but a fundamental reorientation. The vast majority of modern data stack tools are geared towards defining, governing, and querying metrics. Far fewer tools, workflows, and dedicated roles exist for resolving, connecting, and traversing entities across diverse systems. The current imbalance explains why many organizations with sophisticated data governance still struggle to enable agents to execute multi-step workflows. As noted by Jessica Talisman in Metadata Weekly, AI systems reason differently than human analysts. They don’t primarily need metrics presented in charts; they require a robust understanding of concepts, their inherent relationships, and the ability to infer meaning from these connections.
Lessons from the Text-to-SQL Graveyard
The early wave of text-to-SQL products, which emerged following the launch of ChatGPT, offers a prescient cautionary tale. These tools promised users the ability to "chat with their database" and receive instant answers. While they demonstrated impressive capabilities in narrow, clean environments, sustained production usage proved elusive for many. The post-mortems often focused on simplistic implementations or model quality. However, conversations with builders from that era reveal a more nuanced failure mode rooted in the complexity of multi-system data interactions.
Text-to-SQL solutions often performed remarkably well when queries were confined to a single system with a well-defined schema. Questions like "How many orders last week?" or "Top SKUs" were easily handled because all necessary information resided within that system’s schema. The models appeared brilliant. The challenge arose when teams integrated a second or third system—support tickets, refund data, billing events, CRM contacts. Suddenly, the agent wasn’t failing on SQL generation; it was failing on the implicit meaning of relationships that were absent from any single schema. The model lacked the contextual knowledge to understand which ticket belonged to which order, which refund was associated with which customer, or what constituted a "negative" support experience within that specific company. The models could not reason about relationships that had never been formally defined.
.png)
These teams stumbled because they inherited the semantic layer’s foundational assumption: that "understanding data" equates to knowing what individual columns mean. They discovered that agents require something beyond column-level abstraction—namely, a comprehensive understanding of how entities connect across disparate systems. The initial success within single systems ironically made the multi-system failures harder to diagnose, as the teams had evidence that "it works." This pattern suggests a structural prediction: any team building agents on top of a semantic layer without a formal ontology is undertaking a similar experiment, albeit with a longer timeline before critical failures emerge.
Ontology vs. Semantic Layer: A Map vs. A Dictionary
The distinction between a semantic layer and an ontology can be visualized as the difference between a dictionary and a map. A semantic layer, much like a dictionary, defines the meaning of words. It tells you what "revenue" signifies and how it’s calculated. An ontology, however, functions as a map, illustrating how different entities and concepts connect. One can possess a perfect dictionary and still be utterly lost when trying to navigate a complex territory.
Kirk Marple emphasizes that metadata, when structured as a model, is crucial. Providing agents with a semantic ontology is as vital as the data itself. When this ontology is populated with live data, it transforms into a knowledge graph—a dynamic, operational network of entities and their relationships that agents can traverse in real time. The semantic layer never needed to evolve into this because dashboards do not traverse relationships; agents do.
This difference becomes starkly evident when comparing the workflows of human analysts and AI agents. An analyst typically poses a question and receives a numerical answer. An agent, however, begins with an entity, such as a customer, then follows a relationship to their recent transactions, then to refund activity, then to open support tickets, checks communication history, makes a decision on an appropriate action, and finally executes a write operation. Each step is contingent on the preceding one, and each step demands an understanding of the connection between distinct entities. This process is traversal, and traversal necessitates a map—an ontology—not merely a dictionary.
The Convergence Trap: Extending the Old or Building the New?
As the industry grapples with the limitations of current data infrastructure for agentic applications, a predictable instinct emerges: extend what already exists. dbt has open-sourced MetricFlow, framing it as a bridge between AI and structured data. Microsoft, at its Ignite conference, introduced an ontology-based "IQ layer," a move significant enough for SoftwareReviews to note its use of the term "ontology" in this context. Vendors in the semantic layer space, such as Galaxy and Atlan, are beginning to integrate entity resolution and relationship modeling alongside their metric governance capabilities. The prevailing narrative is one of convergence, suggesting the semantic layer is evolving to meet the demands of the agentic era.
However, this framing can be a trap. When metric-first systems attempt to bolt on entity awareness, the fundamental architectural center of gravity remains unchanged. Design decisions, default behaviors, and optimizations continue to prioritize aggregate computation. Entity traversal becomes a secondary capability, struggling for resources within an architecture not originally designed for it. This is akin to adding a camera to a flip phone; while it can technically take pictures, the underlying architecture was never conceived around the camera’s functionality. The success of the iPhone stemmed not from adding a camera to an existing phone but from designing the device around the camera, while also integrating phone capabilities. An "ontology-first" infrastructure, with metric governance integrated, represents this iPhone architecture. A semantic layer with bolted-on entity awareness is the flip phone with a camera.
Jessica Talisman’s observations in Metadata Weekly are pertinent here: the gap between metric definitions, often expressed in YAML, and formal ontologies, which represent fundamentally different approaches to knowledge representation, may be too wide to bridge incrementally. Transitioning from one paradigm to another through gradual extension is unlikely to succeed.
"Ontology-First" Architecture: A New Paradigm
The agent designs that have successfully shipped to production often reflect an inversion of the typical approach. They are "ontology-first," with metric governance capabilities then integrated. This starting point—entities and their relationships—and layering metric governance on top creates a distinctly different architecture than beginning with metrics and attempting to add entity awareness later. The order of operations dictates the center of gravity, which in turn determines scalability and operational effectiveness. Teams that grasp this distinction are more likely to build functional agents, while others may continue to produce sophisticated demos that falter in real-world scenarios.
The Unclaimed Territory: Ownership of the Entity Model
The most significant hurdle in this transition is not technical but organizational. Ask a data team, "Who owns metric definitions?" The answer is usually clear: analytics engineers, managed through a dbt project or a semantic layer configuration. Ownership, workflows, and accountability are well-established.
Now, ask, "Who owns the entity model?" Who is responsible for deciding that a customer record in Stripe, Salesforce, a support platform, and a product database all represent the same real-world entity? Who maintains the rules governing how these entities connect? In many organizations, this question is met with hesitation, confusion, or a simple shrug.
The knowledge required to build an entity model often resides within the institutional memory of individuals—account managers, support representatives, sales operations specialists, or long-tenured engineers. They possess the implicit understanding that "Acme Corp" in Salesforce is equivalent to "Acme Corporation Ltd" in billing systems, or that certain tags in a support ticket signify billing-related issues versus technical ones. However, this knowledge has rarely been formally requested or codified into infrastructure.
Because no job description explicitly includes "maintain the entity model," it remains an unaddressed responsibility. No tool directly solicits this knowledge, no workflow captures it, and no role is formally accountable for it. This is why ontologies often fail to materialize. The necessary organizational practice has not yet evolved, leaving critical entity knowledge trapped in tribal memory, inaccessible to the agents that desperately need it. Data engineers built schemas for data storage, analysts built dashboards for reporting, but no one has systematically built the "map" of business entities and their interconnections. This is the true gap.
For the semantic layer to succeed, it provided a defined role: define metrics, maintain them in code, review changes, and deploy. Ontology will only achieve similar traction when an equivalent structure exists: a dedicated role responsible for entity definitions, a workflow for maintaining cross-system relationships, and a clear expectation that entity knowledge is treated as core infrastructure, not mere anecdotal understanding. Without this organizational commitment, even the most advanced tooling risks becoming shelfware. Technology is the easier part; fostering a team discipline around entity resolution as a first-class engineering concern is the more challenging, yet critical, determinant of an agent’s operational success.
A Simple Diagnostic: The Two-Question Test
Organizations can quickly assess their readiness for agentic applications by posing two simple questions to their AI agent. The first question tests the efficacy of the existing semantic layer: "What was Q3 revenue?" If the semantic layer is functioning correctly, the agent should provide an accurate answer, demonstrating its ability to define and retrieve consistent metrics.
The second question, however, probes deeper into the agent’s ability to navigate and act upon entity relationships: "Email the customers who received refunds last week and also had a negative support experience. Personalize each message based on their history." If the agent falters on this second query, it’s rarely due to a forgotten metric definition. The breakdown typically occurs because the organization possesses metric meaning but lacks the essential structure and control required for such complex workflows.
The first question relies solely on metric definitions—what constitutes revenue, the relevant quarter, and the currency. This is precisely what the semantic layer was designed to address. The second question, however, demands entirely different infrastructure. It requires an understanding of how entities connect across systems, the contextual meaning of terms within specific operational domains, and the ability to traverse from one business function to another. This is the domain of ontology.
Administering this two-question test to an organization’s agent can swiftly identify the missing components. If the second question fails, it signals a fundamental gap that cannot be resolved with a simple feature request; it necessitates a different foundational approach.
The Missing Practice: Formalizing Entity Knowledge
Semantic layers empowered a generation of teams to excel at defining and managing quantitative metrics. The teams that will successfully deploy functional agents will adopt a similar rigorous approach to entities and their relationships. This involves assigning ownership, establishing change management processes, and demanding production-grade control over the entity model. Without this discipline, organizations will continue to produce impressive demos that invariably collapse the moment a workflow crosses system boundaries.
The critical gap is not a lack of tools but a missing organizational practice. While tooling for entity resolution and relationship modeling is available, the supporting organizational muscle is not yet developed. The success of the semantic layer was not solely due to a superior product; it was driven by its ability to provide analytics engineers with a clear, defined role: define metrics, maintain them in code, review changes, and deploy. This fostered an entire discipline with clear ownership and a well-defined workflow. Ontology currently lacks this established structure. No one officially "owns" it, no formal process governs its maintenance, and there is no widespread expectation of rigor surrounding it. The tooling may be ready, but until the organizational discipline emerges, entity knowledge will remain confined to the heads of individuals, inaccessible to the agents that depend on it.
The pertinent question for data teams is no longer "How can we adapt our semantic layer for agents?" but rather, "Who within our organization possesses the understanding of how our business entities connect, and why has this crucial knowledge never been formalized into our data infrastructure?" This knowledge represents the map. And without it, agents are effectively navigating blind.
