Why your AI agent gives technically-correct answers that are still wrong

Enterprises are pouring effort into giving AI agents context. The piece that decides whether an agent is useful is the part almost nobody is capturing.

Why your AI agent gives technically-correct answers that are still wrong

An AI agent can find the right table, use the right named metric, apply the right join, and still return an answer that is wrong.

Not wrong in the way a chatbot invents a fact. Wrong in a quieter, more expensive way: technically correct, and yet not what the business actually meant. The agent counts customers from the customer table when everyone on the team knows you have to use a corrected version of it, because the original has a join bug nobody fully removed. It reports revenue by calendar weeks starting Monday when the question was about finance, which runs on Sunday boundaries. The query runs clean. The number is off by twelve percent. Nobody notices until a decision has already been made on it.

This is the problem sitting underneath the current rush to make enterprise AI "context-aware," and it is the part the industry conversation keeps skating over.

Everyone agrees context is the bottleneck

At Snowflake Summit 2026, one word ran through nearly every keynote, breakout and booth: context. Catalog companies, semantic layers, observability tools, ingestion platforms, agent platforms, each had its version of the same pitch. Snowflake put real engineering behind it, with a system that gathers context for agents before they answer and lifted accuracy on its own evaluation from 24% to 83%.

The convergence is happening for a sound reason. The accuracy of an AI agent answering a business question depends almost entirely on what it knows about the business, the data, and the relationship between them. Without that, the agent is guessing.

But "context" as the industry is currently capturing it means context that can be written down: catalogs holding metadata about tables, semantic layers mapping business terms to columns, glossaries documenting what metrics mean. All real, valuable work. And all of it stops short of the context that most often decides whether an agent is useful.

The knowledge that lives in people's heads

Engineers call it tribal knowledge. It is the reason a team always uses one version of an ID and not another, the reason marketing and finance count weeks differently, the reason nobody joins two particular tables directly but routes through a third that quietly fixes a renamed key.

Almost none of it sits in any catalog, semantic layer or wiki. It lives in the head of the senior engineer who has been at the company for three or four years. When that person leaves, a meaningful share of it walks out of the door with them.

And this is precisely the context that separates a technically-right answer from a genuinely useful one. The agent that pulls last quarter's revenue from the canonical table is correct and useless if the team trusts a different view the catalog never flagged as the operative one.

Why it is so hard to capture

Tribal knowledge resists the tools built to hold it, for a few specific reasons.

It is situational. Almost every rule a team follows is a response to a particular historical event, and without the why, the rule looks arbitrary. It is contested, converged on through arguments rather than handed down, so capturing it means resolving those arguments rather than transcribing them. It evolves constantly, so a snapshot taken in one month is stale by the next. And it is invisible until it's wrong, because people don't realise they're applying it until they watch a new hire not apply it and produce something subtly off.

Wikis weren't built for knowledge like this. Neither were catalogs or semantic layers. The industry has been using tools designed for stable, documentable information to try to hold knowledge that is none of those things.

There is also a comfortable illusion at work. The codifiable parts of context, schema, lineage, metric definitions, are roughly eighty percent of what an agent technically needs, so the working assumption is that capturing that eighty percent gets you most of the accuracy. The catch is that the remaining twenty percent, the tribal part, is often what determines whether the answer is right or wrong in exactly the cases that matter most.

What good capture looks like

Holding this kind of knowledge in a form an agent can actually use has a few requirements that fall straight out of the difficulties above.

It has to happen as a side effect of the work, not as a separate documentation project, because no working data team has time to maintain a wiki of why they do things. It has to be readable by every agent operating on the team's data, not locked inside one vendor's product. It has to be enforced at the moment a pipeline is built, not checked weeks later once it has already run. And it has to regenerate as the team and the data evolve, because the underlying truth keeps moving.

That is a meaningfully different shape from a catalog. It is closer to a continuously maintained operating model for the data team, one that every agent, human or otherwise, reads on every job.

This is the layer Maia, the AI data platform built by Matillion, is working on. Its Context Engine is where a team's standards, naming rules, business definitions, governance policies, and the reasoning behind each convention, get encoded once and read by every agent on every job, with the standards enforced at build time rather than audited after the fact.

The platform-level investments and this kind of standards capture are complementary rather than competing. One provides the infrastructure to retrieve and apply context inside the warehouse. The other captures the team's specific tribal knowledge in a form those agents can read. Together they produce agents that are accurate not just because they found the right data, but because they applied the team's actual rules to it.

The move after this one

The agentic enterprise has graduated from vendor pitch to broad consensus, and the bar has moved from experimental projects to agents that have to work in production. Context is rightly seen as the gating factor for whether any of it works at scale.

Where that conversation has the most room to deepen is on the tacit, situational knowledge that lives in a team's practice rather than in any document. The organisations that win agentic data work over the coming years will be the ones that treat their team's tribal knowledge as a first-class artifact, kept current and made readable to every agent, rather than something written down occasionally and left to rot.

A fuller version of this argument, with worked examples of the knowledge agents keep missing, is set out in this analysis from Snowflake Summit 2026.

Disclaimer: This article is sponsored content curated by HT Syndication. The inputs and details accounted for in the article do not necessarily reflect those of HT, and HT does not endorse or assume any responsibility for the information provided.

Want to get your story featured as above? click here!