What Happens to an Architectural Decision After Ten Agent Turns

We have been benchmarking the easy case

Most coding-agent evaluation looks the same. Give the agent an issue, let it produce a patch, run the tests, score it. That shape has driven real progress, and on that shape the agents have become genuinely good.

It is also the case that almost never occurs in production. Real development is a trajectory. A requirement arrives, then another that partially contradicts it, then a refactor, then a decision made four weeks ago that nobody restates, then a handoff to a different engineer or a different agent. The question that matters is not whether an agent can satisfy one instruction. It is whether an architectural decision made in round one still governs behaviour in round ten.

Three 2026 benchmarks now measure something close to that question, and the results converge.

Performance degrades across persistent rounds

EvoCode-Bench is the closest available proxy. It evaluates coding agents across 26 tasks spanning 227 sequential rounds, five to fifteen rounds each, in five domains including build systems, data engineering, and cloud and security work.

Three design choices make it relevant. The workspace persists, so code and decisions from round one are still present at round fifteen. Specifications evolve, and some new instructions deliberately conflict with earlier assumptions. Testing is cumulative, so every round is scored against all accumulated requirements rather than only the newest one.

Only two of the evaluated agents exceed half of the available multi-round credit. The failure profile is the more useful result. Weaker agents drop early requirements. Stronger agents get further and then fail on conflict resolution, self-correction, and regression management in later turns. Capability does not remove the problem. It relocates it.

Working code can still be deteriorating code

SlopCodeBench asks a different question: what happens to the codebase itself when an agent repeatedly extends its own prior output under evolving requirements.

Structural erosion increased across 80% of trajectories, and verbosity across 89.8%. The finding worth sitting with is the one about prompting. Asking for cleaner code improved the starting state and did not prevent the subsequent decline. Better instructions moved the intercept. They did not change the slope.

This is the empirical shape of a claim that is otherwise easy to dismiss as vendor talk. Functional correctness and architectural health are separate properties, and an agent can satisfy the first while steadily degrading the second.

The repository is not the whole handoff

There is a reasonable objection to all of this. If context is lost, the next agent can simply read the code. The repository is the source of truth.

Handoff Debt tests that assumption directly. It interrupts an agent at deterministic handoff points, freezes the repository, and hands the work to a successor under four conditions: repository state only, raw trace, summary notes, and structured notes. From 75 source tasks it generates 181 handoff-point tasks and 724 takeover runs per successor model, across three successor models.

Handoffs that carry context reduce median agent events by 20% to 59% and cumulative prompt tokens by 42% to 63% compared with repository-only takeover. The successor can read the code either way. Reading it is expensive, and some of what the predecessor knew is not recoverable from the files at all.

State that matters to the next contributor exists outside the artifact. That is worth stating plainly because so much agent tooling assumes the opposite.

Three failures that look identical from outside

When an agent violates an architectural decision, the post-mortem usually stops at "it lost context." That description covers three distinct failures with three distinct fixes.

• Availability. The decision is not recorded anywhere the agent could reach. Fixed by writing it down.
• Retrieval. The decision exists but was not surfaced for this particular change. Fixed by relevance selection.
• Enforcement. The decision was recorded, surfaced, and read, and the agent still produced a violating implementation. Not fixed by either of the above.

The first two are context problems and the industry is solving them quickly. The third is a different property, and it is the one that determines whether a decision is binding. We have argued the general form of this elsewhere in memory is not governance, and the density-based version in constraint decay. What the long-horizon benchmarks add is the time axis.

What this evidence does not show

Being exact here is worth more than being persuasive.

The studies establish that agent performance degrades over persistent trajectories, that accumulated requirements become harder to preserve, that code structure erodes as agents extend their own work, and that context-bearing handoffs materially outperform repository-only handoffs. That is a well-supported failure class.

They do not show that switching between model families specifically causes architectural decisions to be dropped. They do not show that any particular governance mechanism prevents the degradation. No study here evaluates deterministic architectural enforcement as a treatment.

The research identifies the problem. It does not validate the cure, and anyone selling you the cure should say so.

The measurement that would settle it

The useful experiment is not another one-shot compliance score. It is a survival curve.

Introduce an architectural decision early. Run a series of unrelated or evolving tasks. Include at least one later task where violating the decision is the locally convenient move. Then plot the percentage of runs still compliant against trajectory length, at rounds one, three, five, and ten.

Run that across conditions: repository only, repository plus an instruction file, repository plus the explicit decision in context, and persistent retrieved decision state with deterministic enforcement. Add handoffs between model families as a second axis.

If baseline compliance decays while the enforced condition stays flat, the mechanism is demonstrated. If it does not, that is worth knowing too. A curve is falsifiable in a way that a demonstration is not.