Loop Engineering

Loop engineering is a recent practitioner term for designing repeatable systems that discover or receive work, hand it to an AI agent, evaluate the result, preserve state, and decide whether to continue, stop, retry, escalate, or run again. The term appeared in practitioner writing in 2026 and is not yet defined by a standards body or settled research taxonomy. It is useful when it names the control system around agent execution rather than a new name for prompting alone.

A loop may contain an agent loop, but the two are not identical. An agent loop is the model-facing cycle of receiving context, choosing an action, observing a result, and reasoning about the next action. An external loop operates at a higher level: it selects work, starts or resumes an agent session, checks evidence, records progress, and schedules or triggers another pass. The software that performs the model and tool interaction is an agent harness. These layers compose with prompt engineering, context engineering, evaluation, and human review; they do not replace them.

Background and terminology

Software has long used event loops, retry loops, control loops, and scheduled jobs. Agent systems add a variable component whose outputs are not fully determined by the input. That variability makes evidence, state, permissions, and stopping rules central design concerns.

The phrase “loop engineering” was introduced in recent practitioner material to describe moving attention from a single instruction toward the system that repeatedly prepares, runs, checks, and continues agent work. A related research preprint describes the design of systems that prompt agents and evaluates patterns for repeated autonomous execution. Because the terminology is new, a neutral account should describe the underlying mechanisms and avoid treating the phrase as an established discipline.

A loop specification describes the trigger, work-selection rule, state, execution step, evidence gate, terminal states, budgets, and escalation path. An evaluator–optimizer loop alternates between generating a result and evaluating it against criteria, with feedback used for another attempt. A terminal state is an explicit condition such as completed, rejected, blocked, canceled, or budget exhausted. The seed paper also uses verification debt for the risk created when work accumulates faster than it can be independently checked; this is a source-specific term rather than settled vocabulary.

Relationship to prompts, context, and harnesses

Prompts express goals, constraints, and local instructions. Context supplies the information available for a particular invocation. A harness assembles that context, calls the model, exposes tools, records events, and applies execution controls. Loop engineering connects those components across repeated runs.

This distinction matters because a strong prompt does not define what happens after a failed check, how progress survives a context reset, who may approve a side effect, or when repeated attempts must stop. Conversely, a loop cannot compensate for ambiguous goals, missing evidence, or poorly designed tools. The system works only when instructions, interfaces, state, evaluation, and control rules agree.

Anatomy of a loop

Trigger and work discovery

A loop begins because an event occurs, a schedule fires, a queue contains work, or a person requests a run. The discovery rule should define what work is eligible and how duplicate or already completed work is recognized. Without this step, a scheduled agent may repeatedly select stale tasks or create conflicting work.

Goal and handoff

The selected task must be translated into a bounded goal with relevant context, constraints, and a definition of acceptable evidence. For long-running work, the handoff should include durable progress rather than relying on one conversation window. Task lists, event histories, repository state, and structured summaries can all serve this role.

Harness execution

The harness invokes the model and routes its tool calls within an execution environment. It determines which tools, credentials, files, network destinations, and computational resources are available. The internal reason–act–observe cycle belongs here, while the external loop decides what the completed session means for the larger task.

Verification and feedback

A verification step compares the result with evidence: tests, graders, schemas, policy checks, human review, or observed external state. Feedback should identify a correctable difference rather than merely asking the same agent to try again. Independent evaluation can reduce self-confirming errors for some tasks, but it also adds cost and may reproduce the generator’s assumptions if it uses the same evidence and framing.

Persistence and memory

A repeatable loop needs durable state outside a transient model context. At minimum, the state should show what was attempted, what changed, what evidence was collected, and what remains. Persistence also supports recovery after crashes, context compaction, or a fresh agent session.

Stopping, escalation, and scheduling

Every loop needs explicit terminal states and limits. Completion should be tied to evidence, not the agent’s declaration alone. Retry counts, time, token, financial, and side-effect budgets act as circuit breakers. Blocked or uncertain work should move to an escalation path rather than being converted into endless retries. If the work is recurring, scheduling begins only after the current state has been recorded.

Common patterns

A fixed workflow runs a known sequence of steps and uses agents only where judgment or synthesis is needed. An evaluator–optimizer pattern generates an output, evaluates it, and iterates until a threshold or budget is reached. A long-running incremental loop divides a larger goal into small changes, stores progress, and resumes with fresh context. A human-gated loop requires approval before consequential actions or ambiguous transitions. An event-driven or scheduled loop starts from external signals or time rather than a continuous autonomous process.

These patterns can be combined. A scheduled loop may select a task, use an evaluator–optimizer inside a harness, and pause at a human gate before publication. The important design question is which component owns each transition.

Failure modes

Weak verification produces circular confidence: the same system creates the work and accepts it without new evidence. State loss causes repeated work, contradictory changes, or premature completion after context resets. Unbounded retries increase cost without increasing information. Error propagation occurs when an early mistaken assumption becomes input to every later pass.

Loops can also reduce human comprehension. A system may continue producing changes faster than reviewers can understand their dependencies. Observability data does not automatically solve this problem; traces must be organized around decisions, evidence, and state transitions. Consequential side effects create another class of risk when retries are not idempotent and the same message, transaction, deployment, or record creation can occur more than once.

Design considerations

A practical design starts with terminal states and independent evidence. It defines what counts as complete, what counts as blocked, and which observations justify another pass. Budgets and circuit breakers bound cost and repeated failure. Idempotency keys, reconciliation checks, and explicit side-effect records prevent duplicate actions.

The loop should expose enough information for operators to reconstruct why a transition occurred. Useful records include the selected task, input version, agent and harness version, actions, external effects, evaluator results, resource use, and final state. Human checkpoints belong where judgment, authority, or risk cannot be reduced to a reliable automated test. An override should be recorded as an override rather than presented as automated success.

Current state of practice

The mechanisms described by loop engineering are established across workflow engines, agent harnesses, evaluation systems, and long-running coding agents. The combined label remains new. Current guidance therefore supports the architectural distinctions—triggers, state, harness execution, evaluation, budgets, and escalation—more strongly than it supports any universal “loop engineering” method.

The supplied PDF is an independent synthesis and reformatting of other practitioner material, not an Anthropic publication. Anthropic’s engineering articles provide primary examples of agent workflows, evaluator–optimizer patterns, long-running harnesses, managed sessions, containment, and evaluation. They should be cited for those specific practices, not as evidence that Anthropic owns or formally defines the broader term.

Open questions

• Will “loop engineering” persist as a useful term or be absorbed into workflow orchestration, agent operations, or control-system design?

• Which components are essential for a process to count as a loop specification?

• How should subjective work be evaluated without turning one model’s preference into circular evidence?

• When does an independent evaluator justify its latency and cost?

• How should uncertainty, blocked states, and human overrides be represented across implementations?

• Which tasks should never be placed in unattended recurring loops?

Related topics

• Agent Harnesses

• Human-In-The-Loop AI Workflows

• Agent-Oriented Developer Workflows

• Agent-First Design

• Agent-ready business systems

Further reading

• Loop Engineering — Addy Osmani

• Stop Hand-Holding Your AI: Build Systems That Prompt Agents — research preprint

• Building Effective AI Agents — Anthropic

• Effective Harnesses for Long-Running Agents — Anthropic

• Demystifying Evals for AI Agents — Anthropic