The hardest AI failures to catch are the ones that look correct.
We recently talked to an Enterprise Architect at a technically complex manufacturer who’s building federated AI governance across the organization. Thousands of people are contributing context, definitions are being recorded across domains, and agentic workflows are starting to span those boundaries. All this context and dynamism may seem like a good thing, but he identified the failure mode.
“What if certain context drifts in the wrong direction to an inaccurate definition?” he asked. “How do we rectify that? How do we get visibility of that?”
He was seeing what happens when agents across ecosystems define the same word differently, but nobody has a mechanism to detect the divergence, let alone resolve it. What happens when “transport” means something different to the logistics team than it does to the infrastructure team? What happens when agent “ecosystems of context” collide, with no governance model ready to handle what happens next?
This is context drift. And the question of how to get visibility into it is one most enterprises building agentic AI cannot yet answer.
How context drift works in practice
Permalink to “How context drift works in practice”Context drift is the gap between your organization’s current definition of a term, entity, or metric, and what your agents have been told it means.
Let’s say a column called customer_tier was created by the product team in 2022. It reflected three tiers based on seat count. In 2024, the business introduced a new segmentation model — tiers became based on annual contract value. The column name didn’t change and the pipeline didn’t break, so the data continued to flow normally.
But now, an agent querying customer_tier to identify high-value accounts for an expansion play is reasoning from a definition that no longer reflects the business. It will confidently identify the wrong accounts with no error signal. Downstream, models continue training on incorrect context that never gets caught, until the mess is too big to untangle.
Why doesn’t context drift set off alarms?
Permalink to “Why doesn’t context drift set off alarms?”We’re all used to model hallucinations. When an agent invents a fact or contradicts a source document, the output is testable against ground truth. Hallucinations generate incidents, but they’re relatively easy to catch.
Context drift fails in the shape of success. When a RAG system retrieves from a knowledge base and that knowledge base carries stale context, the model reasons correctly over incorrect premises. The math checks out and the metric definition is right — it’s just last quarter’s definition. But who’s checking? The output looks plausible because it is internally consistent.
There are no error codes, no failed assertions, no anomaly alerts. The output passes human review unless someone notices that the agent’s version of “revenue” no longer matches the CFO’s. By the time the damage surfaces, via a misdirected outreach campaign, a flawed capacity plan, or an autonomous procurement decision routed to someone who left the company, the drift has already compounded through hundreds of agent decisions.
Three patterns that cause context drift
Permalink to “Three patterns that cause context drift”Context drift isn’t just one problem. It’s three patterns that look similar from the outside but require different interventions.
Meaning shift after a product or business change. A metric gets redefined when the product or pricing model changes, but the context layer isn’t updated in sync. Agents keep using the old definition. This is the most common pattern and the hardest to detect, because there’s no error state. The context is confidently wrong.
Cross-domain definition conflicts. Two teams define the same entity differently. Finance’s “active customer” uses a 90-day window; Sales’ “active customer” uses 30 days. When a multi-agent workflow draws from both domains, it resolves the conflict by picking the one definition its context layer happened to encounter first. The problem is, no one approved that resolution.
Semantic updates that don’t propagate. A dbt model is updated, but the business glossary isn’t (or vice versa). Semantic definitions drift out of sync across layers because there’s no mechanism to treat them as a unified versioned artifact. Each system maintains and propagates its own version of truth.
A single definition change propagates downstream to every agent consuming it. Without context lineage, there’s no audit trail — and no way to know which decisions were made on stale ground.
Each of these is manageable when humans are in the analytical loop. But when agents make autonomous decisions, they compound invisibly.
The versioning gap that must be closed — and how to do it
Permalink to “The versioning gap that must be closed — and how to do it”Data engineering teams have largely solved data lineage: modern stacks can trace which transformations produced a table, which sources fed it, and which assets consume it.
Context lineage is a different problem, and it isn’t yet solved. Almost no organization tracks who changed a definition, when, why, and which downstream agents or consumers were affected. Gartner predicts 80% of data governance initiatives will fail by 2027, citing the absence of clear accountability as the primary cause. The absence of context lineage is what makes accountability impossible to enforce.
The structural cause is that data lineage tools were designed to track data movement, not semantic drift. A column exists in a lineage graph, but its business meaning does not. When context drift surfaces as a bad outcome, root cause analysis has nowhere to start because there’s no audit trail for meaning.
How to close the versioning gap
Permalink to “How to close the versioning gap”Git-style version control for code tracks diffs, attributes changes to authors, and enables rollback. Context needs the same model applied to its semantic layer.
Specifically, four capabilities are required:
- Diffs — what changed between definition version A and B
- Attribution — who changed it, when, and under what approval
- Rollback — the ability to revert to a prior semantic state when agents downstream are behaving incorrectly
- Impact assessment — which agents, dashboards, or consumers were using the definition that changed
This is harder to build than it sounds. Business definitions live across multiple systems, including business glossaries, semantic layers, dbt annotations, catalog descriptions, and tool documentation. Versioning context requires treating all of these as a unified artifact, not as independent records. That infrastructure doesn’t exist out of the box in most stacks today. The tooling gap is real, and it’s where context drift accumulates undetected.
Why governing context is a prerequisite, not a wrapper
Permalink to “Why governing context is a prerequisite, not a wrapper”The standard governance model treats context management as a review layer applied after definitions are written. Definitions are authored, reviewed on a cadence, and approved for agents to consume them. In agentic environments, this model breaks. By the time a quarterly review surfaces a stale definition, agents have made thousands of decisions against it.
Governance needs to operate as a condition of access, not a wrapper around it. That means three things:
RBAC for definition changes: Who is permitted to modify which definition, with what approval chain? Without this, anyone can update a business term and the change flows silently to every agent consuming it.
Certification workflows: Definitions must be actively certified as current before agents consume them. Passive validity — “it hasn’t been changed, so it must be right” — is the assumption context drift exploits.
Conflict resolution protocols: When two domain definitions conflict, there’s a named process for resolving it before the conflict reaches an agent’s context window. This is where cross-domain drift most often becomes a production incident.
Gartner analyst Andrés García-Rodeja put the architectural principle plainly at the 2026 Data & Analytics Summit: by 2028, 60% of agentic analytics projects relying solely on MCP will fail due to the absence of a consistent context layer. The organizations in the other 40% are the ones treating context governance as infrastructure, not as a follow-up project.
A detection framework for context drift
Permalink to “A detection framework for context drift”Three signals are detectable before drift reaches production agents.
Three detection signals — automated consistency checks, cross-domain definition comparison, and usage anomaly signals — that surface context drift before it reaches a production agent.
Automated consistency checks. Compare semantic definitions across systems on a scheduled basis. If the definition in the catalog doesn’t match the annotation in the dbt model, surface the conflict at build time — not at runtime when an agent is already consuming it. This requires connecting the catalog to the semantic layer as part of the CI/CD pipeline, not as a separate governance process.
Cross-domain definition comparison. When two domains define the same entity differently, flag the divergence at the moment it appears — not when a multi-agent workflow collides with both definitions simultaneously. This requires a shared taxonomy layer that can detect when domain-specific terms have drifted from a canonical version.
Usage anomaly signals. When agent behavior on a given metric changes unexpectedly — query patterns shift, outputs diverge from baselines — route the investigation to the context layer first, not the model. Most teams invert this order and spend investigation cycles on model logs when the problem is upstream in the definition layer.
None of these require new AI infrastructure. They require instrumentation decisions made before agents ship.
Can’t data quality frameworks solve context drift?
Permalink to “Can’t data quality frameworks solve context drift?”You could argue that data quality frameworks already exist to resolve context drift. That’s partially right, but it misses the failure mode.
Data quality frameworks catch technical failures: null rates, schema mismatches, distribution shifts in raw values. They don’t catch semantic failures: a definition that is technically valid but no longer reflects business intent. A column with a 0% null rate and correct typing can still carry a definition that was accurate two product cycles ago.
Semantic drift is a different failure mode than data quality drift, and it requires a different layer of instrumentation. Conflating them is why many organizations are confident their data quality programs protect them from context-driven agent failures — until they don’t.
Your first three steps to avoiding context drift
Permalink to “Your first three steps to avoiding context drift”If agents are running against your enterprise data today, three moves matter in this order:
Audit your semantic sources of truth. Map where business definitions live: in which catalogs, dbt models, tool descriptions, documentation wikis. Then, identify the sources those agents are drawing from. Most organizations discover their agents are drawing from multiple conflicting sources with no reconciliation layer between them.
Instrument for staleness, not just correctness. Every definition in your context layer should carry a last_verified timestamp and a verified_by attribution. A definition that hasn’t been actively certified within your change cycle shouldn’t be available to production agents. Passive validity is the assumption context drift exploits.
Build drift detection into your agent evaluation harness. Before evaluating whether agent outputs are correct, evaluate whether the context it was given is current. Context validation before output validation. The evaluation order matters because a context failure looks like a correct output.
Enterprise context layers like Atlan’s address the propagation problem. Lineage, usage signals, and quality scores move automatically as the data environment changes. The organization must provide the accountability structure on top: named owners, certification workflows, and conflict resolution protocols before context reaches an agent.
What’s at stake with context drift
Permalink to “What’s at stake with context drift”Enterprise agents are now independently generating procurement approvals, scoring accounts, triggering outreach workflows, and making capacity decisions. That means the failure mode is the same as before, but the surface area is orders of magnitude larger.
Your agents will be as reliable as the context you give them. The context you gave them last quarter may no longer be the context your business is operating on today.
The organizations that treat context versioning and governance as infrastructure now — not as a follow-up after the agent is in production — will be the ones whose agents compound intelligence rather than erode it.
Share this article
