How One Bad Input Poisons an Entire Agent Chain (and the Fix)

Mostafa Dhouib·September 4, 2026·7 min read

How One Bad Input Poisons an Entire Agent Chain (and the Fix)

The short answer. A real system missed one document in its first step. That single wrong assumption was handed to the planner, which generated three subtasks that each inherited it, and their outputs became the input to the next stage. Five steps later the output had nothing to do with reality, and every individual step had reasoned perfectly. The fix touched no model and no prompt: each step was given the ability to reject a bad input rather than swallow it, and the cascading failure dropped by 82 percent.

Garbage in, garbage out is the version everyone knows. It undersells this badly.

In a multi-step agent system the garbage does not pass through. It compounds, and every step downstream treats it as settled fact and builds on it, adding weight and confidence at each stage. By the time anything surfaces, you are not looking at a wrong answer. You are looking at a structure built on one.

What actually happened

The first step missed one document. Just one.

That omission became a wrong assumption, and the assumption was handed to the planning step. The planner did its job correctly: it took the state it was given and generated three subtasks from it. Each of those three inherited the original mistake, because they were derived from it.

Their outputs became the input to the next stage. That stage reasoned correctly over what it received. So did the one after.

Five steps down, the output had nothing to do with reality. It was confident, well-formed, internally consistent, and completely wrong.

The part that unsettles people

Every single step in that chain was flawless.

The model did exactly what it was asked at every stage. It reasoned perfectly from beginning to end. Audit any individual step in isolation and it passes, because in isolation it was correct: given that input, that output was right.

The system was poisoned from a specific point, and after that point correct reasoning is precisely what propagates the error. A step that reasons well over corrupted input produces confidently corrupted output. Reasoning quality is not protective here. It is the transmission mechanism.

This is why the reflex fails so completely. A better model reasons better over the same poisoned state and produces a more convincing wrong answer. You do not get fewer failures, you get better-dressed ones.

Why nobody catches it in the middle

Two things conspire, and both are structural rather than careless.

Every step downstream treats what it receives as settled fact. There is no convention in most agent frameworks for a step to be suspicious of its input. Steps are written to do their job with what they are handed. Doing the job is the contract; questioning the input is not part of it.

Nobody goes back and checks the source. By step four, the original document is three transformations away and nobody knows which document it was. The chain has no provenance, so even a suspicious step has no cheap way to verify.

And there is a mechanism underneath that makes it invisible rather than merely missed. Look at a correct step and a poisoned step side by side in a trace. Same confidence, same clean formatting, same citation. The wrong step wears the exact uniform of the right one.

At the moment the model produced that step it may have been 51 percent sure or 99 percent sure. That difference existed briefly, inside the computation, and then the step was written down as text and the uncertainty was destroyed in the act of writing, because prose has no field for it.

So the instinct you were counting on, that something looks off, never fires. Nothing looks off.

The fix, and the number

We did not touch the model. We did not touch the prompts.

We changed the system so that every step could reject a bad input instead of accepting it and moving on.

That is the whole change, and the cascading failure dropped by 82 percent. Same model, same prompts, different system. That number is architecture, not intelligence.

What "reject a bad input" actually means

The phrase is doing more work than it looks, so here is the concrete version.

Preconditions on every step. Each step declares what must be true of its input for its output to mean anything. Required fields present rather than plausibly invented. Values inside ranges that are possible. Referenced entities that actually exist. Counts that match what an earlier stage claimed to produce. These are cheap assertions and they catch a surprising share of poisoned state, because a corrupted assumption usually violates something checkable a step or two later.

A refusal path that the orchestrator understands. A step needs a way to return "I will not proceed on this" that is not an exception and not a low-quality answer. Most agent frameworks make completion easy and refusal awkward, which is exactly backwards for reliability. If the refusal has nowhere to go, engineers stop writing refusals.

Provenance carried forward. Each piece of state travels with where it came from, so a check at step five can reach the original source in one hop rather than an hour. This is what makes verification affordable enough to actually happen.

Verification that is not the model grading itself. The check has to be independent of the thing it is checking, which rules out asking the same model whether the state looks right. Use a deterministic rule, a second source, or a property you can compute.

Contain it at the source

There is a design principle underneath the 82 percent that generalises past agents.

A failure that stops at the step that produced it costs you that step. A failure that propagates costs you everything downstream of it, and the cost grows with the length of the chain. So the value of a check is not uniform across the pipeline: a check at step one is worth vastly more than the same check at step five, because it prevents everything in between.

That inverts the usual instinct, which is to validate the final output. Validating the output tells you something is wrong after you have paid for the whole chain, and gives you almost no information about where. Validating at each boundary costs more checks and catches the failure while it is still cheap and still localised.

If you only get to build one check, build it at the earliest step whose output everything else depends on.

What to do on Monday

Take one multi-step flow and do four things.

Write down, for each step, what must be true of its input. Give each step a way to refuse, and make sure the orchestrator, the caller, and the queue all understand what a refusal means. Carry provenance with the state. And count how often a step would have refused if it could, which is usually the number that gets the work prioritised.

None of that is a model change, and all of it is available this week.

FAQ

Why does one small error ruin an entire AI agent run? Because every step downstream treats what it receives as settled fact and builds on it, so the error compounds rather than passing through. Correct reasoning over corrupted input produces confidently corrupted output, which means reasoning quality propagates the error rather than catching it.

Will a better model prevent an agent error cascade? No, and it usually makes the output more convincing. A stronger model reasons better over the same poisoned state and produces a more articulate wrong answer. In the real system described here, the fix used the identical model and prompts and cut the cascade by 82 percent.

How do I stop a bad input from propagating through an agent chain? Give each step preconditions on its input, a refusal path the orchestrator actually understands, provenance so a later check can reach the original source cheaply, and verification that is independent of the model producing the state.

Why doesn't anyone notice the error in the middle of the chain? Because the wrong step looks identical to a right one: same confidence, same formatting, same citation. The model's uncertainty is destroyed the moment the step is written down as text, since prose has no field for it, so the instinct that something looks off never fires.

Where should I put a check if I can only build one? At the earliest step whose output everything else depends on. A check at step one prevents the entire chain, while the same check at step five catches the failure after you have paid for everything before it.