Agent Memory Contamination: How One Bad Tool Response Poisons a Whole Session

Your agent completes 80% of a multi-step research task correctly, then confidently delivers a conclusion that's completely wrong. You trace back through the logs and find the culprit at step three: a tool call returned stale data, the agent integrated that data as fact, and every subsequent reasoning step built on that poisoned premise. By the end of the session, the agent was correct about everything except the thing that mattered.

This is agent memory contamination — and it's one of the most insidious reliability failures in production agentic systems. Unlike a crash or timeout, it produces a confident wrong answer. Observability tooling records a successful run. The user walks away with bad information.

How LLM Agents Accumulate and Trust Working Memory

An LLM agent maintains state through its context window. Every tool response, every observation, every intermediate conclusion gets appended to a growing conversation buffer. This buffer is the agent's working memory, and it has a critical property that makes contamination dangerous: everything in it carries implicit trust.

When a language model processes its context window, it doesn't weigh recent tool outputs against earlier ones using explicit credibility scoring. It treats the entire context as evidence for its next reasoning step. A tool output that says "User account balance: $47,200" in turn three shapes how the agent interprets every financial query for the rest of the session — without the model actively choosing to trust it.

Research on agent failure modes confirms this pattern. A systematic analysis of 13,602 production issues across 40 open-source agentic repositories found that "Perception, Context & Memory" faults accounted for 72 distinct failure types, second only to runtime errors. The common thread: agents that correctly execute tool calls but misintegrate the results into their belief state, creating downstream errors that cascade silently.

The contamination propagation has three directions. It spreads temporally within a session as the agent builds on its flawed premise. In multi-agent systems, it spreads laterally when agents share memory stores, and persistently when session memories get written to long-term storage and retrieved in future sessions.

The Anatomy of a Poisoned Session

Consider a financial agent tasked with generating a quarterly summary. At step three, it queries an exchange rate API that returns a cached, day-old rate. The agent has no signal that this rate is stale — the response was well-formed, the HTTP status was 200, and the value is plausible. It stores the rate, converts several subsequent figures, and builds a narrative around the results.

By step twelve, the agent is generating charts and recommendations based on compounded errors. Each step was locally reasonable; the failure was in what got accepted at the boundary.

This is the experience-following property gone wrong. Empirical research on LLM agent memory management shows that when flawed observations get stored and reused, the agent replays misaligned experiences as if they were ground truth. The agent doesn't just use the bad data once — it keeps reaching for it as supporting evidence.

Three failure modes are worth distinguishing:

Factual staleness: Tool data was once correct but is now outdated. The agent can't detect this without external timestamps or explicit TTL metadata.

Schema misinterpretation: A tool returns a field named balance that means available credit, not total balance. The agent reads it correctly according to the JSON but reasons about it incorrectly according to the domain.

Adversarial injection: A tool response contains hidden instructions embedded in legitimate-looking content. The model processes the instruction as part of its context, updating its behavior in ways the operator didn't intend.

The third vector has received increasing scrutiny. Research on indirect prompt injection shows that content fetched by the agent — web pages, documents, API responses — can carry embedded directives that redirect the agent's behavior mid-session. A tool call to retrieve a user document becomes a vector for injecting instructions that the agent will follow for the rest of the conversation.

Empirically, the reliability degradation from these compounding errors is substantial. Long-horizon agent task success rates drop from 76.3% on short tasks to 52.1% on extended ones — a 24-point decline that accelerates non-linearly. Contamination is a primary driver: once a wrong belief enters context, subsequent steps have positive error correlation rather than independent failure rates.

The Validation Layer That Most Teams Skip

The standard response to bad tool outputs is better tool documentation. That helps at design time but does nothing at inference time when a tool returns an unexpected value. What actually limits contamination is a tool output validation layer that runs before results enter the agent's context.

The minimum viable version of this layer has three components:

Schema enforcement: Every tool response should validate against a declared JSON schema before the agent sees it. This catches malformed outputs, unexpected nulls, missing required fields, and values outside expected ranges. It won't catch semantically wrong-but-structurally-valid data, but it eliminates a large class of accidental errors.

Source metadata tagging: Attach provenance to every tool result before it enters context — which tool returned it, when, with what HTTP status, and whether the data carries an explicit expiration. A well-formed context includes not just the result but a brief header the agent can query when forming conclusions. Agents given explicit staleness signals make significantly better calibration decisions than those given raw outputs.

Plausibility bounds checking: For numeric and categorical outputs, define acceptable ranges at tool registration time. An exchange rate that moves 40% in an hour should trigger a flag. An account balance that went negative since the last check warrants a re-query before the agent proceeds. These bounds don't need to be tight — they need to catch the values that are implausible enough to warrant a second look.

This isn't sophisticated engineering. It's the same input validation that every API boundary enforces in traditional software. The discipline breaks down in agentic systems because tool outputs feel like internal data once they're in the agent's context — but they're not. They're boundary inputs with all the reliability characteristics of external calls.

Session-Scoped Fact Checking: Detecting Contradictions in Flight

Validation at ingestion catches structurally bad outputs. A separate problem is detecting when the agent's accumulated belief state has become internally inconsistent — when one tool result contradicts another from earlier in the session.

The most practical approach is a consistency monitor that runs after every N tool calls and scans the working memory for logical contradictions. This doesn't require a complex inference engine. A targeted prompt to a secondary model checking "Given what you've established so far, does this new observation contradict any prior conclusion?" adds roughly one LLM call per checkpoint and catches a meaningful fraction of contamination events before they compound.

For numeric data specifically, maintaining a simple running state table of key variables — accounts, balances, user IDs, timestamps — and verifying that new values don't violate continuity constraints catches another class of errors that the model itself might not flag. An agent building a timeline shouldn't accept an event dated before a precondition that's already been established.

Multi-agent fact-checking architectures go further, using dedicated reasoning agents whose sole job is to evaluate logical and causal consistency of accumulated claims. The overhead is proportional to session length and criticality — a one-shot query agent doesn't need this; a multi-day planning agent building on accumulated research does.

Containing Blast Radius: Resets and Pruning

Even with validation and consistency checking, some contaminated sessions will slip through. The defense-in-depth question is: when contamination is detected, how do you recover without losing the entire session?

The key insight from transaction-based approaches like SagaLLM is that agent sessions can support compensating actions — steps that undo or quarantine the effect of a bad observation without requiring a full restart. This requires that the agent's state transitions are logged with enough granularity to identify where the bad data entered and what conclusions depended on it.

Concretely: each tool call gets a unique identifier, each subsequent belief that references that tool call gets tagged with a dependency, and when contamination is confirmed, the agent can prune not just the bad result but all beliefs that derived from it. This is more aggressive than it sounds in most sessions — a factual error at step three typically propagates into only a subset of the subsequent reasoning chain. The rest of the session can be preserved.

For cases where pruning is impractical, scheduled context checkpoints are an effective fallback. Rather than allowing sessions to accumulate unbounded working memory, the agent periodically summarizes validated conclusions into a condensed snapshot and starts fresh from that snapshot. This doesn't eliminate contamination — a bad result that makes it into the checkpoint persists — but it prevents indefinite compounding and reduces the attack surface for long-running sessions.

Observation masking has emerged as a surprisingly effective complement to summarization. Rather than including full tool outputs in the ongoing context, the agent operates on structured observation headers with the full output available but not pushed into the primary context window. This cuts memory cost by more than 50% in practice and limits how deeply a single bad output can entangle itself with subsequent reasoning.

What This Means for System Design

The operational implication is that tool outputs should be treated with the same distrust as user inputs. This isn't the default mental model for most teams building agentic systems, where the tools are internal and the data sources are controlled.

But "internal" doesn't mean "correct." Internal APIs return cached data, encounter race conditions, and fail partially in ways that produce plausible-but-wrong responses. When a tool is consumed by a human, the human's domain knowledge provides a cross-check. When the same tool is consumed by an agent, that cross-check is absent unless you engineer it in.

The architectural decisions that matter most:

• Every tool should declare its output schema and the agent runtime should validate against it before the result enters context.
• Tool responses should carry explicit freshness metadata, and the agent's context should surface that metadata when the agent reasons about time-sensitive conclusions.
• Sessions that exceed a threshold length should trigger mandatory context pruning or checkpointing, with the pruning logic aware of dependency relationships between observations.
• High-stakes outputs should require explicit re-verification — a second tool call or a cross-check against a different source — before the agent acts on a conclusion that involves irreversible actions.

None of these are novel. They're the defensive engineering practices that already govern how microservices handle external data. The novelty is applying them to the context window as a trust boundary, not just to the output the agent delivers at the end.

An agent that validates its tool outputs, monitors its accumulated beliefs for consistency, and has a pruning strategy for contaminated state is qualitatively more reliable than one that treats its context as ground truth. The 24-point reliability gap between short and long tasks isn't inevitable — it's largely a product of architectural choices made before the first tool call runs.