Agents in production: what looks like a reasoning failure is usually a context failure

Your agent isn't hallucinating. It's reasoning correctly over the wrong inputs.

Here's a failure every team running agents in production has seen some version of. An alert fires. The agent investigates: pulls metrics, checks recent deploys, scans the logs, proposes a fix. The fix is wrong, confidently, articulately wrong. The postmortem instinct is to blame the model: it hallucinated, it reasoned badly, we need a better prompt, maybe a better model.

Then someone actually reconstructs what the agent saw. The metrics query returned a five-minute-old aggregate because the vendor API caches. The deploy list was fetched before the relevant deploy landed and was never re-fetched. The log window was truncated at 1,000 lines by a default nobody set deliberately, and the line that mattered was number 1,014. Given those inputs, the agent's conclusion was reasonable. It debugged the incident it could see. That just wasn't the incident that happened.

This is the oldest law in computing, wearing a new costume: garbage in, garbage out. But agents give GIGO a twist that makes it more dangerous than it was for any previous generation of software. A dashboard shows you the garbage; a human looks at a stale chart and might notice the timestamp. An agent consumes the garbage silently and then acts on it, with fluent, well-structured reasoning layered on top. The output doesn't look like garbage. It looks like a plausible investigation with a confident conclusion. Confidence is the dangerous part.

Why is this surfacing now?

For the chatbot era, context was mostly a retrieval problem over documents. If the retrieval was mediocre, the answer was mediocre, a human read it, and the cost was a shrug. Three things changed when agents moved into production.

First, agents act. An agent that reads a stale metric doesn't produce a slightly-off paragraph; it restarts the wrong service, or opens a PR against the wrong config, or pages the wrong team at 3 AM. The cost of a context failure went from cosmetic to operational.

Second, the input surface exploded. A production agent doesn't read one corpus. It reads metrics from one system, logs from another, deploy history from a third, tickets and chat from a fourth and fifth, plus its own notes from previous runs. Every one of those is a separate fetch, with its own latency, its own rate limits, its own caching behavior, its own idea of time. The agent's picture of the world is assembled, per investigation, from a half-dozen partial snapshots taken at slightly different moments while the assembly takes place inside the model's reasoning loop, where nobody can inspect it.

Third, errors compound. A single-shot answer over slightly-wrong context is slightly wrong. A twenty-step investigation, where step three's conclusion becomes step four's premise, turns a small input error into a confidently wrong remediation. Multi-step agents don't average out input noise; they amplify it.

Put those together and you get the pattern in the title. Teams observe an agent failure, file it as a reasoning failure, and reach for model-side fixes: a bigger model, a longer prompt, more instructions about being careful. The failure was upstream of the model the whole time.

A taxonomy of context failures

It's worth being concrete about what "bad context" actually means, because it's rarely as obvious as wrong data. In practice, it's one of five things.

• Stale. The data was true when it was fetched, and the world moved. Caches, polling intervals, and eventual consistency all manufacture staleness. The agent has no way to know its snapshot is old. Freshness is a property of the pipeline, not of the payload.
• Partial. Pagination limits, truncated log windows, rate-limited retries that silently gave up. The agent reasons over what arrived and cannot reason over what didn't. Absence of evidence reads as evidence of absence.
• Unordered. Events from six systems, each with its own clock and its own delivery delays, interleaved incorrectly. Causality inverts: the deploy appears to follow the errors it caused.
• Lossy. Somewhere in the pipeline, a transformation threw information away as every transformation does. Embeddings drop exact identifiers, timestamps, and word order. Summarization drops whatever the summarizing model judged unimportant, which is precisely the judgment you built the agent to make. Extraction into entities and relations drops everything that didn't fit a predefined shape. Aggregation drops the individual events. None of these are bugs; they're what those transformations are for. Each one makes data easier to query by making it less true. Stack two or three of them, as most agent pipelines do, and by the time the model reads its context, it's reading a paraphrase of a summary of a sample.
• Unattributed. The agent can't tell where a piece of context came from, when it was captured, or what produced it. Two contradictory data points arrive with equal apparent authority, and the model picks one.

Notice that not one of these is a model problem. A better model reasons more elegantly over the same stale, partial, disordered, lossy, unattributed inputs and arrives at the same wrong conclusion with better prose.

"Just wait for bigger context windows"

The standard objection: models are improving fast, context windows are now in the millions of tokens, so pipe everything in raw and let the model sort it out. Attention is all you need; engineering the context is a temporary crutch.

Three problems with that.

1. Long context degrades. The empirical record here is consistent: models attend unevenly across long inputs, and facts buried in the middle of a large context are recalled far less reliably than facts at the start or end (the "lost in the middle" effect documented by Liu et al.). More recent multi-model testing shows the broader phenomenon, now usually called context rot: accuracy on even simple tasks drops as input length grows, across every frontier model tested (Chroma's context-rot study ran the comparison across 18 of them). A million-token window is not a million tokens of reliable attention. Dumping six systems of raw telemetry into the window doesn't give the model more truth; it gives it a haystack and a token bill.
2. Cost scales with tokens. Every token of context is paid for on every reasoning step. For an agent that runs hundreds of investigations a day, "just send everything" is a unit-economics decision, and a bad one. Selection (i.e., sending the right events, not all events) isn't a workaround for weak models; it's what keeps the product margin-positive.
3. And most fundamentally: the window can't fix what never arrived. Freshness, completeness, ordering, and provenance are properties of the systems that collect and deliver the data. No amount of model capability recovers the log line that was truncated upstream, un-stales the cached metric, or restores the fields the embedding dropped. The model reasons over what it's given. What it's given is a systems problem.

Context engineering is a systems discipline

This is why "context engineering" has displaced "prompt engineering" in how serious teams talk about agents, a shift you can watch documented in the engineering blogs of the major labs. Anthropic's guidance on the subject treats context as an engineering problem in its own right, curating what enters the window, not just wording it well.

But even that framing is often applied narrowly, to mean packing the window: what to include, what to compress, what to move into tool descriptions. That's the last mile. The discipline is bigger, and it looks less like writing and more like data infrastructure.

Engineered context has verifiable properties. It is complete over a defined window, e.g., the agent gets everything about service X in the last 30 minutes, and "everything" is a guarantee, not a hope. It is fresh, with staleness measured and visible rather than accidental. It is ordered, on one clock, so causality survives. It is lossless where it counts — structured and typed so it's cheap to query, but with the original records preserved, because you don't know at ingest time which detail the investigation will hinge on. And it is attributed so that every piece of context is traceable to a source and a moment.

There's a sixth property that only matters after something goes wrong, which is exactly when it matters most: replayable. When an agent takes a bad action in production, the postmortem question is not "why did the model say that?", it's "what did the model see?" If the pipeline that assembled the context was a pile of live API calls, the answer is unrecoverable: the vendor APIs have moved on, the caches have rotated, the aggregates have re-aggregated. You cannot replay what you threw away. Teams that treat agent context as a durable, ordered record can reconstruct any investigation after the fact. Teams that treat it as ephemeral fetches are doing forensics on a crime scene that no longer exists.

The uncomfortable summary

The industry has spent two years making agents better at thinking and almost no time making sure they're thinking about the right thing. That ratio is inverted. The models are already good enough to be dangerous when fed garbage: fluent enough that the garbage is invisible until the postmortem.

So the next time an agent fails in production, run the cheap experiment before reaching for a bigger model: reconstruct exactly what it saw, then ask whether you'd have done better with the same inputs. Most of the time, the honest answer is no. What looks like a reasoning failure is usually a context failure… and context failures are fixable, with engineering, today.

That's the problem we're working on at NavFlow: giving production agents one read path that is complete, fresh, ordered, lossless, and replayable so the model's reasoning is the only variable left. If you're running agents against real systems and feeling this gap, I'd like to show you how NavFlow can help: cal.com/ashishbagri/navflow.