As AI agents move into enterprise workflows, data agents are becoming some of the most business-critical. Every report, recommendation and operational decision depends on their ability to retrieve the right data. Yet while coding and knowledge agents continue to improve rapidly, data agents remain surprisingly unreliable. The reason isn't usually the model. It's that enterprise data carries meaning that exists outside the data itself, and agents have no reliable way to recover it.

A wrong readmission rate

A user typed a routine question into the data agent:

"What's the 30-day readmission rate for our MA members with CHF (Congestive Heart Failure) over the past year?"

The agent produced a number that passed the first user review. However, a clinical reviewer caught the problem days later. 

The result had quietly folded Original Medicare members in with the Medicare Advantage ones. In the US a member enrolls in one or the other but never both, and the two populations follow different rules and carry different regulatory weight, so blending them produces a rate that is wrong at the root.

The error went to an AI engineer to troubleshoot. The model hadn't drifted, the prompt was sound and the SQL was valid, it ran cleanly and returned exactly the rows it asked for. The fault sat one step earlier: when the agent resolved "MA members" against the data, the boundary between Medicare Advantage and Original Medicare had already conflated. The context it reasoned against was wrong before a single query ran.

So the agent didn't fail because the model drifted. It failed because the context was reconciled carelessly.

One concept, two systems

The member data came from two systems of record, and the two describe Medicare plans differently.

Source 1, Claims DB. Three levels deep, down to HMO and PPO:

Medicare

├── MedicareAdvantage

│   ├── MA_HMO

│   └── MA_PPO

└── OriginalMedicare

    ├── OM_A

    └── OM_B

Source 2, Enrollment. Two levels, and it stops there:

Medicare

├── Advantage   

└── Traditional

Each system is internally correct. Both preserve the meaning of Medicare, and both keep Medicare Advantage and Original Medicare apart. But they keep them apart at different depths and under different names, MedicareAdvantage in Claims, Advantage in Enrollment.

It's one shared idea, Medicare, represented two ways. And no one holds both halves of the knowledge: why Claims models it down to HMO and PPO, why Enrollment stops at two levels, which name is authoritative when they meet. That knowledge lived with whoever designed each system, years apart, and was never written down in one place. 

The LLM doesn't know that relationship either. Without explicit mappings or business rules connecting the two systems, it falls back on semantic similarity rather than enterprise semantics. "Advantage" and "Medicare Advantage" appear closely related, so merging both hierarchies into a shared parent becomes a plausible interpretation. In doing so, it loses the business distinction neither source system ever needed to encode explicitly: a Medicare Advantage member and an Original Medicare member are mutually exclusive populations.

Can we control it?

A post-mortem found the problem. It took weeks for a clinical reviewer and an AI engineer to close the gap. The real question is whether we have a scalable way to catch this, before it reaches a decision, without an expert reading every result by hand.

To answer that, look at what a data agent actually does. Almost every one runs the same six steps, and each step is a place where we might, in principle, catch an error:

Five of the six steps have real, deterministic controls, we know how to confirm intent, lint a query, enforce a type, validate a schema, check a format. The wrong readmission rate came from step 2, context resolution. So the question narrows to one thing: does that step have a control?

The uncomfortable truth, for most enterprises today, is no. 

The missing control in context

Context resolution is the critical and challenging point where data agents fail. Natural language often abstracts distinctions that enterprise systems must preserve. While harmless within a clear domain boundary, it can be dangerous when spanning multiple systems. And most real data requests are exactly that: they span sources of truth, not one clean domain.

In the CHF example, the agent reconciled Claims and Enrollment by collapsing Medicare Advantage and Original Medicare into the shared term they both trace back to: Medicare. An experienced analyst knows these categories are mutually exclusive, but that knowledge is rarely codified. It exists only as tacit tribal knowledge within individual teams, never written down as an executable rule that guides the system behaviors.

Documentation helps humans understand systems, but it rarely participates in query-time reasoning. Even when the rule exists in a wiki, the agent isn't consulting that wiki while resolving a query. Relying on documentation or on a better model treats the symptom after the fact, rather than preventing the collision at the source.

Closing the gap

Data agents rarely operate within a single, well-defined domain. Most requests require them to bridge systems such as Claims and Enrollment, finance and billing, or product and support. Cross-domain context resolution isn't a special case. It's their primary responsibility.

And we have to admit that, for most of us, this is exactly the step with no control today.

A few starting points, from what we've seen work.

Recognize recurring reconciliation patterns: The Medicare Advantage / Original Medicare collision isn't a one-off, it's an instance of a recurring shape (Figure 1.): the same concept represented by duplicated entities across systems, each correct on its own, none aware of the other. Once you know to look for that shape, you can go find where else it's hiding.

Continuously discover new semantic gaps: Systems change, new sources get added and yesterday's clean mapping quietly grows a new seam. Discovery has to run on an ongoing basis, not once at project kickoff.

Turn the tacit into the codified: The rule that Medicare Advantage and Original Medicare are mutually exclusive lives in an analyst's head. It needs to become a written, explicit rule: the kind a system can check, not just a fact a person happens to know.

Make context resolution a runtime service: A codified rule sitting in a document doesn't help if the agent never consults it. It needs to become a service the agent calls at the moment it resolves a query, the same way execution has an engine to enforce it, resolution needs something to enforce it.

Prefer domain-aware data products: By using products that resolve exclusivity rules within their contract, you offload the reconciliation logic from the agent. This fulfills the promise of domain-oriented data: absorbing complex context resolution before the agent ever runs a query.

None of this is a model problem, and none of it gets solved by waiting for a better one. It's a problem of resolving, governing and servicing context, and it needs its own discipline at scale, codified with first-class citizen treatment.

Enterprise AI has spent enormous effort improving how agents reason. Far less attention has gone into improving what they reason over. Until context becomes an explicit, governed and executable asset, data agents will continue producing confidently wrong answers, not because they lack intelligence, but because they inherit ambiguity. Preparing data for the agentic era therefore means more than making it accessible. It means making its meaning executable.