Work, not answers

A system is not agentic because it calls tools. It is agentic when it can say what it is trying to achieve, and then tell whether it got there.

An earlier version of this idea looked convincing from the outside — a visible plan, steps appearing one after another, a trace scrolling by. But underneath, the plan was scenery: the engine had quietly stopped reading it and simply followed a fixed path. Anyone watching drew the only reasonable conclusion, that the steps were being followed. They were not.

The fix was a stricter idea of agency: a real run has to hold on to something across its whole life — what the objective is, what would count as a satisfactory result, what evidence is needed, and what should happen when the evidence says the current approach is wrong.

Fig. 5.1 — The loop bounded by a reconsideration cap and a budget of time and rounds.

Four moments carry the weight of the whole idea. The objective is written down before the work starts, so success cannot be redefined later to fit whatever turns up. A step reports what it learned, not merely that it ran — a completed call is not the same as a call that helped. The approach can change mid-run; the objective cannot. And the final check asks whether the evidence in hand satisfies the objective as written at the start — readiness, not the appearance of completion.

The most instructive failures were never crashes. They were runs that reported success and delivered nothing — every step returning cleanly, and no result at the end of it. Which is why the loop reads what actually came back, every time, rather than trusting that a completed call means progress.

And because a run is stateful, the relationship does not end when the answer is written. The result is a document a person can come back to. Ask for a section to be changed, and it revises that work — it does not throw the whole thing away and start again.

Two failures worth telling

A project that only publishes its successes teaches nobody anything. Two failures from this one are worth keeping, because both looked like success from the outside.

The plan that was scenery. An early version of the agentic loop had everything a demo needs — typed state, a budget, a live trace of steps scrolling past. It looked exactly like a system reasoning about its task. Underneath, the engine had quietly stopped reading the plan it displayed and was following a fixed path regardless of what the plan said. Anyone watching drew the only reasonable conclusion: that the visible steps were the ones being taken. They were not, and nothing before the stricter loop described earlier in this book would have caught the difference.

The run that finished with nothing in it. A piece of work once reported success and produced no result at all — every step returning cleanly, nothing flagged, and no document waiting at the end. Every automated test for that code passed, because the tests checked that steps ran, not that the objective had actually been reached. Only a real request against the live system exposed the gap between completed and helped.

A step that completes is not the same as a step that helped — and a green test suite can be entirely honest about the wrong thing.

Both failures trace back to the same absence: nothing outlived any individual step to say, in writing, what the run was actually for. That is precisely the gap the frame-act-evaluate-verify-compose loop was built to close.

Bounded, not endless

A loop that can revise its own plan is a loop that can also spend a long time revising it. Agency without a ceiling is not patience — it is a system quietly burning time, tokens and money while looking, from the outside, exactly as busy as it would if it were making progress.

Two ceilings hold the loop in check. One caps how many times a run may reconsider its approach — a run that keeps changing its mind is a run that has stopped converging on anything. The other is a budget of rounds, tokens and wall-clock time, so that even a run making genuine progress cannot run forever on a single task. Both are needed, because a loop can oscillate cheaply for a surprisingly long time without ever becoming obviously expensive in any single step.

Reconsideration cap — Limits how many times the plan itself may change mid-run, so revision converges instead of drifting.

Round & time budget — Caps rounds, tokens and wall-clock time regardless of how confident the run feels along the way.

Neither ceiling is a punishment for being wrong. A run that hits its budget still returns whatever it has judged and verified so far, clearly marked as partial — agentic does not mean unbounded, and a system is more trustworthy when it can stop cleanly inside a known envelope than when it simply keeps going until something breaks.