Loop Engineering: Designing Bounded, Verifiable Agent Systems for Software Delivery

White paper · Research and editorial analysis · July 2026

AI coding has moved beyond autocomplete, but that does not mean a single oversized prompt can reliably run an engineering organization. The useful unit of design is increasingly a loop: a bounded system that gives an agent a goal, lets it inspect and act on a real environment, measures the result with independent evidence, records what happened, and either continues, stops, or escalates. This paper calls the discipline of designing that system loop engineering.

That definition is deliberately practical. It is not the name of an Anthropic product or an established formal standard. It is a synthesis grounded in the open-source Loop Engineering repository, the documented behavior of Claude’s agent loop, and a growing body of agent and software-engineering research. The central claim is modest: dependable agentic development comes less from making one prompt more eloquent and more from making the surrounding feedback system observable, constrained, and accountable.

Executive summary

An AI coding agent can examine a repository, write files, run tools, read failures, and try again. That is an internal action loop. An engineering loop is broader. It defines what work may enter the system, what context and authority the agent receives, what evidence can count as success, where durable state lives, how costs are capped, and which decisions remain human decisions. It is the difference between “please keep fixing this” and a reproducible operating model.

Five conclusions follow.

1. Verification is the center of the loop. A model’s declaration that it is done is not evidence. Tests, builds, linters, screenshots, policy checks, review, and observed production signals are the feedback that closes the loop. Anthropic’s Claude Code best-practices guide makes the same operational point: give the agent a check it can run so it can inspect a pass/fail result and iterate rather than leave validation to a person.
2. Autonomy needs boundaries, not just more retries. Every loop should have a bounded scope, allowed tools, time or turn limits, a spend budget, an attempt cap, and explicit escalation conditions. A retry without a new signal is not learning; it is often just expensive repetition.
3. State is a product surface. Git history, issue status, test output, a run ledger, a feature list, and a small durable memory are what allow a system to resume intelligently. Keeping all state in an ever-growing chat transcript is fragile because context is finite and degraded context produces degraded decisions.
4. Separation of duties improves trust. The agent that proposes or implements a change should not be the only entity that approves it. Independent evaluators, deterministic gates, isolated worktrees, and human review are not bureaucracy; they are the control surfaces that make unattended operation safer.
5. More “agentic” is not automatically better. For a stable, well-understood task, a deterministic workflow can be cheaper, easier to audit, and more reliable than an open-ended agent. The correct question is not “Can we add a loop?” but “What uncertainty requires adaptive decision-making, and what evidence will tell us that the loop is earning its authority?”

For leaders, the implication is straightforward. Treat loops as production systems with objectives, permissions, budgets, telemetry, and incident response—not as clever prompts. For individual engineers, begin with report-only loops and promote autonomy only after evidence shows that the loop is useful, bounded, and comprehensible.

1. What “loop engineering” means—and what it does not

In this paper, loop engineering is the design of recurring, feedback-driven systems around AI agents. A useful shorthand is:

objective → observe → decide → act → verify → record → stop / escalate / repeat

Each arrow represents a design decision. Who chooses the objective? What sources are trustworthy during observation? Which tools can create side effects? What verification is independent of the agent’s own assertion? What data is retained for the next run? When does the system stop rather than continue? Those questions are engineering questions, even if the model call at the center is probabilistic.

The term is associated in practice with Cobus Greyling’s open-source toolkit and related writing by Greyling and Addy Osmani. The repository presents patterns, starter kits, readiness checks, and command-line tools for recurring coding-agent work. Its conceptual model combines scheduling, isolated worktrees, reusable skills, MCP or other connectors, a maker/checker split, and durable state. Its reference flow is scheduler to triage to state to isolated implementation to verification to a connector or human gate.

That is a useful implementation framing, not a proven universal architecture. The repository’s patterns and failure stories are practitioner guidance, not independently audited outcome research. Its readiness checklist can reveal whether key controls are documented; it cannot prove that a loop is correct, secure, or economically worthwhile. This distinction matters because a scorecard can be mistaken for a safety guarantee.

Loop engineering also does not mean letting a model run indefinitely. It does not mean replacing tests with self-critique, replacing technical judgment with an approval button, or assigning the same permissions to every task. And it is not a claim that a particular vendor officially teaches a product called “Loop Engineer.” Anthropic’s current official vocabulary is more precise: its materials discuss the agent loop, goal conditions and Stop hooks, subagents, hooks, worktrees, non-interactive execution, and evaluation. Those are the building blocks from which a loop can be engineered.

2. From a model turn to an engineered system

At the model level, an agent loop is simple. A user or application supplies a prompt; the model decides whether to call a tool; the tool produces a result; that result returns to the model; and the process continues until the model returns a final response or a limit is reached. The Claude Agent SDK documentation describes this kind of repeated model-and-tool execution and exposes controls such as permissions, hooks, session handling, and turn limits.

The intellectual predecessor is the ReAct pattern: interleave reasoning with actions that retrieve evidence from an environment. Reasoning can update a plan; actions can reveal that the plan was wrong. In software work, the environment is unusually rich: a repository, dependency graph, test suite, issue tracker, CI logs, compiler, linter, browser, monitoring system, and version-control history. The quality of the interface to those tools therefore has a major effect on the outcome. SWE-agent made this argument directly by studying agent–computer interfaces for repository navigation, editing, and test execution.

But an internal tool loop is insufficient for production engineering. Consider a model that sees a test failure, changes a timeout, and gets a green run. It may have silenced a flaky test rather than fixed the defect. It may have changed an assertion to match a broken behavior. It may have passed only a narrow suite while damaging a deployment workflow. The loop had feedback, but the feedback was weak and the action surface was too broad.

An engineered loop adds an outer control layer:

Control layer	Question it answers	Concrete examples
Objective	What outcome is worth pursuing?	“Classify new issues”; “repair one reproducible CI failure”; “draft a changelog.”
Scope	What is in and out of bounds?	Repository, branch, file allowlist, maximum files changed, non-goals.
Authority	What may the system read or change?	Read-only issue access; a disposable worktree; no production database writes.
Evaluator	What observable evidence is required?	Fail-to-pass tests, build, lint, visual diff, policy scan, reviewer verdict.
State	What survives the current context?	Git commits, run ledger, issue lock, concise findings, budget counter.
Governance	When must the loop stop or ask?	Risk-path gate, attempt cap, spend cap, ambiguity threshold, human approval.

This outer layer makes a loop inspectable by someone who did not author the original prompt. It also makes failures diagnosable. A team can ask whether a failure came from bad task intake, missing context, an overly permissive tool, a poor evaluator, stale state, or a weak escalation policy—instead of treating “the AI failed” as a single undifferentiated event.

3. External verification is the engine, not the last step

Any system can generate a plausible explanation of its own work. That is why self-reported completion is a poor success metric. A robust agent loop needs an evaluator that observes the effect of a proposed change from outside the agent’s narrative. The stronger the consequence of the action, the more independent that evaluator should be.

For coding tasks, tests are often the first useful evaluator. SWE-bench illustrates an outcome-oriented design: a task is built from a real repository state and a real issue, then assessed by whether previously failing tests pass after the candidate patch. This is much more meaningful than scoring a patch by whether it looks sensible in prose. Still, it is not the whole story. A green test suite is evidence about known behavior, not a certificate of architecture, security, operational readiness, or future maintainability.

Anthropic’s documented practice is appropriately concrete: give Claude a test, build, linter, or screenshot comparison it can execute. The agent can then work, run the check, read the result, and iterate. The same guide recommends separating exploration, planning, implementation, and review; it also recommends an adversarial review in a fresh context before a task is considered done. These are not decorations around the loop. They change the information available at the moment the agent decides whether to continue.

Four kinds of evaluator are particularly useful:

1. Deterministic functional checks. Unit, integration, contract, and end-to-end tests; type checking; compilation; schema validation; and reproducible browser checks. They are usually cheap to repeat and easy to record.
2. Constraint and policy checks. Secret scanning, dependency policy, static analysis, license checks, path allowlists, migration rules, and deployment policy. These do not prove correctness, but they limit known unsafe classes of action.
3. Independent review. A fresh agent, a different model, a specialist reviewer, or a human compares the output to explicit acceptance criteria. Fresh context matters because the reviewer is less likely to inherit the implementer’s mistaken framing.
4. Outcome monitoring. CI status after merge, error rates, rollout metrics, support signals, and incident reports. This is the feedback that tells a team whether a locally successful loop is actually helping the system over time.

The evaluation hierarchy should match the task. A changelog-drafting loop may need source links, a factuality review, and a human editor. A CI repair loop needs reproduction, an isolated test environment, and a strong rule against disabling tests to obtain green. A production deployment assistant needs even more: staged rollout, reversal, and human approval. The point is not to impose every gate on every task. It is to make the evidence proportional to the blast radius.

Research on iterative agents supports feedback, but also reveals its limits. Reflexion explores retaining textual reflections from feedback in episodic memory to guide later attempts. Self-Refine examines generate–critique–revise cycles. These are valuable patterns for making an agent reconsider an answer, yet they are not substitutes for an external test. A system that writes both the proposal and the critique can converge on a shared misconception. Treat model-generated critique as a supplement; make observed evidence the decision signal whenever possible.

4. The seven components of a durable software loop

A practical software loop can be decomposed into seven components. The components need not be separate services, and small projects should avoid unnecessary machinery. The distinction is useful because it exposes missing responsibilities.

4.1 Intake: make the work item testable

Every loop starts with an intake boundary: an issue, failed check, scheduled report, dependency update, or explicit request. The input should include a goal, scope, constraints, and a definition of done. If a ticket is too ambiguous to verify, the safe action is clarification or escalation—not speculative implementation. A good intake record distinguishes facts from assumptions and lists the data sources the agent may trust.

This is where human judgment often belongs. The model can propose questions, search the codebase, and summarize trade-offs, but it should not silently choose product behavior from an ambiguous sentence. A loop that accepts vague work items will generate apparent momentum while embedding unreviewed decisions in code.

4.2 Planner: turn the goal into a bounded approach

Planning is most useful when a change crosses files, services, or unfamiliar territory. The official Claude Code guidance recommends explore–plan–implement for this reason. In an engineered loop, the plan should name the expected evidence: which tests must fail first, which files are in scope, what commands will verify success, and which changes require a gate. This makes a plan a testable contract rather than a private chain of thought.

4.3 Context and memory: store handles, not a novel

Long-running agents create an information-management problem. Logs, source files, tool output, and partial attempts consume context. Anthropic’s context-engineering guidance recommends just-in-time retrieval, compacted summaries, and focused subagents rather than attempting to keep an entire project in one conversation. The lesson is broader: durable state should preserve decisions, identifiers, evidence, and next actions, while detailed artifacts remain retrievable by reference.

A healthy loop state record might contain an issue ID, commit SHA, current branch or worktree, reproduction command, last evaluator result, attempt count, owner, budget consumed, and escalation reason. It should not contain credentials, raw customer data, or unbounded copied logs. State must be read at the start of a run, updated at the end, and pruned when the underlying issue closes. Otherwise the loop begins acting on ghosts.

4.4 Actor: make side effects explicit and reversible

The actor is the portion allowed to modify a file, create a branch, comment on an issue, or open a pull request. Its authority should be smaller than the system’s theoretical capability. In practice that means scoped credentials, read-only defaults, worktree isolation, protected branches, and allowlists for unattended changes. The Loop Engineering safety guide recommends no auto-merge by default, denylisted sensitive paths, and human gates for authentication, payments, personal data, infrastructure, dependency changes, large diffs, and repeated failure.

These controls have familiar software-security analogues. SLSA emphasizes provenance and integrity across a software supply chain. Agentic systems add new paths to the supply chain: instructions, tool definitions, connector permissions, retrieved web content, model output, and automated commits. A loop should therefore record which agent configuration and tool versions produced an action, just as a build system records how an artifact was made.

4.5 Evaluator: judge against evidence, not enthusiasm

The evaluator receives the diff, plan, and acceptance criteria, then runs its checks independently. A maker/checker split is one of the strongest simple patterns available. It may be implemented as a deterministic CI job, a separate model invocation, a code-review agent with narrower tools, or a human review. The evaluator should be able to reject a change and state which evidence is missing. A generic “looks good” is verifier theater.

4.6 Governor: control cadence, cost, and termination

The governor decides whether another attempt is allowed. It enforces max attempts, max turns, wall-clock time, token or currency budget, notification policy, and escalation rules. These are product requirements. A loop that repeatedly applies a near-identical patch to a flaky test is not becoming more autonomous; it is failing to recognize a stop condition.

The official Ralph Wiggum Plugin in Anthropic’s Claude Code repository is a useful concrete example of bounded iteration. It documents a self-referential development loop driven by persisted files, Git state, test feedback, a completion promise, and a required maximum-iteration escape hatch. The original Ralph concept is attributed there to Geoffrey Huntley; neither the pattern nor the plugin makes unlimited retry safe. Its value is that it makes the exit condition explicit.

4.7 Human handoff: turn uncertainty into a useful queue

Escalation is not a failure state. It is the correct output when a task is ambiguous, policy-sensitive, repeatedly unsuccessful, or too consequential for the granted authority. A useful handoff includes the objective, evidence gathered, attempted actions, current state, relevant logs or links, a concise decision request, and a recommended safe next step. It should arrive in a place an owner will actually inspect—not merely be written into an obscure file.

5. Inside the Loop Engineering repository

The supplied Loop Engineering repository is a practical reference implementation of these ideas. At the main-branch revision reviewed for this paper, it is MIT licensed and provides patterns, starter folders, tool-specific examples, safety documentation, and npm command-line tools. It is not a monolithic agent runtime. It is closer to an operational kit for designing the surrounding system.

Its primitives documentation identifies automation and scheduling, worktrees, skills, plugins and connectors, subagents, and durable memory or state. The design is cross-tool: the project supplies mappings and examples for Claude Code, Codex, Grok, OpenCode, OpenClaw, Cursor, Windsurf, and GitHub Actions. That portability is valuable because it keeps the control model separate from any one model interface.

The repository also provides seven recurring patterns: Daily Triage, PR Babysitter, CI Sweeper, Dependency Sweeper, Changelog Drafter, Post-Merge Cleanup, and Issue Triage. Each pattern should be read as a starting template, not a mandate. The risk profiles are very different. A report-only changelog loop can safely begin with minimal authority. A loop that changes CI configurations should be one of the last systems promoted to unattended operation.

The maturity model captures that difference well:

Level	Purpose	Minimum posture
L0 — Draft	Document the intended loop.	A goal, scope, and a human owner; no recurring action.
L1 — Report	Observe and summarize.	Read-only access, durable state, useful triage, human decides action.
L2 — Assisted	Propose narrowly scoped changes.	Isolated worktree, independent verification, review before merge.
L3 — Unattended	Act inside a tightly specified envelope.	All prior controls plus budgets, gates, auditability, and proven behavior.

The project’s quickstart explicitly recommends a report-only first week, then a staged progression toward assisted and, only when justified, unattended behavior. This is sound operational advice. The fastest way to lose trust is to start with a high-frequency loop that modifies code before anyone understands its false-positive rate or cost curve.

Its command-line tool set maps directly to the control layers described above:

• loop-init scaffolds a selected pattern, state artifacts, budget files, and starter instructions.
• loop-audit checks documented readiness signals and suggests missing controls.
• loop-cost estimates spend for a chosen cadence and maturity level; it is a planning estimate, not an invoice.
• loop-context can read a ledger and trip a circuit breaker for repeated error, failure, iteration, or budget conditions.
• loop-worktree helps create and clean up isolated Git worktrees for attempts that change code.
• loop-sync checks for drift between state and loop configuration; its auto-fix path is explicitly experimental and should be treated accordingly.
• loop-mcp-server offers a read-only runtime lookup surface for patterns, skills, and project state. Read-only does not make it consequence-free: project state may still be sensitive.

The project also documents real failure modes, including infinite fix loops, stale state, verifier theater, notification fatigue, token burn, scope overreach, parallel collisions, and escalation failure. The CI Sweeper failure story is particularly useful as a cautionary case study because it reports high token consumption and a risky proposed change caught in human review. It should not be generalized as benchmark evidence, but it illustrates why cost, approval, and independent verification must be designed before a loop scales.

6. Claude Code: the official foundations, without false attribution

There is no official Anthropic tutorial titled “Loop Engineering.” That absence is informative rather than problematic. Anthropic’s official documentation provides the lower-level mechanisms and design guidance from which teams can build their own loops.

First, the Agent SDK loop supplies a model–tool execution cycle. Second, Claude Code best practices describes how to give agents verifiable checks, explore before planning, use subagents for investigation, manage context, run non-interactively in CI, use worktrees for parallel sessions, and run an adversarial review before accepting a result. Third, the Agent SDK overview explains how applications can programmatically access the tools, context management, and permission controls behind agentic work.

These official materials also make a useful distinction between capability and control. Claude Code can run shell commands and edit files, but it operates with permission modes and tool restrictions. Anthropic’s discussion of Auto Mode describes why permission fatigue is a real problem and why safety cannot be reduced to clicking every prompt. It presents layered controls around what agents read and what they do, including boundaries for file operations, external actions, and subagent handoffs. The general lesson is not “delegate all approvals to a classifier”; it is that a loop needs explicit trust boundaries.

A simple Claude-oriented loop might use the following components:

# A scheduler or CI job starts a bounded session.
claude -p "Read the issue, reproduce the failure, propose the smallest fix,
run the named tests, and stop if a denylisted path is required." \
  --max-turns 20

# A separate evaluator runs deterministic CI and checks the diff.
# A human reviews any pull request before merge.

The exact command and permission configuration should match current official CLI documentation, not a copied community snippet. For example, the official guide documents non-interactive execution and recommends restricting tools for unattended work. The Loop Engineering repository’s Claude examples are useful community implementation guidance, but a team should not claim that every slash command in a third-party scaffold is an official Claude Code primitive unless the official documentation independently confirms it.

The most important Claude Code lesson may be the simplest: “done” should be represented by a check the agent cannot merely talk its way around. A goal condition, a Stop hook, a test command, or a reviewer’s rejection criteria turns a conversational instruction into a closed control loop.

7. Safety, security, and least privilege

Loop design is security design because a loop combines untrusted inputs with tools that can cause side effects. A web page, issue comment, build log, repository file, or connector response can contain instruction-like text. If the agent treats that text as authoritative, it may be manipulated into changing scope or transmitting data. This is the core concern behind OWASP’s LLM risk guidance and the broader class of prompt-injection attacks.

OpenAI’s prompt-injection security analysis frames the practical danger as a path from an attacker-controlled source to a sensitive sink: untrusted content influences an agent that can transmit information, follow a link, invoke a tool, or change a system. That source–sink model is useful for coding loops. Any loop that reads issues or web documentation and then has write access to source control, deployment, chat, or customer data should be threat-modeled as a system that crosses trust boundaries.

Minimum controls should include:

• Least-privilege credentials. Separate bot identities and narrowly scoped tokens. A triage loop needs read access, not merge rights. A documentation loop should not inherit cloud-admin credentials.
• Path and action policy. Denylist secrets, authentication, payments, production infrastructure, migrations, and credential files unless a human explicitly authorizes the specific change. Restrict destructive Git, package, database, and network operations.
• Isolation. Use disposable worktrees, containers, sandboxes, or ephemeral environments for code-changing attempts. Keep production data and credentials out of the default execution context.
• Confirmation at the boundary. Require human approval before publishing, deploying, merging, changing access policy, sending external messages, or transmitting sensitive data.
• Observability and reversibility. Log tool calls, inputs, decisions, diffs, evaluator output, and handoffs. Prefer branches, pull requests, feature flags, dry runs, and rollback plans over irreversible direct action.
• Incident response. Define how to pause the scheduler, revoke credentials, revert output, inspect the trace, notify owners, and tighten the policy before a restart.

The NIST AI Risk Management Framework organizes continuous risk work as govern, map, measure, and manage. That structure maps well to loop engineering: govern the authority and owner; map data, tools, and impacts; measure evaluator quality and outcomes; manage thresholds, incidents, and improvements. The Generative AI Profile is a useful companion for teams turning those principles into operational controls.

8. Economics, telemetry, and the problem of silent failure

Agent loops incur more than model-token cost. They consume API calls, CI capacity, review attention, queue space, storage, external-tool quotas, and engineering trust. A system can be technically capable but economically irrational if it performs a long chain of work for empty triage, repeats a failed attempt without new evidence, or sends so many notifications that people mute the channel.

Measure the loop as a service. At a minimum, record run count, items observed, items acted upon, completion rate, rejection rate, evaluator failures, retry distribution, time to escalation, token or currency spend, CI minutes, cost per accepted outcome, and human-review time. Add quality measures specific to the task: regressions after merge, rollback rate, false-positive triage rate, reopened issues, reviewer acceptance, or documentation corrections. Metrics should be interpreted with context. A high number of pull requests is not a success metric if most are rejected.

The repository’s operating guidance and cost estimator reinforce the importance of cadence, early exit, budgets, and kill criteria. Before scheduling a loop, model its likely path: cheap triage first; expensive research or subagents only for actionable items; code modification only after a strong signal; separate verification; and an exit when the queue is empty. This funnel is usually better than applying the largest available model and every connector on every tick.

Notification design is equally important. A loop should distinguish “I ran,” “I found something,” and “a human decision is needed.” The first belongs in logs, the second may belong in a digest, and the third deserves a targeted alert with enough evidence to decide. If every heartbeat becomes an interruption, an organization loses the very human oversight that makes automation safe.

9. How to evaluate a loop before trusting it

Evaluating an agent loop differs from evaluating a single response. The object of evaluation is a trajectory through an environment: the input, actions, tool results, intermediate state, final artifact, cost, and side effects. Anthropic’s guide to agent evaluations recommends defining tasks, trials, graders, traces, and outcomes; using deterministic grading where possible; repeating trials for non-deterministic systems; and reviewing transcripts rather than relying only on aggregate scores.

A practical evaluation program has four layers.

1. Offline capability suite. Representative tasks with controlled environments and explicit expected outcomes. Include normal cases, edge cases, ambiguous inputs, missing prerequisites, and policy-sensitive paths.
2. Regression suite. Historical failures, prior incidents, rejected pull requests, and adversarial examples become permanent tests. A loop should not silently reintroduce a known mistake after a model or prompt update.
3. Shadow or report-only run. The loop observes live work but does not act. Compare its recommendations with what experienced engineers actually did. This estimates relevance and false-positive cost before authority is granted.
4. Production monitoring. Once action begins, monitor outcome quality, policy violations, latency, cost, and human overrides. Use canaries and gradual rollout; do not promote a loop on the basis of a handful of impressive demos.

Benchmarks help define the discipline but should not be overread. SWE-bench captures issue-resolution behavior in real repositories; Terminal-Bench evaluates realistic command-line tasks; and OSWorld studies open-ended computer environments. None of these alone measures whether a loop will safely maintain a particular company’s codebase, security posture, or approval workflow. Use external benchmarks to understand categories of capability, then build an internal suite around actual risk.

10. Multi-agent loops: parallelism with a coordination tax

Multi-agent designs can be excellent when a task decomposes cleanly: one agent researches a failing subsystem, another maps test coverage, a third inspects a diff for security issues, and an orchestrator synthesizes the evidence. Anthropic’s multi-agent research-system write-up describes an orchestrator–worker pattern and warns that parallel workers increase token use and coordination complexity. The same trade-off applies to code.

Use parallelism for independent discovery, evidence gathering, or review—not as a default response to every task. Give each worker a narrow objective, a bounded tool set, a separate context, and a structured return artifact. Do not let several actors edit the same working tree. The Loop Engineering project’s multi-loop guidance recommends one owner per branch, separate state files, shared constraints, aggregate budgets, and locks that record what each loop is acting on. These are familiar concurrency controls expressed in agentic terms.

Maker/checker is often the first multi-agent pattern worth adopting. The maker receives the task and prepares the smallest valid change. The checker gets the criteria and diff, runs independent tests, and looks for reasons to reject. For complex work, add specialized reviewers only when they bring distinct evidence: security, accessibility, data migration, or domain rules. More agents using the same prompt, same tools, and same assumptions are often correlated redundancy rather than independent validation.

11. When not to use a loop

One of the most mature loop-engineering decisions is choosing not to build a loop. Anthropic’s guidance on effective agents argues for starting with the simplest solution and adding agentic behavior only when dynamic decision-making is necessary. The research paper Agentless is an important counterweight: on its evaluated software-repair setting, a simpler localization–repair–validation approach achieved strong results without a complex autonomous agent.

Prefer a deterministic workflow when the task has stable inputs, known transformations, low ambiguity, and a clear schema. Examples include formatting, a controlled dependency report, a fixed database migration generator, a known lint autofix, nightly artifact validation, or a standardized release-note template. A script is cheaper to test, easier to audit, and more predictable than an agent deciding how to improvise.

Do not automate beyond human control when the action is irreversible, material, or underspecified: changing production access, handling secrets or personal data, performing financial operations, deleting data, making legal or policy decisions, or merging a behavior change with inadequate tests. An agent may still support the human by gathering evidence, producing a plan, preparing a draft, or running a simulation. Assistance and delegation are not the same thing.

12. A phased adoption blueprint

The following twelve-week blueprint is intentionally conservative. Its purpose is to establish evidence before privilege.

Phase 0: establish the baseline

Choose one painful but bounded workflow. Define the owner, input sources, outcome, non-goals, risks, existing manual steps, and current cost. Identify the deterministic checks that already exist and the gaps that must be filled before automation. Write the stop and escalation conditions before building the actor.

Phase 1: report-only triage

Run on a modest cadence with read-only tools. Produce a structured report and update a small state ledger. Measure relevance, false positives, time saved, and notification quality. Have a human compare the loop’s recommendations to real decisions. Improve the intake and evidence requirements until the report becomes trusted.

Phase 2: assisted change in isolation

Permit a loop to create a worktree or branch and propose a small patch. Require a reproduction, a test or build result, a diff summary, and an independent evaluator. Do not auto-merge. Track reviewer acceptance and the reasons for rejection. Use rejected attempts to refine scope, not merely to add more prompt text.

Phase 3: narrow unattended action

Only after repeated evidence should a loop receive narrowly specified unattended authority: for example, opening documentation-only pull requests, applying a known formatter under an allowlist, or updating a non-production status label. Enforce budget, rate, and attempt caps. Keep human gates around consequential actions. Test the kill switch and rollback path before the first unattended run.

Phase 4: continuous evaluation and governance

Review the loop’s outcomes on a fixed schedule. Audit permissions, connector scopes, dependencies, and secret exposure. Add incidents and near-misses to the regression suite. Prune stale state. Revisit whether the loop should be simplified, narrowed, paused, or retired. The goal is not maximum automation; it is a sustainable improvement in quality-adjusted throughput.

13. A minimum viable loop, implemented cautiously

For a team using the Loop Engineering toolkit, a conservative starting sequence looks like this:

# Scaffold a report-only pattern for the chosen agent integration.
npx @cobusgreyling/loop-init . --pattern daily-triage --tool claude

# Estimate cadence and maturity-level cost before scheduling.
npx @cobusgreyling/loop-cost --pattern daily-triage --level L1 --cadence 1d

# Inspect documented controls and receive recommendations.
npx @cobusgreyling/loop-audit . --suggest

# For a later L2 code-changing attempt, create an isolated worktree.
npx @cobusgreyling/loop-worktree create --run-id issue-123-attempt-1 --pattern issue-triage

# Before a retry, check the ledger for repeated failures or budget limits.
npx @cobusgreyling/loop-context --check --ledger loop-ledger.json

These commands are not a deployment recipe. The tool, pattern, credentials, scheduling mechanism, and verification commands must be adapted to the project. The right first loop may have no code-changing capability at all. The most valuable outcome in the first week is often a reliable report that tells the team what should not be automated yet.

A minimal LOOP.md should answer these questions in plain language:

• What single outcome does this loop pursue, and what does it explicitly not do?
• Which repositories, branches, files, issues, and connector operations are in scope?
• Which commands or evaluators establish success, and who owns them?
• What durable state is read first and written last?
• What are the max turns, attempts, cost, cadence, and notification rules?
• Which paths, actions, or signals require immediate human escalation?
• How does a person pause the loop, revert its work, and inspect its trace?

If the answers are vague, the loop is not ready for more autonomy. That is not a limitation of the model; it is a sign that the human system has not yet made its own operating assumptions explicit.

14. Final principles

Loop engineering reframes AI coding from a prompt-writing exercise into systems design. The model remains important, but it is one component inside a larger control system. The highest-leverage improvements are frequently mundane: a better test command, a smaller scope, a preserved run ledger, a fresh reviewer, a worktree, a denylist, a budget cap, or an escalation that reaches the right person.

Build loops that can explain what they are doing, show the evidence for their last decision, respect a boundary when they meet one, and leave the codebase easier—not harder—for the next engineer to understand. Start where the evidence is strongest. Promote autonomy slowly. And never confuse activity, token spend, or a confident final message with engineering success.

Further reading and primary sources

• Loop Engineering repository, quickstart, failure catalog, and safety guidance.
• Anthropic: How the agent loop works, Claude Code best practices, Building effective agents, Effective harnesses for long-running agents, and Demystifying evals for AI agents.
• Research: ReAct, Reflexion, Self-Refine, SWE-bench, SWE-agent, Agentless, Terminal-Bench, and OSWorld.
• Governance and security: NIST AI 600-1, OWASP Top 10 for LLM applications, SLSA, and A practical guide to building agents.