Loop Engineering

Field guide for recurring agent systems

Awesome Loop Engineering

Design loops, not just prompts.

Explore 874 resources from model recurrence to agent operations, then build with 22 patterns, 22 adaptable contracts, and 8 runtime starters.

Explore resources Choose a loop
Scoped work Agent workspace + tools Independent verifier Durable memory
Retry with evidence Escalate to a human Exit on a verified goal

Intake: turn a goal, event, or queue signal into a bounded work packet.

Loop Engineering is the practice of designing recurring systems that discover work, delegate it to agents, verify results, persist state, decide next actions, and run again on a cadence, event, or until a verifiable goal is reached.Loop Engineering designs recurring agent systems that discover work, delegate it, verify results, persist state, and decide what happens next.

874resources
20operational patterns
20loop contracts
8runtime starters
8languages

01 / The loop contract

Make recurring agent work reviewable before it runs.

A Loop Contract is the operating specification for one recurring agent job. It records what authorizes a run, what the agent may change, what evidence counts, what survives, and when a human takes over.

Why it is necessary

In a supervised session, a person supplies missing judgment as the work unfolds. Once a schedule, event, queue, or goal starts the agent, every unanswered question becomes a hidden default. The loop may select the wrong work, widen its scope, approve its own output, forget a failed attempt, or retry without a stopping rule. The contract turns those defaults into policy that builders, reviewers, security teams, and operators can inspect together.

Four layers, four jobs

The contract connects run-level ingredients to a repeatable operating model.

PromptInstructs the model during one call or run.
PatternDescribes how a class of recurring work should operate.
ContractFixes the exact permissions, gates, memory, budget, and handoff.
RuntimeExecutes that contract in a session, workflow, or durable worker.
Loop Contract: objective, trigger, intake, workspace, context, delegation, verification, state, budget, escalation, exit, and next action.
Eleven explicit decisions replace hidden defaults; next action closes the control loop.

01 / Set up

01Objective
02Trigger
03Intake
04Workspace

02 / Run

05Context
06Delegation
07Verification
08State

03 / Govern + close

09Budget
10Escalation
11Exit

Next actionRepeat, report, escalate, or stop.

01 / Set up

Authorize the right work

Name the outcome, trigger, intake rule, and isolated workspace before any tool acts.

Objective · Trigger · Intake · Workspace
02 / Run

Act, prove, and remember

Load current evidence, separate acting from checking, verify externally, and persist receipts.

Context · Delegation · Verification · State
03 / Govern + close

Bound autonomy

Cap retries and spend, assign a human owner, and define success and blocked exits.

Budget · Escalation · Exit · Next action

Worked example: PR babysitter

“Keep this pull request moving” is only a goal. The contract below turns it into a bounded job that can run without someone polling CI and review threads all day.

Trigger + intake

Run every two hours during working hours and after requested changes or failed checks. Select only explicit blockers on one pull request.

Permission boundary

Use a dedicated branch or worktree. Allow narrow fixes, checks, and progress comments; prohibit force pushes, dependency upgrades, secrets, and production changes.

Team + context

An explorer finds the smallest blocker, an implementer patches it, and a reviewer checks scope using the latest SHA, review threads, CI logs, and repository instructions.

Evidence + memory

Required checks must pass, threads must be resolved, and the diff must stay narrow. Commands, check URLs, changed files, blockers, and the next action survive every run.

Budget + handoff

Stop after three retries or 60 minutes. Escalate architecture, repeated failure, reviewer disagreement, or any force-push requirement to the human owner.

Done means merge-ready or waiting only on human review - not “the agent says it is done.”

Open the full JSON contract →

Verifiable by design

Tests, typechecks, evals, traces, or reviewers decide done. The acting agent never approves itself.

State outside the model

Progress files, issues, checkpoints, and traces survive context resets and the next run.

Budgeted and bounded

Retries, runtime, and concurrency are capped, with a clear path to human judgment.

02 / The lifecycle

Evidence moves the loop forward.

Tests, evals, traces, or reviewers gate the work. Evidence and state persist outside the model, then drive retry, escalation, or exit.

Loop Engineering lifecycle: Intake, Delegate, Act, Verify, Persist, Decide; then retry with evidence, escalate to a human, or exit when the goal is met.
One pass of a recurring, stateful, verified loop.
  1. 01
    IntakeCapture bounded work.
  2. 02
    DelegateRoute it to an agent.
  3. 03
    ActWork in isolation.
  4. 04
    VerifyGate with evidence.
  5. 05
    PersistSave state and receipts.
  6. 06
    DecideChoose the next action.
RetryFeed back evidence
EscalateHand off judgment
ExitClose a verified goal

03 / Pattern library

Choose the control policy, not the model.

The same agent can repair CI, monitor a rollout, or test a system adversarially. The right loop defines the different trigger, permissions, proof, memory, budget, and human owner each job requires.

Why selection matters

A generic "keep trying" loop can retry a judgment call, let the acting model approve itself, forget evidence between runs, or take write actions where observation and escalation are safer. A pattern gives a recurring job a reviewable operating policy before you adapt the exact contract.

Use a loop when

  • Work returns through a schedule, event, queue, or recurring condition.
  • An external check can prove progress or completion.
  • State, permissions, retries, cost, and human handoff can be bounded.

Use one supervised run when

  • The task is genuinely one-off.
  • Completion depends mainly on open-ended human judgment.
  • No safe permission boundary or useful persistent state can be defined.
01Name the recurring job

Identify the signal that returns and the outcome that should improve.

02Define proof

Name evidence a machine or reviewer can inspect to decide pass.

03Bound action

Set readable and writable scope, non-goals, retries, time, and cost.

04Plan the next pass

Decide what persists, retries, escalates, or exits after each result.

Pattern → contract → runtime. Select the operating model below, adapt its schema-checked contract to your environment, then choose where it runs based on persistence, isolation, and permissions.

Compare every contract field →
Build & maintain"My PR is stuck"PR babysitterDone when: checks pass, review threads resolve, and merge state is current. Build & maintain"CI keeps failing"CI repair loopDone when: the original failing command passes with a scoped patch. Build & maintain"The docs may be stale"Docs drift collectorDone when: verified mismatches are patched and examples still run. Build & maintain"Updates pile up"Dependency triage loopDone when: safe updates pass tests and risky upgrades have an owner. Build & maintain"Bugs need systematic discovery"Bug hunting loopDone when: each accepted finding has a reproduction or failing test. Build & maintain"Release notes are a chore"Release-note loopDone when: every shipped change maps to a source and audience note. Operate & observe"A deploy needs monitoring"Deploy verifierDone when: synthetic checks and rollout thresholds remain within policy. Operate & observe"An incident just paged"Incident response loopDone when: impact, evidence, timeline, and accountable owner are recorded. Operate & observe"A dataset keeps drifting"Data-quality loopDone when: hard quality rules pass before a version is promoted. Operate & observe"Agent spend is rising"Cost-control loopDone when: spend falls on comparable work without quality regression. Operate & observe"Model choice is ad hoc"Model-routing loopDone when: routing meets quality, latency, privacy, and cost tolerances. Operate & observe"Performance regressed"Performance regression loopDone when: a controlled benchmark confirms recovery and correctness. Learn & optimize"Feedback is noisy"Feedback clustererDone when: themes cite sources and separate frequency from severity. Learn & optimize"Agent evals regressed"Evaluation regression loopDone when: targeted evals return to baseline without scorer changes. Learn & optimize"A stable system should improve"Benchmark optimization loopDone when: repeated measurements improve with protected metrics intact. Learn & optimize"The agent's knowledge is stale"Knowledge freshness loopDone when: the corpus passes provenance, freshness, retrieval, and leakage gates. Govern & protect"Sensitive changes need review"Security review loopDone when: findings cite evidence and approval boundaries stay intact. Govern & protect"A change needs sign-off"Enterprise approval loopDone when: every gate has a recorded human decision and audit trail. Govern & protect"Accessibility checks failed"Accessibility regression loopDone when: the exact regression is fixed and human criteria are approved. Govern & protect"The agent needs adversarial testing"Adversarial red-team loopDone when: findings are reproduced, minimized, reported, and regression-tested.

04 / Where loops run

Pick the runtime deliberately.

Five adaptable templates cover sessions, schedules, worktrees, Actions, and cron. Three executables demonstrate test repair, threshold monitoring, and idempotent queue work. The runtime selection guide compares persistence, file access, isolation, and permissions.

Runtime map progressing from a nearby session to a local desktop schedule, isolated CI and cloud execution, and a recoverable durable worker.
Keep the contract stable; change the trigger, isolation, and permission wiring.
Adaptable template

Claude Code /loop

Use while present in a coding session; repeat a bounded command and keep progress in a file.

 Adaptable template

Desktop scheduled task

Use when local files need a schedule, a last-run marker, and missed-run guardrails.

 Adaptable template

Codex automation

Use for isolated background repository work with declared checks and reviewable receipts.

 Adaptable template

GitHub agentic workflow

Use when GitHub events or cron should produce issues, artifacts, or pull requests.

 Adaptable template

Shell / cron

Use when an existing agent CLI only needs OS scheduling, locks, and a progress file.

 Executable

Test repair

Run a failing command, delegate its evidence, and stop only when that same external check passes.

 Executable

Threshold monitor

Poll a metric, persist samples, and escalate on a breached boundary without auto-remediation.

 Executable

Queue worker

Process bounded JSONL work items with external verification and durable receipts.

05 / Maturity model

Use the smallest loop that can do the job.

The level describes how one workflow is triggered, remembered, verified, divided, and supervised. It measures operating capability, not model intelligence or product prestige.

Read capability, not ambition.

Start with the recurring outcome, evidence, risk, and human owner. Move up only when the current level produces a repeated failure or cannot meet an operating requirement; every added level brings more code, permissions, observability, and maintenance.

Build in order: durable state before longer unattended runs, external verification before more agents, and production controls before the loop can affect users or infrastructure.

Loop Maturity Model progressing from manual prompting through scripted retry, scheduled, stateful, self-verifying, multi-agent, and production-supervised loops.
Levels are cumulative capabilities. Many useful workflows should stop at Level 2 or 3.
00

Manual prompting

A person holds the state, supplies each next instruction, and judges the result.

Why
Keeps one-off, ambiguous, or high-judgment work under direct supervision.
Example
A developer asks an agent to fix one failing test, reviews the diff, and decides whether to continue.
Progress signal
The same task and feedback sequence recur often enough to encode.
01

Scripted retry

A bounded wrapper reruns one agent and feeds back an external failure.

Why
Removes repetitive reprompting while preserving one objective and one feedback signal.
Example
Run pytest and return its failure output for at most three repair attempts.
Progress signal
The job should start from a schedule or event without a person launching it.
02

Scheduled loop

A schedule or event triggers fresh intake, one bounded run, and a report or artifact.

Why
Removes manual launch and makes cadence, idempotence, and no-work exits explicit.
Example
A nightly docs-drift scan reports only when code and documentation disagree.
Progress signal
Work spans runs, repeats items, or loses context between invocations.
03

Stateful loop

Durable checkpoints and receipts record completed work, blockers, evidence, and the next action.

Why
Survives restarts, avoids duplicate work, and makes every run resumable and inspectable.
Example
A feedback clusterer stores processed IDs, prior themes, and the last successful checkpoint.
Progress signal
Stable external evidence can decide whether a transition or completion is valid.
04

Self-verifying loop

Tests, evals, policy checks, traces, or an independent evaluator gate progress and exit.

Why
Replaces the agent's claim of success with reviewable evidence.
Example
A CI repair exits only when the original failing command passes and the diff remains in scope.
Progress signal
One role becomes a bottleneck, duties must be separated, or independent review is required.
05

Multi-agent loop

Specialists divide discovery, action, review, and judgment through explicit handoffs and shared state.

Why
Adds separation of duties and parallel expertise without letting the acting agent approve itself.
Example
A security loop uses an explorer, a reproducer, and an independent reviewer.
Progress signal
The loop can affect production, customers, money, credentials, or other high-impact systems.
06

Production-supervised loop

Telemetry, least privilege, budgets, approvals, rollback, and human escalation govern every run.

Why
Controls blast radius and makes production work observable, interruptible, and accountable.
Example
A deploy verifier pauses on a breached threshold and hands rollback approval to the release owner.
Harden next
Service objectives, replay, permission reviews, failure drills, and cost controls.

06 / Resource atlas

Find evidence, not just links.

Filter 874 resources by goal, loop layer, lifecycle, artifact type, and evidence class. Open any result to see its contribution, novelty, impact, scope, publication details, and original source.

Last source check, 2026-07-21 UTC: 821 public links opened successfully, 2 required access, 49 point to files in this repository, and none were broken or unreachable. View the results or report a correction.

Inner loopModel recurrence

A learned block refines hidden or latent state inside one inference. Included as an adjacent foundation.

Task loopAgent execution

The model reasons, calls tools, observes results, and updates working state while solving one task.

Outer loopOperational governance

Triggers, evidence gates, durable state, budgets, handoff, and exit govern repeated work.

Preparing 874 resources...

Preparing the resource index...

07 / Future directions

Turn open problems into evidence.

Fifteen workstreams define a decision, minimum artifact, metrics, starter slice, and completion gate. Build the foundations first, then prove scale and adoption.

Foundation

  • Challenge verifiers with hard negatives and tampering.
  • Recover state and side effects after injected crashes.
  • Reconstruct every decision from receipts under least privilege.

Completion signalThe loop can be interrupted, audited, attacked, recovered, and stopped without losing control of evidence or effects.

Scale

  • Separate model, harness, verifier, and loop effects.
  • Test long horizons, stop rules, and runtime portability.
  • Compare quality, recovery, latency, cost, and human effort.

Completion signalGains survive matched budgets, adverse conditions, multiple runtimes, and full cost accounting.

Adoption

  • Baseline one frequent, verifiable, reversible domain job.
  • Shadow first, then promote through measured approval gates.
  • Rehearse handoff, rollback, incident response, and retirement.

Completion signalA named operator can understand, interrupt, update, and retire a useful loop from external evidence.

01 / ScopeChoose one recurring task

Name the operator, trigger, evidence gate, and consequence of error.

02 / CompareFreeze fair baselines

Test current operation, single pass, fixed retry, and a cost-matched candidate.

03 / StressExercise failure paths

Inject interruption, stale state, verifier conflict, attack, and budget exhaustion.

04 / PublishRelease the whole result

Share contracts, receipts, costs, unsuccessful runs, and rejection criteria.

Start a 90-day project

Choose the researcher, runtime, application, or security plan, then use the shared protocol and proposal template to make the result comparable.

Open 15 workstreams

08 / Contribute

Improve the evidence or share a loop.

Share an original or official source, correct an entry with primary evidence, or document a loop you have run.

Suggest a resource

Share one original or official source and a precise summary in under five minutes.

Correct an entry

Fix a summary, contribution, date, venue, identifier, or source link with primary evidence.

Share a loop

Submit a real or anonymized operating example with no pull request required.

Join the discussion

Compare operating patterns with other loop builders.

09 / FAQ

Questions that define the boundary.

Use these tests to decide whether a recurring agent system needs a loop.

What is loop engineering?

Loop Engineering is the practice of designing recurring AI-agent and coding-agent systems that discover work, delegate it, verify results, persist state outside the model, decide what happens next, and run again.

How is it different from prompt, context, and harness engineering?

Prompt, context, and harness engineering improve one agent run. Loop Engineering governs how agent work repeats, verifies, persists state, and escalates over time.

When should you use an agent loop?

Use a loop when work recurs, external evidence can verify progress, useful state should persist, actions and budgets can be bounded, and a human owner can handle exceptions. Prefer one supervised run when the task is one-off, completion is mainly subjective, or no safe permission boundary can be stated.

What belongs in a loop contract?

A Loop Contract is a reviewable operating specification for one recurring agent job. It fixes the objective, trigger, intake, workspace and permissions, context, roles, external verification, durable state, budget, escalation path, and success or blocked exit so repeated runs do not depend on hidden defaults.

Does every loop need to reach the highest maturity level?

No. Choose the lowest level that meets the job's continuity, evidence, and blast-radius requirements. Many useful workflows should stop at Level 2 or 3. Persist state before increasing autonomy, add external verification before more agents, and reserve production supervision for workflows with production impact.

Which runtimes can run agent loops?

The same loop can run as a Claude Code loop or scheduled task, a Codex automation, a GitHub agentic workflow, a shell or cron wrapper, or a durable-execution runtime.

10 / Community momentum

Follow the star trail.

Each milestone marks more researchers and builders discovering the field guide, from the first save to the latest GitHub count.

GitHub star growth for Awesome Loop Engineering

Star the repository to keep the field guide nearby and help more researchers, engineers, and developers find its resources and implementation kit.

Star on GitHub