Why AI agents fail on enterprise data without context (and what fixes it)
The model is rarely the problem: the warehouse knowledge that lives in people's heads is
AI agents fail on enterprise data mainly because the schema they can read does not contain the knowledge needed to use it correctly: what a column means, which table is the trusted one, who may see it, and what depends on it. Anthropic's engineering team frames this as a context problem, not only a prompt problem, in Effective context engineering for AI agents: an agent can only act well on the information placed in its context window. In a warehouse, most of that information was never written down.
Key Takeaways
- •A warehouse schema describes structure, not meaning. Names, types and foreign keys do not tell an agent which of three
orderstables finance trusts. - •Agents fail quietly: a wrong join returns a plausible number, not an error. That is worse than a crash.
- •The missing context falls into five buckets: definitions, lineage, quality state, ownership and policy.
- •A context layer is infrastructure the agent queries (for example over MCP), not a longer system prompt.
- •Context does not fix everything: it will not rescue a warehouse with no owners, no tests and no agreed metric definitions.
Why AI agents fail on enterprise data without context
Consider a real shape of problem on a data team. Someone asks an agent in Claude Code or Cursor: "Why did row counts drop 40% overnight?" The agent can list tables and run SQL. What it cannot see is that a vendor changed an upstream export format at 02:00, that the staging model silently filters rows with a null customer_id, and that a data contract on that table was waived last month. A human on the team knows two of those three things. The agent knows none, so it produces a confident but unsupported explanation.
This is the pattern we see repeatedly, and it is our opinion rather than a measured benchmark: on enterprise data, capable models fail less from lack of reasoning ability and more from lack of grounded facts about the environment. The model is asked to infer organizational knowledge from table names.
The five kinds of missing context
| Missing context | What the agent does without it | Example question it gets wrong |
|---|---|---|
| Definitions (semantic layer) | Invents its own metric logic from column names | "What was revenue last quarter?" with gross, net and recognized revenue all present |
| Lineage | Cannot tell upstream cause from downstream symptom | "What's the blast radius if I drop this column?" |
| Quality and freshness state | Treats stale or failing tables as ground truth | "Show freshness scores for all gold tables." |
| Ownership and history | Does not know who to ask or what changed recently | "What changed in the orders schema since last deploy?" |
| Policy and access | Exposes or joins data it should not | "Who has access to PII columns in analytics?" |
None of these five is exotic. Each one exists somewhere in most companies: a dbt project, a catalog, a Slack thread, an access-control system, someone's memory. The failure is that they are scattered and not reachable by the agent at the moment it writes SQL.
Failure mode 1: plausible wrong answers from ambiguous definitions
Text-to-SQL is the clearest case. If a warehouse has orders, orders_v2 and fct_orders, the agent picks by name similarity unless something tells it otherwise. This is the reason semantic layers exist: dbt documents the idea in its Semantic Layer docs, where metrics are defined once and queried consistently. An agent that queries governed metric definitions fails less often than one that writes raw SQL against raw tables. An agent without access to them reinvents the definition on every question, and two askers can get two different numbers.
Failure mode 2: changes that look safe locally
Ask "Is the customer_id join safe after the migration?" and the agent can check types and row overlap in the tables in front of it. It cannot see the three dashboards, the reverse-ETL sync and the ML feature pipeline that also depend on that key. Without column-level lineage, the safe-looking change is only safe for the part of the graph the agent can see. Our Schema Agent exists for this reason: it maps downstream impact of a column change before a migration is generated, so the blast radius is a lookup rather than a guess.
Failure mode 3: trusting data that is already known to be bad
A table can be queryable and still be wrong today. If the Quality state (failing tests, an open incident, a missed freshness SLA) is not part of what the agent sees, it will answer from stale data without caveat. A human analyst checks the quality dashboard or asks in the channel first. An agent skips that step unless the quality signal is available as a tool it can call, such as the one our Quality Agent exposes on top of Great Expectations and dbt tests.
Failure mode 4: no memory of what happened before
Incident work is mostly history: the last deploy, the previous schema change, the same failure three weeks ago. A fresh agent session starts with none of it. This is why we think context needs to be persistent infrastructure and not a pasted prompt. The same conversation tomorrow should not start from zero. The industry-standard way to expose such persistent sources to coding agents is the Model Context Protocol, which defines how clients like Claude Code and Cursor discover and call tools and resources on a server.
Failure mode 5: access and policy that the agent cannot see
The most serious failure is an agent that is technically allowed to run a query but should not. If PII classification and role policies live in a separate governance tool, the agent has no reason to consult them. A context layer has to carry policy with the data: which columns are classified as PII, who may read them, what must be redacted. Our Governance Agent does this classification and policy work, and our OSS edition is read-only by default so an agent cannot write as a side effect of answering a question.
What a context layer actually is
A context layer is not a bigger prompt and not another catalog UI. It is a queryable service that answers, for any asset, what it means, where it came from, whether it is healthy, who owns it and who may touch it, and that the agent can call at the moment it needs the answer. Anthropic's guidance on context engineering argues for retrieving information just in time instead of loading everything up front. For a warehouse with thousands of tables, that is the only approach that scales: the agent asks for the context of the five tables it is about to join, not all of them.
- •Definitions: governed metrics and column descriptions, from your semantic layer and catalog.
- •Lineage: column-level where available, table-level otherwise.
- •State: freshness, test results, open incidents.
- •People: owners, recent changes, past incidents.
- •Policy: PII classes, RBAC, retention.
Our Catalog Agent federates the catalogs a team already runs (OpenMetadata, DataHub, Amundsen, Unity Catalog, Atlan) so this context is not rebuilt from scratch. We covered the catalog side of the landscape in a separate post on Atlan alternatives, which is a good starting point if you are choosing where definitions should live.
Where Data Workers fits, and where it does not
Data Workers is a set of fifteen MCP-native agents covering pipelines, quality, schema, governance, cost and incidents. Each is an MCP server, so Claude Code, Cursor or any MCP client can call them from the terminal an engineer is already in. The point of coordinating them is that context is shared: when the Incidents Agent diagnoses a failure, the Schema Agent and Quality Agent contribute what they already know instead of the engineer relaying it between tools. In early pilot testing we saw 60% of incidents auto-resolve before human notification; that is our own pilot data, not an independent benchmark.
It does not fit every situation. If a company has no agreed metric definitions, no owners on tables and no tests, no agent will fix that. A context layer exposes knowledge that exists; it does not create it. In that case, the first investment is a dbt semantic layer or catalog descriptions written by humans. If you already have a mature catalog and a semantic layer, you may only need a thin MCP wrapper over them, and a full agent swarm would be more than the problem requires.
A practical order of operations
- •Start read-only. Let agents answer questions before they change anything.
- •Publish definitions first: one governed metric beats ten well-written prompts.
- •Expose quality and freshness state as tools, not dashboards.
- •Add lineage so impact questions become lookups.
- •Attach policy last but before write access, never after.
Frequently Asked Questions
Why do AI agents give wrong answers on enterprise data even when the SQL runs? Because correct syntax is not correct meaning. The agent chooses tables and joins from names and structure, and nothing in the schema says which table is authoritative or how a metric is defined. The query succeeds and returns a plausible but wrong number.
Is a bigger context window enough to fix it? No. A larger window lets you paste more text, but the knowledge still has to exist and be selected. For a warehouse with thousands of tables, retrieving the relevant context on demand works better than loading everything, which is the approach Anthropic describes in its context engineering guidance.
Is a semantic layer the same as a context layer? A semantic layer is one input to a context layer. It supplies governed metric definitions. A context layer also carries lineage, quality state, ownership and policy, and exposes them to the agent as callable tools.
Can we build this ourselves with MCP? Yes. MCP is an open protocol, and wrapping your catalog, dbt project and quality tool as MCP servers is a reasonable build. The cost is maintaining the connectors and keeping the pieces consistent with each other, which is the part a coordinated set of agents is meant to handle.
Where should a team start? With read-only access and one question the team asks every week, such as "What changed in the orders schema since last deploy?" Measure whether the agent's answer matches what an engineer would have found, then add context sources until it does.