Loop Engineering Is Just Software Engineering. We Have a Name for That.<br>This site uses cookies to understand how visitors find us.<br>You can accept or decline non-essential cookies.<br>DeclineAccept
A few weeks ago Addy Osmani, formerly of Google<br>Chrome, now author of Beyond Vibe Coding, published a piece called Loop<br>Engineering. It opened with a quote from Peter Steinberger:<br>“You shouldn’t be prompting coding agents anymore. You should be designing loops<br>that prompt your agents.” Boris Cherny, head of Claude<br>Code at Anthropic, said the same thing: “I don’t prompt Claude anymore. I have loops running that prompt<br>Claude and figuring out what to do. My job is to write loops.”
LangChain followed with The Art of Loop Engineering, laying out a four-level<br>architecture. Tooling appeared: LoopFlow on GitHub, Neuralyzer for self-wiping<br>agent context windows. The term now has 987 results on the Hacker News search<br>API.
It is also a good description of a distributed system. We have been building<br>those for twenty years.
What Loop Engineering Actually Describes
Per Addy Osmani and LangChain’s own writing, a production loop has four levels:
The agent loop: a model calling tools repeatedly until a task completes.
A verification loop: a grader checks output against a rubric and retries on failure.
An event-driven loop: cron schedules or webhooks trigger agent runs automatically.
A hill-climbing loop: production traces feed an analysis agent that rewrites the harness configuration.
Surrounding everything: memory — “a markdown file, or a Linear board, anything<br>that lives outside the single conversation and holds what’s done and what is<br>next.” Addy’s words, not mine.
This is a complete description of an event-driven, observable, stateful<br>distributed system with retry logic, dead-letter handling, pub/sub fan-out, and<br>durable external state.
Let me translate the terminology:
Loop Engineering PrimitiveWhat It Actually Is”Automations that run on a schedule”Cron trigger”Memory that lives outside the conversation”Key-value store”Sub-agents that don’t step on each other”Isolated workers consuming from a message queue”Verifier checks the maker’s work”Pub/sub consumer with retry logic”Traces feed the hill-climbing loop”Observability pipeline”Dead work lands in a triage inbox”Dead-letter queue”Loop runs until a condition is true”Queue-backed durable execution with completion condition”Plugins connect your tools”Webhook integrations<br>The naming is different. The systems are the same.
A developer on Hacker News built a loop engineering pipeline for<br>Korean-to-English translation before the term existed — a plan, execute,<br>critique, repair loop with a separate reference translator as an “impartial<br>witness,” a translation memory to prevent terminology drift, and an output<br>writer appending incrementally to disk. Textbook loop engineering architecture.
Their conclusion: “the critic kept flagging that the translation is not good<br>enough and looping back and the translator was not able to translate good enough<br>for the critic to be satisfied… after a couple of weeks I kind of gave up.”
An unobservable retry loop with no circuit breaker, no dead-letter queue, no<br>backpressure, and no durable state is loop engineering on paper. In production<br>it just runs until something breaks.
iii’s Harness Worker
iii ships a worker called harness. Its own description is “thin durable turn<br>loop that wires session-manager, context-manager, and llm-router into an agent<br>loop; spawns sub-agents as child sessions.” That is loop engineering, in one<br>command: iii worker add harness.
Now look at its dependencies. iii-state for a key-value store. iii-queue for<br>a message queue. iii-cron for the scheduler. iii-observability for<br>distributed tracing. iii-stream for streaming output. session-manager for<br>transcript persistence. context-manager for token budgeting. Every loop<br>engineering primitive — the memory, the durable execution, the scheduling, the<br>observability, the streaming — is a named, separately installable worker that<br>the harness composes. In the dependency manifest. The harness does not abstract<br>over those things. It is those things, composed.
The harness’s core function, harness::turn, is described in the registry as an<br>internal durable loop step enqueued onto the default queue, not called directly.<br>The agent loop step itself is a message queue consumer. Every iteration of the<br>model’s think-act cycle is a job enqueued onto iii-queue and drained by a<br>worker. If the process crashes mid-turn, the queue holds the step and another<br>worker picks it up where it left off. This is durable execution. SQS launched in<br>2006.
harness::sweep-pending is described as: “Internal cron sweep: resolve pending<br>function calls past their timeout so a parked turn never wedges.” The mechanism<br>that stops loop engineering from running forever and eating all your tokens is a<br>cron job. Configurable via sweep_expression: "0 * * * * *" in config.yaml. It<br>scans all turn records, finds any...