Context Isn't Enough: Agentic Analytics Eventually Has to Fix the Data

Teams are teaching agents to navigate data platforms with skills, semantic layers, and ontologies. The results are impressive. They also keep running into the same thing: the data underneath.

TL;DR: Analytics agents are being improved by layering context around the data: skills, semantic layers, and lately ontologies. It works, but every such layer is still a map over a platform it did not shape. If the platform is ambiguous and messy, the map grows expensive, drifts out of date, and the agent may still ignore it. The more durable fix is a declarative data model that generates more of the platform, so meaning is built in rather than documented on top.

• The context arms race
• Where context hits a wall
• What the mess actually looks like
• Building the meaning into the model
• From context to structure

The context arms race

The most visible recent development in agentic analytics is the context placed around the data: skills, semantic layers, rules files, reference docs, glossaries. Anthropic now automates 95% of its internal business analytics queries through Claude at roughly 95% accuracy, and credits skills as the biggest lever; without them, accuracy did not exceed 21%. Claire Gouze took her analytics agent from 4% to 82% correct answers by iterating on a dbt semantic layer and agent rules.

The context is also getting more formal. Open Semantic Interchange (OSI), the vendor-neutral semantic standard backed by Snowflake, dbt Labs, Salesforce, and other companies, now defines a common way to exchange semantic metadata across tools. It has also added an ontology specification: concepts, typed relationships, identity declarations, constraints, derivation rules. Microsoft is going the same way with Fabric IQ, now in preview, which makes ontology a core platform item for grounding agents. The docs are clear about why: tables and schemas are "structures built for machines, not meaning."

Skills, semantic layers, and ontologies differ in how formal they are, but they all respond to the same problem: the agent needs a map of the data estate. It needs to know what concepts exist, which tables matter, which joins are safe, which definitions are governed, and which traps to avoid.

A map is the obvious first move. You can draw one without changing the terrain.

Where context hits a wall

The improvement from context is real. That is not the point in question.

The question is what the examples reveal after the first jump in accuracy. In both Anthropic's post and Gouze's semantic-layer experiment, the remaining work is not only about giving the agent more instructions. It is about improving the data model the agent is trying to use.

For Anthropic, the hard part is mapping a user's question to the right entities in the data model; once that works, writing the SQL is easy. Their stack uses skills to help the agent retrieve and follow the right context, but the foundation is still the governed data underneath: canonical datasets, deprecated near-duplicates, enforced standards, maintained metadata, freshness checks, and validation.

A semantic layer can help resolve which definition of revenue to use, but only after someone has done the work of defining, governing, and maintaining that choice. If forty plausible revenue datasets exist underneath, the semantic layer can route around the confusion, but it has not made the confusion disappear. What should be the same business decision now has to be represented in the warehouse, the semantic layer, the documentation, and the agent instructions, and all of those representations can drift.

Gouze ends up in the same place. Her remaining failures came from bad joins between tables that shared primary keys, nulls nobody filtered, business rules that existed only in people's heads, and metrics that needed data model changes before any semantic layer could express them. Her own summary: "the semantic layer reduces hallucinations, but doesn't remove them entirely."

Context can route an agent to the right answer only if the platform contains a right answer to route to.

What the mess actually looks like

Anyone who has worked in a data platform that grew over many years knows what this looks like. Naming conventions vary from team to team and year to year. Keys are missing or loosely defined. Pipelines are orphaned. Some data is historized, some is overwritten in place, and nothing tells you which. Filters are undocumented, grain is mixed, and the same logic is implemented three times with three subtly different results.

Each of these quirks turns into context the agent has to carry around. Anthropic's published skill skeleton includes a dedicated "Field Naming Gotchas" section ("use field_x_v2 NOT field_x"). This is compensating documentation: writing the mess down instead of removing it.

Documentation like that has several problems. The first is that it goes stale. Anthropic watched accuracy fall from roughly 95% to 65% within a month, because the docs described a model that changed daily, and it took real engineering (colocated docs, CI hooks, automated correction harvesting) to stop the rot.

It is also expensive, since every gotcha means more tokens for the agent to read on every question; Gouze found her semantic-layer setup noticeably slower and costlier. It crowds out other context, which feeds the very retrieval failures it was meant to prevent. And in the end it is advice rather than a rule. In Anthropic's most telling experiment, the agent had access to thousands of earlier SQL queries, demonstrably read them, and accuracy moved by less than a point.

A rule the agent has to remember is weaker than a rule the platform enforces.

A formal ontology does better than free-text documentation. It is harder to misread, and its constraints can be checked. But declared over a messy platform, it still has to encode the mess, and it still describes a territory it did not shape.

Context is useful. But when it is compensating for ambiguity, duplicated logic, missing keys, unclear grain, or undocumented business rules, the better long-term answer is not more context. It is a better governed model, one that embeds and enforces more of that meaning natively.

Building the meaning into the model

The way to get there is to declare meaning from the beginning and let more of the platform be generated from it.

Define the business model declaratively: entities, attributes, identifiers, relationships, valid histories, source mappings, and the rules that turn source data into analytical facts. Then let a compiler generate the physical implementation.

This changes the failure mode. Much of the mess described earlier never gets a chance to form. Naming is uniform because it is generated. Every entity gets identifiers from the start. Historization is something you declare, with one mechanism everywhere, rather than something each pipeline solves in its own way. Grain is fixed per entity, and attributes are modeled as answers to atomic business questions: a loan amount is not just a number, but a number plus a currency. Logic is defined once and compiled wherever it is needed, and nothing deployed can be orphaned, because everything derives from the current model.

None of this solves everything. A generated platform still inherits the quality of its source systems, and a poorly chosen model compiles just as reliably as a good one. But it shrinks the space where mess can accumulate, and the description and the implementation can no longer drift apart, because one is produced from the other.

For an agent, that last point is the one that counts. Coding agents do well because codebases are legible, and a generated platform is legible by construction: an agent that learns the shape of one entity knows the shape of all of them. The declared model is the source and the warehouse is an output. In effect, the model becomes the ontology, except the platform is generated from it instead of merely described by it. A semantic layer can be exposed from the same declarations rather than maintained on the side.

From context to structure

This is the idea behind Daana, a declarative data modeling tool: business models defined in YAML, compiled into deployed transformation infrastructure, with identifiers, historization, naming consistency, validation, and documentation generated rather than hand-maintained. We recently documented what this looks like in practice in a case study with Nextory: a platform rebuilt so that definitions drive the implementation, and what changed once meaning lived in the model instead of in documentation beside it.

With that kind of approach, much of the ambiguity we see in today's platforms never gets the chance to form. The platform becomes easier for humans to understand, easier for agents to navigate, and easier to extend without slowly recreating the same mess in a new layer.

Context that explains a well-structured platform is leverage. Context that papers over an ambiguous one is a patch.

The patch grows with every gotcha and decays with every schema change. The lasting gains come from moving meaning out of the map and into the territory.

Or, put more bluntly: rather than writing ever better guidebooks to the maze, stop building mazes.