Common AI context failure modes
What you will learn in this module
Five structural context failures behind common enterprise AI analytics errors
The impact and implications each failure has on the business
What controls you can put in place to reduce each failure
Failures that may never raise an error
When an AI analytics system returns a wrong number, your first instinct is to blame the model’s ability to translate text-to-SQL. However, the model’s technical ability is rarely the source of the problem. Modern models write syntactically valid SQL reliably, and while they can still get a join or a date filter wrong, the errors that reach your executives usually come from somewhere else: context that is missing, stale, buried in noise, dropped mid-conversation, or ungoverned.
These errors are often hard to catch because they happen quietly. Where a syntax error stops the query and initiates an investigation, a structural context failure may return a clean result set, a well-formatted chart, and an answer that seems plausible based on past results. This miscalculation doesn’t show up as an error message, so business users who aren’t as familiar with the data won’t take a second look.
Anthropic shared a clear example of this concept. Connected naively to the warehouse, Claude was right about 21% of the time. Months of context engineering took it to roughly 95%, but as soon as that context started to drift, accuracy degraded again. The model did not change. The context did.
If no one monitors these failures, these incorrect answers can take root in your business, becoming the foundation for quarterly planning and goal setting, customer communication, and investor strategy sessions. That’s why it’s critical that you are aware of these failure modes and create stop-gap strategies to prevent them in the first place.
Semantic mapping failure
Business terms remain ambiguous until someone maps them. “Active users” can mean logged in, transacted, or engaged. “User” can mean an account, a seat, or a person. Two teams calculating MRR can land on different numbers depending on how each handles discounts, delinquent subscriptions, and currency conversion.
When several plausible tables or columns could answer a question, an agent that has not been given the map, or been pre-configured to ask, will use its reasoning to pick the statistically likely candidate. The resulting query will run cleanly and may answer a different question than the one you asked. The Anthropic write-up names this as the most common failure in enterprise deployment: the agent cannot map a high-level concept to one correct table, column, and metric definition, usually because several candidates look equally plausible.
Picture a revenue question asked on the last day of the quarter. Your warehouse holds rev_booked, rev_recognized, and a Salesforce-sourced opportunity_amount: bookings, recognized revenue, and pipeline value. Only one matches what your CFO means, and without an explicit definition, the agent chooses for you without flagging that it chose.
The control here is an explicit semantic definition: name the authoritative table, column, and metric for each business concept, and deprecate the other candidates visibly — often through a reviewed query.
Silent context decay and drift
Context describes a data model that keeps moving. A schema changes. A team renames a column. Finance revises how ARR is calculated. The documentation and business rules your AI system relies on now describe the old shape.
Some of those changes announce themselves. For example, if you drop an essential column, the query fails. The more dangerous changes leave queries executable while quietly changing what the results mean. A revised ARR calculation breaks nothing structurally, so the agent keeps executing against outdated business logic with undiminished confidence, and the accuracy loss shows up as a slow decline in trust rather than as an incident.
In the Anthropic case study, when documentation drifted from the underlying data model, query accuracy dropped from about 95% to about 65% in a single month. There were no changes to the model or the raw data.
Drift detection is the solution. However, a schema check alone will not deliver it. Give each context artifact an owner and a last-verified date, check it automatically against the live schema where you can, and put the definitions that no schema check can see in front of a human on a schedule.
Key takeaway
Watch answer accuracy alongside your error rates, not in place of them. Several of the failure modes return a well-formed answer and no error at all.
Context bloat and the more-data fallacy
Faced with an accuracy problem, the tempting fix is volume: load the historical queries, the notebooks, and the dashboard definitions into the context window on the theory that the answer is in there somewhere.
There is evidence that pushes against this instinct. When Anthropic granted the agent direct access to thousands of historical SQL query logs, accuracy shifted by less than one percentage point. Anecdotally, other leaders, like ARM, have described little improvement, and even declining performance, when more context is uploaded.
In reality, loading more context can end up costing you. In the Lost in the middle evaluation, model performance often dropped when the relevant information sat in the middle of the input rather than near either end, so a definition that matters can become harder to use once it is surrounded by a thousand queries that do not.
Query logs are valuable. They can help point out context gaps and decay. But providing query logs to the model in bulk at question time is a different and ill-advised move. The same logic applies to other context sources. In this case, less can be more as long as you ensure the context you share is high quality and adds strategic value.
Unbounded constraints and state degradation
You won’t see this failure in single-question analytics. However, it shows up clearly when you use AI in complex, multi-step agentic work, where a conversation runs long enough that the window has to be managed.
Three things go wrong:
As a thread approaches its context budget, the application’s truncation policy may drop instructions you stated early, so a constraint you set at the start stops applying unless it is reinforced.
The model’s truncation policy makes this decision based on context position rather than relevance. In the case where a system rule or a schema constraint is dropped, the model works to navigate a boundary it can no longer see.
Across sessions, an agent loses the decisions it already made unless the application stores and reloads them. In this case, repeatability declines. The same question you asked and received a correct answer for yesterday may be wrong today.
Treat state as architecture rather than as a side effect of the window. Persist what has to survive the conversation in a durable store, using patterns like a transactional layer for agent state alongside tracing to record what the agent actually did across steps. Then configure the application to retain or reinsert the non-negotiable rules after compaction, test that it does, and enforce the authorization boundaries outside the model entirely.
Ungoverned context and evaluation blind spots
The final failure mode is a governance failure, with two distinct risks.
1. Security and access controls
Context should never create a path around the access controls enforced by your enterprise data layer. If a retrieval store, cache, semantic layer, or connected application serves context without preserving the row-level, column-level, and role-based controls of the underlying system, users may gain access to information they are not authorized to see, including sensitive or personally identifiable information.
Every copy and representation of context must inherit the same access policies as the source. You cannot assume those controls automatically travel with the data.
2. Context governance and evaluation
Context is constantly evolving. Teams add sources, refine definitions, update business rules, or introduce new examples to improve an answer. The problem is that a change that improves one question can unintentionally degrade many others.
Without a repeatable evaluation framework, teams typically validate changes against only the handful of questions that triggered the update. Regressions remain invisible until users discover them in production.
Context changes should therefore be treated like code changes. Every material change should be tested against a fixed evaluation suite of representative questions and known-good outcomes. Performance should be compared before and after the change, and releases should be gated based on measurable results across accuracy, security, and other relevant quality dimensions.
Without systematic evaluation and monitoring, there is little evidence that a context change improved the system beyond the specific question it was intended to fix.
Go deeper
Read Effective context engineering for AI agents for a practical treatment of curating, compacting, and structuring what enters a context window.
Where this leads
Look at the six controls together, and a pattern appears. Explicit mapping, drift detection, curated retrieval, managed state, inherited access controls, and gated evaluation are not one-time fixes. Each supports a stage of a wider lifecycle.
Context degrades wherever that lifecycle has a gap. The next module organizes that work into four stages: build, govern, adapt, and publish.
Key takeaways
Structural context failures, not SQL generation failures, cause most enterprise AI analytics errors, and they tend to arrive formatted and confident with no error to investigate.
Ambiguous business terms and stale definitions are two of the most common causes. Explicit definitions, named owners, and scheduled verification reduce both.
Relevant curated context beats bulk. Mine your query logs for definitions rather than handing them to the model whole.
Every copy of context must inherit the access controls of its source, and every context change should pass a fixed evaluation suite before it ships.