🧩 Fundamentals of Loop Engineering

Loop Engineering is the approach where automated systems (loops) trigger, monitor, and iterate over AI agents in a continuous cycle, replacing manual human prompting.

Understanding the precise definition avoids confusion with generic automation. The term has a specific meaning in the context of coding agents.

Loop-driven vs. prompt-driven. You define the system, not each prompt. Analogy with cron jobs + AI agents.

Boris Cherny, Head of Claude Code, manages tens of thousands of agents per day using loops. He doesn’t type prompts: he builds systems that do it for him.

The source’s credibility matters. Boris is at the center of Claude Code development and practices loop engineering at an industrial scale.

Scaling to thousands of agents per day. Prompting as a system, not an interaction. Anthropic as a practical reference.

Peter Steinberger created OpenClaw and runs loops that automatically prompt Claude, with an orchestrator, workers, and external state management.

It's a real implementation case outside Anthropic. It shows that the approach works for independent developers, not just the people who build the tool.

OpenClaw as harness. Orchestrator/worker separation. External state (Postgres). Agent autonomy.

With manual prompting, the human interacts directly with the agent at every step. With loop-driven work, the human defines the system once, and the loop automatically runs N iterations.

The distinction is essential for knowing when each approach makes sense. Loop-driven development doesn’t replace manual prompting in every case.

Synchronous vs. asynchronous interaction. Cost of human attention. Scale vs. precision. Control trade-off.

Loop Engineering combines the concept of scheduled tasks (like cron jobs on Linux) with the reasoning capabilities of LLMs. The loop triggers, and the agent decides what to do.

The analogy helps demystify it: it's not magic; it's automation with an intelligent layer. If you understand cron jobs, you're already halfway there.

Time-based vs. conditional trigger. Job = agent session. Exit condition = stopping criterion. Idempotency.

The term Loop Engineering gained traction after Boris Cherny publicly described how Anthropic uses loops internally. Cole Medin asks: "does it deserve its own buzzword?"

Separate signal from noise. Not everything with a proper name is revolutionary. Understanding the context helps you avoid adopting things blindly.

Hype cycle. Naming as marketing. Substance vs. branding. Honest critique of Cole Medin.

The /loop command sets execution intervals for the agent, such as “every 5 minutes.” It is the recurring mechanism that keeps the agent active.

Without a loop, the agent stops when it finishes a task. With a loop, it wakes up periodically to check whether there's new work.

Polling interval. Automatic wake-up. Difference between a loop and a single-shot run. Token cost per idle cycle.

/goal defines an objective completion criterion. The agent keeps iterating until it reaches the goal or runs out of attempts. It's the loop's exit condition.

Without a clear goal, the loop runs indefinitely, spending tokens without producing results. The goal is what makes a loop useful.

Explicit exit condition. Automatic completion check. Fallback and retry limits. Goal vs. deadline.

/routines are scheduled tasks with a defined schedule (e.g., "every hour, review the spec"). Unlike the generic /loop, routines have a specific, recurring purpose.

Routines are the most practical mechanism for maintenance tasks: periodic code review, docs sync, health checks.

Cron-style schedule. Routine vs. ad hoc loop. Combining multiple routines. Priority among conflicting routines.

The three primitives don't operate in isolation. A typical system combines /loop as a heartbeat, /goal as an exit criterion, and /routines as parallel maintenance tasks.

Understanding the composition is the step from "I know what each piece does" to "I can build a functional system."

Pipeline as a graph. Dependencies between blocks. Execution priority. Diagnostics when a block fails.

The plan.md is the Markdown document that defines the tasks for the loop to process. It works as a contract: the orchestrator reads it, executes each item one by one, and marks it as complete.

A poorly written plan.md leads to inefficient loops. Input quality determines output quality, even in automated systems.

Task list structure. Ideal task granularity. Acceptance criteria for each item. Plan versioning.

Loop with no exit condition (runs forever), vague goal ("do something good"), routine that conflicts with the main loop. These are traps that burn tokens without results.

Avoiding these errors from the start saves money and frustration. Most beginners fall into the same traps.

Infinite loop. Ambiguous goal. Conflicting routines. Max iterations as a safety net. Budget limits.

The orchestrator is the agent session that reads the spec, decides which tasks to run, launches workers, and validates results. It doesn't execute code directly.

The orchestrator is the most critical point of failure. If it makes poor decisions, all the workers produce junk. Understanding its role is essential.

Separation of concerns. Decision vs. execution. The orchestrator model (which can be cheaper). Retry logic in the orchestrator.

Workers are agent sessions that receive a specific task from the orchestrator and execute it. They can run in parallel using worktrees for isolation.

Workers are where the real work happens. Understanding how to isolate them, monitor them, and collect their results is the practical side of loop engineering.

Worktrees as a sandbox. Real parallelism. Collecting results. Worker timeout. State isolation.

Instead of relying on the LLM's context window to maintain state, the loop saves state in an external database (Postgres, Neon). This prevents context bloat and lets you summarize sessions.

Context bloat is the #1 cause of degradation in long loops. External state is the architectural solution that makes loops viable at scale.

Database as the source of truth. Context window as cache, not storage. Neon branching for workers. State store schema.

Flow: spec comes in -> orchestrator plans -> spin up workers -> workers execute -> results return to state -> orchestrator validates -> next wave or completion.

Viewing the complete workflow helps you debug when something goes wrong. Each step is a potential failure point that needs to be handled.

Round as a unit of work. Fan-out (orchestrator -> workers). Fan-in (workers -> orchestrator). Validation between rounds.

With external state, if the agent crashes in the middle of a round, the orchestrator can resume where it left off. The state in the database survives crashes, timeouts, and disconnections.

Long loops inevitably fail at some point. Durability is what separates a toy from a production system.

Checkpoint in the state store. Resume from last good state. Worker idempotency. Cleanup of orphaned workers.

Observability is the ability to see what the loop is doing in real time: orchestrator decisions, worker progress, accumulated cost, errors.

Without observability, you're running a blind loop. "Run for a day, come back to crap" is a symptom of inadequate monitoring.

Agent Control Plane. Cost tracking per round. Orchestrator decision log. Human-in-the-loop checkpoints.