On 7 June Addy Osmani published Loop Engineering, on the shape of an agent that works on its own for hours. The argument is that the leverage point has moved from the prompt to the cycle around it: “That’s what makes loop design harder than prompt engineering, not easier”.
In the two months before, two arXiv papers had appeared that start from the same problem and head in opposite directions. One proposes replacing the cycle with a graph declared up front. The other measures external orchestration against doing without it, and finds the orchestrator behind.
We have already described the anatomy of the cycle and the environment that makes it reliable. The shape to give it is a separate design decision.
The loop, and what holds it up
Osmani puts memory outside the context: “the model forgets everything between runs so the memory has to be on disk and not in the context. The agent forgets, the repo doesnt”. Every run starts from an empty context window, so any state that has to survive between two runs must be read back from the files the agent wrote itself.
The second choice is structural: “The most useful structural thing in a loop, by far, is splitting the one who writes from the one who checks”, because the model that wrote the code is far too generous when grading it. The same split applies to the stop condition, with “a fresh model” deciding whether the loop is done instead of the one that did the work.
Connectors are the third: “the reason the loop can act inside your actual environment instead of just telling you what it would do if it could”.
Osmani also states his own caveat: “its still early, I’m skeptical and you absolutely have to be careful about token costs (usage patterns can vary wildly if you are token rich or poor)”.
The graph, as an engineering proposal
arXiv 2604.11378, From Agent Loops to Structured Graphs, by Hu Wei, filed on 13 April, attacks the loop on three points: “implicit dependencies between steps, unbounded recovery loops, and mutable execution history that complicates debugging”.
The framing comes from scheduling theory. The loop is described as “a single ready unit scheduler”, where at most one unit is active and the choice of which one to activate comes “from opaque LLM inference rather than an inspectable policy”. Hence the proposal, SGH, which lifts control flow out of implicit context into a static DAG, with plans immutable within a version, three separate layers for planning, execution and recovery, and an escalation protocol.
The paper is explicit about what it is not: “This is a position paper and design proposal. We provide a theoretical framework, design analysis, and experimental protocol, not a production implementation or empirical results”. Its four deliverables are a framework, a trade-off analysis across 70 surveyed systems, a formal specification with termination guarantees, and a seven-group experimental protocol left to future validation.
The prompt, with numbers against the orchestrator
The opposite work is arXiv 2604.27891, by Simon Dennis, Michael Diamond, Rivaan Patil, Kevin Shabahang and Hao Guo, filed on 30 April and revised on 5 May. It compares a LangGraph orchestrator with the whole procedure placed in the system prompt, using the same model, across three domains: travel booking with 14 nodes, Zoom technical support with 14 nodes, insurance claims processing with 55 nodes. Two hundred conversations per condition, scored by LLM-as-judge on five criteria.
| Measure | In-context | LangGraph |
|---|---|---|
| Score, 1-5 scale | 4.53-5.00 | 4.17-4.84 |
| Failures, travel | 11.5% | 24% |
| Failures, Zoom | 0.5% | 9% |
| Failures, claims | 5% | 17% |
The authors’ conclusion is a temporal one: “While external orchestration may have been necessary for earlier models, advances in frontier model capabilities have made it unnecessary for multi-turn conversations following a defined procedure”.
The method deserves weighing. The judge is a model, the domains are three, and the procedures are defined up front, which is the condition most favourable to the in-context approach. What remains are numbers from a comparison with the same model on both sides, with stated conditions and scoring criteria.
What the cycle costs
Anthropic published the bill while describing its own multi-agent research system: “agents typically use about 4× more tokens than chat interactions, and multi-agent systems use about 15× more tokens than chats”. Hence the stated condition: “multi-agent systems require tasks where the value of the task is high enough to pay for the increased performance”.
The same Anthropic pages, in Building effective agents, separate workflow from agent. A workflow is a system where models and tools are orchestrated through predefined code paths. An agent is a system where the model directs its own process and tool usage.
What we think
The three positions do not answer the same question, which is why all three can be defensible at once.
Where the procedure is known in advance and the steps can be listed, the work by Dennis and colleagues says that an external orchestrator adds a breaking point without adding quality, and says it with a measured comparison. Where the procedure is known but has to be auditable afterwards, Hu Wei’s position is a coherent engineering hypothesis, though at the moment an avowedly unvalidated one. Osmani’s loop is for the case where the path cannot be listed in advance, and that is where his two choices really count.
Memory on disk and the split between the one who writes and the one who checks do not depend on the shape chosen: they hold for a graph as much as for a cycle, and they survive a change of framework. A system with memory in the context loses everything at the first restart, and a system that grades itself declares finished whatever it has just written.
The practical criterion we take from this is to start with the cheapest shape that solves the task, and climb only when the task demands it: an in-context procedure for as long as the procedure is defined, a cycle with memory and a separate checker when the steps cannot be listed, multi-agent coordination when the value of the task covers fifteen times the tokens of a chat. The point of Anthropic’s measurement is that the jump has to be justified every time.