Error Propagation

In one line: a downstream agent has no way to know its input was wrong, so it reasons impeccably from a false premise and everything after it agrees.

Why this is worse than it sounds

In a single agent, an error is one bad step in a trajectory, and a later observation may contradict it.

In a pipeline, an error becomes an input. The receiving agent treats it as established — it arrived from a trusted component, in a structured message, with no indication of doubt. So the agent does not evaluate it; it builds on it.

And because each subsequent agent is reasoning correctly, the output is coherent. There is no seam, no contradiction, nothing that looks wrong. A system that produces internally consistent nonsense is much harder to catch than one that produces something obviously broken.

Published work measuring this finds that uncoordinated designs amplify errors substantially, while centralised designs with a validation step contain the amplification to a much smaller factor. The important part of that result is not the exact multiplier — it is that the architecture, not the model, determines how far an error travels.

The three shapes

Worth distinguishing, because they need different containment.

Factual propagation. A wrong value — a date, a figure, a name — carried forward and used. The most common, and the most tractable, because facts are often checkable.

Assumption propagation. An unstated interpretation. The first agent assumed the user meant one thing; nothing downstream questions it, and the whole output answers the wrong question. Harder, because there is no wrong value to find — everything is correct given an assumption nobody surfaced.

Framing propagation. The first agent's decomposition constrains everything after. If the supervisor split the problem badly, every worker does its part correctly and the assembled result is wrong. This is the specification failure from the previous lesson, seen from the other end, and it is the hardest to detect because no individual output is defective.

That third one has an uncomfortable implication: the supervisor's error is unfalsifiable from inside the system. Every worker reports success, the critic checks each output against its sub-task and passes it, and the assembled answer is wrong. Nothing in the pipeline is positioned to notice.

Containment

Four mechanisms, in order of how much they help.

Validate at the boundary. Every handoff is checked against its schema and, where possible, its content. A date that is not a date, a figure outside a plausible range, a citation that does not resolve — these are cheap to catch and they stop the most common shape at the first hop.

Carry confidence, and let it degrade. A result derived from a low-confidence input should not be reported as high-confidence. Propagating confidence alongside the result — and reducing it as it passes through inference — means the final output carries some signal about how much of it rests on uncertain ground.

Verify against the goal, not the sub-task. At least once, something must check the assembled result against the original request. This is what catches framing propagation, and it is the check most designs omit because every component already reported success.

Bound the depth. Each hop is an opportunity for compression loss and error amplification, so a shallow pipeline is more reliable than a deep one — which is the same argument as preferring wide-and-shallow topologies, arriving from the reliability side rather than the latency side.

The independence illusion

A specific trap worth naming, because it looks like a mitigation and is not.

Running the same sub-task through several agents and comparing looks like redundancy. It is not, if they share the same input, the same model and the same prompt — they will make correlated errors, agree with each other, and the agreement will be read as confirmation.

Genuine redundancy requires genuine independence: different inputs, different prompts, or different models. Otherwise the ensemble is one opinion, expensively repeated, with false confidence attached.

This is the same point as the debate topology needing an independent first round, and the same one as consolidating memory on repetition rather than a single instance. Correlated observations are one observation.

When to stop and ask

The escalation decision, and it is a design choice rather than an implementation detail.

An error detected mid-pipeline can be handled three ways. Retry the failing worker, which helps for transient problems and not for specification ones. Replan from the supervisor, which handles a bad decomposition and costs the work done so far. Escalate to a human, which is correct when the failure is ambiguity about what was wanted.

The rule worth stating: retry once, replan once, then escalate. A system that retries indefinitely burns its budget on a problem that is not going to resolve, and one that never escalates converts a two-minute clarification into a wrong answer delivered confidently.

What to log

Because attribution after the fact depends entirely on what was recorded at the time.

Each handoff, with its full content. Each validation result, including the ones that passed. Each confidence value as it propagated. And the mapping from final output back to the sub-results that produced it.

That last one is what makes a wrong answer diagnosable rather than merely regrettable — and it is the subject of a later lesson, because doing it well is harder than it sounds.

Next: the component that checks the work.