Our AI planner made more work every time we retried it

Most AI pipelines have a retry button. When an output fails review, you run it again with the feedback and expect it to get closer. In June 2026 we watched ours do the opposite on a real client plan. Each retry left the plan larger and no closer to done.

The symptom

ARC's planner writes the specifications for the new system. Each one is reviewed, and a reviewer can block it and suggest changes. Retrying was meant to regenerate only the blocked pieces.

In one run, the number of suggested changes grew from 136 to 156. Blocks were being cleared more slowly than new material appeared. Pressing retry again would have made it worse.

Three causes, all about identity

Nothing checked for duplicates. Every regenerated document was reviewed again. A suggestion saying almost the same thing as an existing one, in slightly different words, was treated as new.

Renaming broke the human channel. A person's answer to a blocking question was tied to the document's name. When a retry renamed the document, the answer no longer applied, so the same question blocked again. Decisions people had already made were silently lost.

Old verdicts never got re-checked. Documents that would now pass kept their earlier block, because the retry skipped anything it didn't regenerate.

None of these is a model problem. Each is a plain engineering bug that gets worse when a model is in the loop, because models rarely produce exactly the same text twice.

What fixed it: stop regenerating

We stopped retrying and ran a one-time clean-up pass instead, with no model in the loop. It merged near-duplicates, reapplied every answer people had already given, made the fixes that had one obvious answer, and re-checked everything. Anything that truly needed a person went into a short queue.

The plan went from 578 documents to 498 and from 32 blocked to none. The queue left for a human held two decisions: where to deploy, and how to merge two legacy permission models. Those are the questions a person should be answering.

We then froze the plan. Running the regenerative loop again would have undone the clean-up, so the plan went to the build as it stood.

The general lesson

Researchers have found that models get worse when they condition on their own earlier mistakes, and that larger models alone don't fix it (Sinha et al., 2025). A retry loop that feeds a model its own previous output plus a list of complaints is that setup exactly. It converges only if the engineering around it is stable.

• Identities have to be stable. If the same idea can look new on every pass, no loop can converge.
• Human answers have to survive change. A decision someone made should never depend on a title staying the same.
• Know when to stop generating. Past a certain point, a mechanical clean-up beats another model pass.

What to ask a vendor

• What happens to a reviewer's or customer's answer when the document it answered is regenerated?
• Can a rerun make the output bigger? How would you know?
• When does the system stop asking the model and hand the remaining questions to a person?

Sources

All accessed 2026-10-30.

• Sinha et al., "The Illusion of Diminishing Returns: Measuring Long Horizon Execution in LLMs", 2025. https://arxiv.org/abs/2509.09677