We’re continuing our series on what really breaks when AI agents move from demos to production. In Part 1 we explored why agent-to-agent communication fails, and in Part 2 we looked at why the agent handoff fails, Part 3 takes us one layer deeper: what happens when an agent has the right information, but the wrong context?
A few months ago, I was digging into why some AI systems return completely convincing answers that turn out to be dead wrong.
The interesting failures aren’t obvious hallucinations. The tricky cases look airtight on paper: the document is real, the customer is real, the policy is accurate, and the text was interpreted faithfully. Yet the final output is completely broken.
The problem isn’t the data itself. The agent simply has the right information applied to the wrong context.
Think about cooking dinner
Imagine preparing a meal for friends. You have chicken, vegetables, rice, spices, and a recipe you’ve made dozens of times. Halfway through prep, someone mentions that one of the guests is vegetarian.
Nothing in your kitchen failed. The chicken was fresh, the recipe was solid, and your technique was fine. You just lacked a crucial constraint about the people you were cooking for, and that missing detail invalidates the rest of your plan.
Enterprise AI agents run into this constantly.
When a good RAG response isn’t enough
Suppose an employee asks an HR bot: “How much parental leave am I entitled to?”
The system queries the internal knowledge base, pulls a valid policy document citing 26 weeks, quotes it accurately, and references the source. It looks flawless.
Except the employee is based in another region, works on a contractor agreement rather than permanent staff, or the policy was revised last week and the search index hasn’t refreshed.
The document wasn’t fabricated, retrieval didn’t crash, and the model didn’t misread the text. The agent simply had no awareness of the situation surrounding the query.
We’ve gotten quite good at feeding documents into LLMs. What we haven’t nailed is ensuring that data applies to this specific user, task, and moment in time.
RAG answers “what looks relevant?”
Standard RAG follows a predictable loop: user asks a question, the engine retrieves matching snippets, feeds them into the prompt, and the model outputs an answer.
The weak point is semantic relevance.
A search index will easily identify an SLA document for a question about service levels. But that document might be superseded by an addendum signed six months later, an unindexed regional policy, or an active exception logged in Salesforce.
The document is semantically relevant, but operationally invalid for that specific scenario.
This is the third piece in a series I’m running, Things That Break When Agents Meet Reality. It’s about the engineering problems that only surface once agentic systems leave the demo and have to survive production.
Context is scattered across systems
In production environments, the data required to resolve a single interaction rarely lives in one place.
A routine customer query might pull identity from the CRM, subscription tiers from Stripe, negotiated terms from the contract repo, open tickets from Zendesk, historical usage from Snowflake, and real-time events from Kafka.
The agent doesn’t need a dump of everything, in fact, dumping raw state degrades performance. It needs the exact slice of state governing that specific decision.
Context goes stale
Systems drift out of sync all the time.
If a company shortens its cancellation window from 30 days to 14 days, the source database might update immediately while the vector store lags behind. The agent keeps quoting the 30-day policy. The model didn’t hallucinate, semantic search didn’t fail, and the pipeline ran as designed. The data was simply historically true, but currently false.
This creates a core infrastructure challenge: is a document valid because it matches search terms, or because it reflects the current operational state?
Basic metadata like created_at and updated_at rarely cuts it. Systems need fields like valid_from, valid_until, supersedes, source_system, and scope, because last updated and currently applicable are entirely different concepts.
Multi-agent compounding errors
This gets significantly messier across multi-agent workflows.
Customer Agent -> Pricing Agent -> Compliance Agent -> Execution Agent
Each service queries its own domain: the customer agent reads the CRM, the pricing agent checks billing tiers, compliance reads policy docs, and execution writes to the transactional database.
Each agent executes its sub-task correctly, but they might operate on mismatched snapshots of state. One sees a legacy plan, another reads an updated tier, and compliance applies an exception logged yesterday that the execution worker never receives.
By the end of the chain, nobody hallucinated, but the pipeline failed due to context fragmentation. It’s an insidious failure mode because every individual log looks green in isolation.
The missing source of truth
Enterprise systems frequently have conflicting definitions of basic terms.
If an account is marked Active in HubSpot, Past Due in Stripe, and At Risk in Zendesk, which one does the agent rely on?
A human operator knows that Stripe owns payment state while HubSpot owns account lifecycle. An LLM lacks that institutional intuition unless it is explicitly engineered into the pipeline.
Teams need clear ownership around business objects:
What the field represents
Which system owns authoritative write access
Update latency and sync schedules
Entity boundaries and constraints
Prompt engineering cannot fix underlying data governance gaps.
The handoff dilemma
When a research agent finishes a task and passes output to an analyst agent, what should that payload contain?
Passing the entire raw dialogue blows up the context window with conversational noise, token bloat, and stale assumptions. Conversely, sending a bare-bones summary drops critical constraints, source provenance, and workflow state.
Agent handoffs require intentional payload schemas: passing the exact state required for downstream decisions; nothing more, nothing less.
Engineering context assembly
For simple chatbots, context is just conversation history and a few retrieved chunks. For decision-making agents, context becomes an active assembly layer:
Before prompt construction, an assembly pipeline must resolve:
Time: Is the data current and actively enforced?
Entity: Does this rule apply to this specific account or tier?
Authority: Is this the definitive system of record for this attribute?
State: What prior steps and mutations occurred in this session?
Permissions: Does the user/agent have authorization to view this data?
Provenance: Can we trace the origin of this assertion?
These are traditional data engineering patterns applied upstream of LLM orchestration.
Bigger context windows won’t solve this
Expanding context windows to millions of tokens doesn’t eliminate the need for curation.
Giving a model an unfiltered firehose of internal data introduces conflicting policies, outdated records, noisy intermediate reasoning, and distraction. The engineering challenge isn’t how many tokens a model can swallow; it’s how reliably we assemble the exact state required for a specific decision.
The evaluation split
When an agent takes the wrong action, the default reaction is to blame model reasoning.
In reality, agent evaluations need to decouple two distinct questions:
Reasoning Quality: Did the model reach a sound conclusion based on the payload provided?
Context Quality: Did the orchestration layer supply the correct, authoritative state in the first place?
If the reasoning failed, you tweak the prompt, model, or tool definitions. If the context was wrong, no amount of prompt tweaking will prevent the failure.
Why this matters for action-taking agents
When an agent just generates text, bad context produces bad copy. When an agent has write access, bad context triggers bad transactions.
A refund bot might look up the right policy, calculate the correct amount, and match the customer record, yet execute a duplicate payout because it lacked visibility into a refund processed ten minutes prior.
At that stage, context management becomes part of the system’s operational control plane.
Rethinking RAG
RAG isn’t going anywhere, but its role needs reframing.
Moving from simple document search to context assembly means pulling simultaneously from vector indexes, transactional APIs, event buses, state machines, and access control layers.
RAG provides reference material. Context provides the operational situation.
See you in Part 4, where we'll look at why your agent can pass every evaluation and still fail in production.
One request:
Your answers will directly shape the next quarter of AgentBuild issues. This isn’t a formality - I’m genuinely building the next stretch of this newsletter around what you tell me. I don’t want to make assumptions. Tell me what you want to learn.
👉 Take the survey here
Thanks for reading,
Sandi
P.S. If you’re new here - welcome 🎉. AgentBuild is a community of practitioners working through the real challenges of getting AI into production inside large organisations. Every week I share practical, grounded thinking from the people doing this work at the sharp end. The goal is never theory - it’s always: what can you use Monday morning.
Ask your friends to join.
More valuable content coming your way.