One loop, three models

A loop framework gives an agent a fixed path to follow. First write down what done looks like as checks anyone can run: “picking 1990s shows only films from 1990 to 1999”, not “it looks good”. Then build, and go round until every check passes. Any failure, at any stage, sends the work back to Build with the reason attached. Nothing reaches production until a person says yes.

The run above adds a decade filter to a page of movies. It fails twice, which is normal and the point: a type error caught by the compiler, and a bug the browser check missed but the review caught.

The loop is one shape of agent graph. Designing an agent graph sets it beside the others: routers, orchestrators and workers, evaluator loops, and gates with a person.

The work in a loop is uneven. A little of it is judgment, where a mistake is expensive: deciding what to build and whether the result is right. Much more of it is reading files and clicking through pages, where a mistake is cheap and the next check catches it. So each kind of work gets its own model.

• Opus, the lead, frames the work and reviews the diff. It uses about as many tokens as the others but costs the most, and that is money well spent: these are the moments that decide the outcome.
• Sonnet, the builder, writes and fixes the code. That needs real skill, and a lot of tokens.
• Haiku, the scout, reads code and drives the browser. It reads about a third of all the tokens in this run for under two cents.

Each model sees only what its job needs. The scouts hand the lead a short summary, not every file they opened, so the lead's context stays small and sharp.

A model asked whether its own work is finished tends to say yes. The compiler, the linter and the build cannot be talked round, so they hold the gates, and they cost nothing. Where a check needs eyes, such as clicking through a page, a model does it, but against checks written down before any code existed.

The layers catch different things. In this run the compiler caught a type error, and the review caught a bug the browser check had walked straight past, because nobody had told it to click “All”.

• What people mean by a harness: the word for the system around the model, and a map of its parts on this site.
• Designing an agent graph: six patterns, the last about what a run does when a check fails and how much it may spend.
• Traces, checkpoints and receipts: what a run like this one should leave behind, and why a passed check is only proof for the content it passed on.
• The vault and the graph and The AI Platform team: Organizational AI Governance: the memory the agents read, and who runs the whole thing.

• This run is scripted. It is written to match how these runs really go, but the token counts are representative, not measured. Costs are worked out from them at list prices as of October 2026.
• Real runs cache. Each call resends much of the same context, and prompt caching makes those repeated tokens far cheaper. Real totals are lower than shown here, and caches are per model, so splitting work across models gives some of that saving back.
• Three models is not always cheaper. One capable model at a lower effort setting can match a team of smaller ones. The honest measure is cost per finished feature, retries included, not cost per call.

• Anthropic 2024 · E. Schluntz and B. Zhang, "Building effective agents", Anthropic (2024): orchestrator–workers and evaluator–optimizer loops
• Yao et al. 2022 · S. Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models" (2022): the think, act, observe loop
• Shinn et al. 2023 · N. Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning" (2023): learning from a failed check in words
• Anthropic pricing · Claude API list prices per million tokens, as of October 2026