Enterprise agents fail when they cannot tell which tables, columns, knowledge bases, or definitions are authoritative.
2
A hierarchy of semantic layers, canonical tables, and database graphs gives agents a structured way to choose data sources.
3
Staleness needs a context lifecycle with live data sources, logged feedback, and regular evaluation, while user preferences remain unresolved.
Summary
Ishita Daga argues that enterprise agents often fail because they lack structure around business data. Bigger models, longer prompts, Markdown files, and more tools do not tell an agent which source is authoritative, which definition is current, or which metric a particular team prefers. She proposes a hierarchy of sources: a curated semantic layer first, canonical tables next, and a flexible database graph last. She also describes a context lifecycle built from continuously updated sources, event logging, and evaluation suites. The hardest problem is preference. Two teams can calculate the same metric correctly in different ways, so the agent needs to route a question to the right definition based on the user or team. Daga is direct that current approaches, including semantic layers and agent memory, do not fully solve this routing problem.
Enterprise agents fail because their business context is ambiguous, stale, and preference-dependent
Daga says teams often respond to bad agent answers by choosing a newer or larger model, adding more context, or supplying more Markdown files, documents, plugins, and MCP servers. Those additions do not solve the agent's underlying data problem. The agent may not know which table, column, data source, or knowledge base is correct. Context also becomes stale as KPI definitions and processes change. A third problem is preference: teams may use different filters, definitions, or query patterns for the same question. Daga presents preference as the least settled of the three problems because it depends on the individual or team using the agent.
A source-of-truth hierarchy should guide the agent from curated data toward flexible data
Daga says an agent should not treat every knowledge base equally. Sources of truth have a hierarchy that runs from the cleanest and least flexible source to the messiest, most dynamic source. The agent should start with the curated source and move outward only when needed. The first layer is a semantic layer containing queries, KPI definitions, metric calculations, and business definitions. The agent can find the closest KPI and use the associated data points. This gives it a structured answer path instead of asking it to guess among raw sources.
Semantic layers and canonical tables should come before a database graph
The second source type is canonical tables, including parameterized tables and queries. These give the agent a set of prepared options while allowing more flexibility in query writing and filters. The third type is a database graph that connects tables to columns, metrics, and the questions those metrics can answer. Daga says the graph can support a wider range of questions, but it takes substantial effort to build and maintain. Her recommendation is to add the semantic layer and canonical tables first. She says those layers solve 80% of the problems, leaving the database graph for the remaining 20%.
A context lifecycle needs live sources and a feedback loop
Daga describes stale context as information that has become rotten, deprecated, or out of date because business processes change. Her proposed context lifecycle has two parts. The first is embedding live data or knowledge sources that are regularly updated, reviewed, and curated. Examples include GitHub, CRM tools, Tableau, and dbt semantic layers. The second is a feedback loop that logs events whenever someone reports an incorrect database, changes a definition, introduces a new metric calculation, or requires a new filter. Those events should update the agent's context instead of disappearing after a conversation.
Evaluation turns user feedback into measurable context updates
After logging feedback, teams need to evaluate the agent and use the results to update its context. Daga suggests a human-annotated evaluation suite or an automated evaluation based on recent questions and answers. The automated approach compares new answers with the actual answers to judge how close they are. She says many teams do not track this progress, so they cannot tell how the agent is performing or whether it is improving. Logging, evaluation, and context updates form a loop that keeps the agent's information current rather than leaving old instructions in files that nobody maintains.
Different teams can have different correct definitions for the same metric
Daga illustrates preference with average milestone time. One team measures it from completion of the previous milestone to completion of the current milestone. Another measures it from the start of the current milestone to the start of the next milestone. Both calculations can be correct, but they produce different answers. The agent therefore needs to understand what a person or team means when they ask for average milestone time. A single canonical query cannot capture this difference. The desired system would route the agent to the appropriate metric based on the identity of the individual or team.
Current semantic-layer and memory approaches still leave preference unresolved
Daga is honest that the industry does not yet have a settled solution for preference. One approach stores multiple metric calculations in a semantic layer and lets the user prompt the model to choose one. That still requires the user to specify the desired metric, so ambiguity remains. Another approach uses agent memory, such as Mem0 or a memory.md file, to store preferences. Daga says memory can record a preference but cannot reliably distinguish two metrics or know when each should be used. The unresolved requirement is routing each question to the right metric for the user or team.
"The source of truth actually is a hierarchy, which goes from the cleanest, least flexible source of truth to the messiest, but most flexible, most dynamic source of truth."02:59
Who should watch
You are building an analytics or data agent that often picks the wrong table, metric, or knowledge source.
Your business definitions and processes change often, and your agent relies on Markdown files or other manually maintained context.
Different teams use valid but incompatible definitions and you need to think through how an agent should select between them.
