Agents need checkpoints more than they need autonomy

A pattern shows up repeatedly in agent systems: each individual step is sound, and the overall run is wrong. Nothing failed loudly. The agent misread something early, everything after was consistent with the misreading, and forty steps later it delivered a confident answer to a problem nobody had.

This is a compounding error problem, and it responds badly to the usual remedies. A better model makes each step more reliable; it doesn't change the fact that errors multiply along a chain.

Checkpoints beat capability

If each step is 97% reliable, a thirty-step chain succeeds about 40% of the time. The two available levers are raising per-step reliability — expensive, bounded — and shortening the chain between verifications.

The second is usually cheaper and more effective. A checkpoint is anywhere the agent's state gets compared against something external and independent:

• Re-anchoring. Restate the original goal and constraints each turn rather than trusting them to survive in history. The most common drift is the agent quietly optimising for a subgoal.
• Verdicts it can run itself. A test, a type check, a schema validation. Anything that returns a hard signal converts a guess into a fact.
• Human gates on irreversibility. Not on every step — on the ones that touch production, spend money, or send something outward. The cost of a gate is proportional to how often it fires; the cost of not having one is proportional to the worst case.

Make failure loud

The other half is refusing to let a failed step pass silently. An empty retrieval that returns nothing, a tool that times out, a parse that half-succeeded — if these return something plausible-looking instead of erroring, the agent will build on them.

The practical version

Before extending an agent's autonomy, ask what would catch it if this particular extension went wrong. If the answer is "a human would notice eventually," the rope is too long.