Autonomous Outer Loops

An outer loop repeatedly launches fresh agent sessions against durable task state until the success criteria hold or a limit is reached. This is the smallest system in the book that can continue delivering work while nobody watches each step.

Keep memory outside the session

Practitioners often call this the “Ralph” pattern after Geoffrey Huntley’s write-ups. His reported production results found that repeated fresh sessions completed large mechanical tasks more often than one long session, at 85 percent versus 60 percent.

The architecture lesson matters more than the name: memory belongs in durable artifacts such as the task, codebase, tests, and version history. It should not depend on one context window remaining healthy for the entire job.

Fresh sessions limit instruction drift and context degradation. They also force each attempt to recover the current state from evidence rather than from an increasingly compressed conversation.

Use outer loops for bounded work

Outer loops work well for migrations, repeated renames, lint remediation, and coverage expansion. These tasks have mechanical steps and binary completion criteria.

They are a poor fit for ambiguous architecture, unresolved product decisions, and security-sensitive actions that require judgment. Repetition cannot repair an unclear goal.

Apply three controls

• Machine-verifiable success criteria. “Tests pass” can terminate a loop. “Code looks good” cannot.
• Hard ceilings. Limit iterations, wall-clock time, and spend.
• Failure containment. Preserve a known-good state and stop after repeated failures instead of accumulating damaged changes.

Know when restart is no longer enough

A simple outer loop assumes an attempt is cheap to repeat. Production workflows cannot always make that assumption. A tool may accept a write before timing out, a worker may restart, or an approval may arrive hours later.

Once work includes expensive or asynchronous side effects, execution state must live outside the running process. The system needs to resume from a safe boundary without repeating completed actions. Durable Agent Execution develops that requirement in full.

Part I has assembled the complete single-agent unit: instructions, model, tools, feedback, and bounded repetition. Part II: A Reliable Agent now engineers the environment that keeps that unit safe and recoverable in production.