The Agent Loop

Strip any agent to its skeleton and you find the same cycle: think, act, observe, repeat. The model reasons about what to do, takes one action through a tool, reads the result, and reasons again. The pattern was formalised as ReAct (Yao et al., arXiv:2210.03629), and every harness in production is an elaboration of it. Understanding the loop, and what feeds it, is the last piece of single-agent groundwork before this book turns to reliability.

Feed the loop good signals

The loop is only as good as its observations. Feedback signals differ sharply in quality:

• Binary and localised signals are gold: a failing test names the failure and where it is; a compiler error points at a line; a linter names the rule. The agent can act on them directly.
• Interpretive signals are noise-prone: raw command output the agent must parse and judge invites misreading and invented success.

The design consequence runs through everything later in the book: build workflows so agents receive binary, localised feedback wherever possible. This is the seed of the argument in Verification & the Outer Loop that success criteria must be machine-checkable, and of the guides-and-sensors control framing in The Harness.

Bound the loop explicitly: an iteration cap, a time or cost ceiling, and the stopping conditions from Instructing an Agent. An unbounded loop does not converge; it wanders.

The autonomous outer loop

Wrap the inner loop in an outer one and you get the first genuinely autonomous unit: a script that repeatedly launches a fresh agent session against a task file, lets it attempt and commit, and starts over until the success criteria hold. Practitioners know this as the “Ralph” pattern after Geoffrey Huntley’s write-ups; the striking, well-documented finding is that fresh sessions repeatedly beat one long session on completion rates for large mechanical tasks, in Huntley’s production numbers 85 percent against 60. This is compound error and context degradation, from Working With Models, showing up as an architecture lesson: memory lives in git and the task file, not in the context window.

The pattern earns its keep on mechanical bulk work with binary completion: migrations, renames, lint remediation, coverage expansion. It is wrong for architecture, ambiguous requirements, and anything security-sensitive. Run it with three disciplines:

• Machine-verifiable success criteria only. “Tests pass” works; “code looks good” recurses forever.
• Hard ceilings: maximum iterations, wall-clock, and spend.
• Entropy management: reset to a known-good commit after repeated consecutive failures, and squash failed-attempt noise out of history.

One agent, looping unattended against verifiable criteria, is the smallest system in this book that delivers work while nobody watches. Its limits (no judgment about what to build, no defence against its own misreadings of the goal) are precisely what the rest of the book adds structure to fix.

The leverage ladder

There is a clean way to see where you now stand and where the walkthrough goes next. Practitioners describe a ladder of engineering leverage (Addy Osmani’s “loop engineering” essay is the crispest statement), where each rung moves the human further from the keystroke:

1. Prompt engineering: a human in every turn. Part I, behind you.
2. Context engineering: curating what each turn sees. Part III.
3. Harness engineering: building the environment around the agent so failures become impossible rather than unlikely. Part II, next.
4. Loop engineering: systems that prompt the agent, discover their own work, and verify their own output. Part IV and Part V.
5. The factory: a system that builds software, where the human runs the organisation. Part VI, and the ambition of Ikidna itself.

Every rung keeps the ones below it. The prompts you learned to write in this part are exactly what gets versioned, evaluated, and eventually self-improved at the top of the ladder.

Turn now to Part II: A Reliable Agent.