The context carries the failure
A model makes one wrong calculation. Its next answer uses that value. The next answer uses the next value.
Correct the original mistake after that chain exists. What happens?
That question drives my working paper, The Context Carries the Failure. The experiment isolates execution on a small deterministic task, where the correct answer can be computed directly.
A ledger with a known answer
The task is a ten-step integer ledger. Each turn gives a small operation and asks for the running total. Ground truth comes from code. No model judges another model's answer.
I tested Qwen2.5-3B-Instruct, Qwen2.5-7B-Instruct, and Llama-3.2-3B-Instruct locally with 4-bit quantization. Three models, from two model families.
A clean-history condition corrects slips before the next turn. Another condition inserts an incorrect value into the history. The later operations stay the same.
This lets me ask whether an incorrect value changes subsequent execution, with the rest of the task held fixed.
Two repairs that sound similar
The important comparison comes after the mistake has propagated:
- Correct only the original incorrect value.
- Correct every incorrect value, including the model's later descendants of that mistake.
In the tested setting, correcting only the original slip left the later failure largely intact. Correcting the full contaminated history restored the clean-history baseline.
The later wrong answers had become part of the context. Editing their ancestor did not remove them.
That supports a behavioral claim about the tested task: the failure is carried by removable context content. It does not identify an attention head, a circuit, or a training mechanism.
Check whether editing itself caused the result
Context editing is an intervention. It needs a control.
The harness checks the editing machinery separately, so a difference cannot simply be credited to rebuilding the prompt. It also tests error-aware instructions. Telling the model to watch for mistakes did not recover the contaminated baseline in these runs.
One planned dose-response check was uninformative: even the smallest injected error produced a near-ceiling effect. The draft discloses that. Passing the main comparison does not make every secondary test informative.
An instrument is not a deployable fix
The scrubber knows the correct ledger values. A real agent usually does not have an oracle that can identify every bad step.
The result therefore does not ship an automatic repair system. It gives a narrower engineering hypothesis: when rolling back a failed run, also examine the outputs and summaries derived from the failed step.
That hypothesis needs testing on real workflows. This study covers short ledgers, greedy decoding, and small quantized models. Code tasks, long projects, and proprietary frontier models remain outside its measured scope.
The useful distinction is already concrete: correcting an earlier message and removing everything that grew from its error are different operations.