Loop Engineering
Most writing about agents is about the inner loop: the model, the tools, the prompt. This section is about the outer loop, the control structure you wrap around an agent so it can find work, do it, check the result, and decide the next step without you typing each turn. “Loop engineering” is the (very new, mid-2026) name for designing that outer structure well.
It pairs with the field guide, Which Loop Do You Need?, which walks six everyday jobs and the loop each one needs. This section is the reference underneath it: the definitions, the taxonomy, the client-ready decision guide, and the verified reading list.
A loop is a task plus a check
Section titled “A loop is a task plus a check”One mental model recurs across almost every serious source on the subject: a loop is a task plus a check. A task without a check is just hope. An agent does the work; something decides whether the work is done, wrong, or stuck. The entire discipline is the engineering of that check (the verifier) and the stop condition (termination), because those are what let you walk away.
The four axes
Section titled “The four axes”Loops do not differ meaningfully by which model or vendor runs them. They differ along four axes that actually change behavior, cost, and trustworthiness. Classify any loop by picking one value per axis; the named patterns are recurring combinations of these values.
| Axis | Question | Values (weak → strong / simple → complex) |
|---|---|---|
| Termination | When does it stop? | time-recurring · goal-met · fixed-pipeline · budget-exhausted |
| Verification | How good is the check? | self-check · fresh-context same-model · cross-model · deterministic tests · layered + human |
| Control flow | Who decides the next step? | scripted workflow · model-driven agent |
| State | What persists between turns? | fresh context · accumulated conversation · externalized (files / git / board) |
The two axes that decide whether a loop is trustworthy are verification (how hard the check is to fool) and state (whether the work survives a closed laptop). Mature loops sit low on verification only when the stakes are low, and push durable state out of the conversation and onto disk the moment a job runs longer than one sitting.
Explore this section
Section titled “Explore this section”How AIOS maps onto the taxonomy
Section titled “How AIOS maps onto the taxonomy”Read through this lens, AIOS is a collection of loop-engineering primitives with an unusually strong bias toward the strongest verification tier. Its tagline, verification is the value, is a bet on the verification axis.
aios relay— cross-model plan review. One model writes a plan, a different model reviews it adversarially, the first revises, repeat until the reviewer signals ready or the round budget is spent. Evaluator-optimizer, goal-met plus budget termination, cross-model verification.aios build— build/review with a fail-closed gate. The builder works on an isolated copy; a different model reviews the real diff; a deterministic secrets scan runs fail-closed before any merge. Layered verification, state externalized to git.aios ship— the fully layered, human-gated pipeline. recon → plan → [plan gate] → build → review by bots and a cross-vendor model → bounded fix loop → [merge gate]. The layered pattern in full, plus a shadow-then-promote egress: everything happens on a staged copy and only two explicit human gates promote it.aios roadmap-run— loop-until-dry over the backlog. Picks one unblocked item at a time, ships it, moves on until the queue is empty. State lives on the board, which is both the queue and the memory.aios spec fix— bounded rubric-gated improvement. Grades a spec against a written rubric, revises, re-grades, until ready or the budget runs out. The rubric is the honest pass bar, and the human still owns the promotion decision.
The through-line. Where most practitioner loops lean on a single verifier, AIOS stacks verifiers, makes the strongest one deterministic and fail-closed, and keeps a human at the two boundaries that matter (plan and merge) and at every point where content crosses a trust boundary. That is a deliberate position on two axes: maximize verification diversity, and never let durable or shared state move without a gate.