Loop Engineering
for agentic AI coding

What "loop engineering" means in agentic coding

A single LLM call is a function: prompt in, text out. It cannot recover from its own mistakes because it never sees them. An agent is what you get when you wrap that call in a while-loop with tools and feedback:

Those four lines hide all the engineering. Loop engineering is the deliberate design of each line:

• gather( ) — context engineering: what enters the window, what gets summarized, what gets retrieved on demand instead of preloaded.
• model( ) — the only part you mostly don't control. Prompts and tool definitions are your steering inputs.
• execute( ) — tool design: legible outputs, loud failures, sandboxed side effects.
• verify( ) + stop — the part most people under-build, and the part this guide is mostly about. An agent without a real verifier isn't iterating; it's free-associating with side effects.

Anatomy of the agent loop

Here is the loop you actually ship, including the two places where the real world injects trouble: hallucination entering at the model (a confident wrong claim, an API that doesn't exist) and environment noise entering at the verifier (flaky tests, dirty workspace, rate-limited services).

The vocabulary, in plain words

You've seen this loop before

If you come from control engineering, none of this is new — only the names changed. An agentic coding loop is a feedback control system where the controller happens to be a language model and the plant happens to be a codebase:

Lab A — The verifier is your loop gain

A Monte-Carlo toy model of one edit-verify loop, 4,000 simulated runs per slider move. Each iteration the agent attempts a fix that truly works with probability p (model capability). The verifier catches a broken attempt with probability v (test coverage / verifier strength). Context rot decays p a little every iteration. Three ways a run can end:

• True success — fix works and the verifier confirms it.
• False success — fix is broken but slipped past the verifier. The worst outcome: it looks identical to success until production.
• Budget exhausted — the stop gate fired. Annoying, but honest.

What the model teaches

• Weak verifiers don't make agents fail — they make agents lie. Drop v from 0.95 to 0.45 with a strong model: the loop "finishes faster," and a huge red mass of broken-but-accepted code appears. Iterations went down; risk went up.
• Verifier strength converts failure into retries. With v ≈ 1, the only bad outcome left is "exhausted," which is recoverable: raise the budget or improve context.
• Context rot punishes long loops. At high rot, late iterations are nearly worthless — which is the quantitative argument for compaction, fresh-start retries, and splitting work into subtasks rather than raising N.
• Flaky tests tax the honest path. Toggle flakiness: true successes get rejected, runs lengthen, exhaustion grows. Determinism in the verifier is a performance feature, not hygiene.
• A writable verifier is no verifier. Enable "agent may edit tests": every caught failure now has a 20% chance of becoming a green-but-broken ship, because the optimizer was allowed to optimize the metric itself. Watch true success barely move while false success explodes — Goodhart's law, rendered as a bar chart.

Feedback quality — making the loop see

The model only knows what the loop shows it. Feedback has three qualities, and you should engineer each deliberately:

• Coverage — how much of "wrong" the verifier can detect. Layer cheap, broad signals first: compiler/type-checker (free, instant, near-total coverage of one error class) → linter → unit tests → integration tests → visual diff/screenshot → human rubric. Each layer catches what the previous one can't see.
• Latency — iterations per budget is your loop bandwidth. A 90-second test suite means an agent gets ~6 meaningful turns in 10 minutes; a 3-second targeted run gives it ~60. Give the agent a way to run just the relevant tests and you've multiplied its effective intelligence by 10.
• Legibility — error output is a prompt. AssertionError alone is a terrible prompt; "expected 3.14 got 2.71 at resolver.py:88 in wrap_angle()" is a great one. Truncate the irrelevant, keep the failing assertion, the locals, and the file:line. Tools that fail should fail loudly, specifically, and with a suggestion.

Lab B — Anatomy of a real run

Below is a replay of a realistic agent trajectory: fixing two failing tests in a resolver angle-decoding module. Press play and watch four things at once: the event log (what the model and tools do), the context meter (the window filling with tool results until compaction reclaims it), the iteration counter (each verify-fail closes one loop), and the moment the stop gate finally opens.

What to notice in the replay

• Reading before writing. The agent's first three actions gather ground truth — failing output, the test file, the source. Grounding is cheap insurance against hallucinated APIs.
• One hypothesis per iteration. Each loop changes one thing and re-verifies. When iteration 1 only half-works (2 failures → 1), that partial signal is exactly what steers iteration 2.
• The context meter mostly fills with tool results, not reasoning. Raw pytest output and file dumps dominate. That's why compaction summarizes results, and why tools should return the minimum that's still legible.
• The run ends because a gate said so — tests green AND lint clean — not because the model felt finished. "Feels done" is not a stop condition.

A failure-mode bestiary (DTCs for agents)

Vehicle diagnostics has trouble codes; agent loops deserve the same. Every fault below is observable from the trajectory log alone — which is the point. You debug a loop by reading its trajectory, the way you debug a drive by reading its signals, not by re-prompting harder and hoping.

Loops inside loops

Mature agentic systems are cascades, exactly like servo drives: a fast inner loop wrapped by slower outer loops, each with its own verifier and its own stop condition.

• The separation rule transfers intact: each inner loop should be ~an order of magnitude faster than the loop around it. If your "inner" test cycle takes as long as a human review cycle, the cascade collapses into one slow, unsteerable loop.
• Inner loops protect outer ones. The inner loop's caps (iterations, diff size, no force-push) mean the outer loop can delegate aggressively without existential risk — the same reason current limits live in a drive's innermost loop.
• Escalation is the cascade's anti-windup. When an inner loop hits its cap, the right move is up, not harder: report what was tried, surface the blocker, let the middle loop re-plan or the human re-spec. Agents that never escalate are agents that thrash.

Loop topologies & workflow patterns

Anthropic's "Building Effective Agents" catalogues the standard topologies. They are all arrangements of the same gather→act→verify cell:

Lab C — Best-of-N and the judge problem

The parallelization pattern promises: sample N independent attempts, have a judge pick the best, ship it. It works exactly as well as the judge. The model below makes that precise: each of N candidates is truly correct with probability p; the judge approves a correct candidate with probability j and wrongly approves a broken one with probability 1−j; one randomly chosen approved candidate ships; if nothing is approved, the run escalates honestly.

What the model teaches

• With a perfect judge, fan-out is pure win. Broken shipments stay at zero and correctness climbs toward 1 − (1−p)^N. You pay only compute — which is why "generate N, run the tests on each, ship the green one" is such a strong pattern.
• With a weak judge, fan-out manufactures plausible wrong answers. Drop j to 0.55 and raise N: the red curve climbs nearly as fast as the green one. You bought more lottery tickets for a judge who can't read the numbers.
• The judge is just another verifier. Everything from Lab A applies: execution beats opinion, determinism beats vibes, and an LLM grading LLM output inherits the generator's blind spots (bestiary L-10).
• Returns diminish fast. Most of the achievable gain arrives by N ≈ 5–8; beyond that you're spending linearly for asymptotic crumbs. Spend the surplus on a better judge instead.

Security — the loop as attack surface

Everything that enters the context window can steer the model, and an agent's tools pour the outside world into that window all day: web pages, issue comments, commit messages, log lines, the README of a dependency. Prompt injection is what happens when that content contains instructions — and the model, which cannot reliably tell data from directives, follows them. The attacker never touches your prompt; they publish a web page and wait for your agent to read it.

Engineering the loop to fail safe

• Least privilege per task. Mount only the tools this task needs. A bug-fix loop needs read/edit/test — it does not need email, cloud credentials, or unrestricted HTTP.
• Egress allowlists. Network access limited to known package registries and APIs turns most exfiltration payloads into harmless text. (The sandbox this page was built in works exactly this way.)
• Sandbox execution, no ambient secrets. Run in a container without production credentials in the environment; secrets the loop can't see are secrets it can't leak.
• Gate by reversibility, not confidence. Local edits: autonomous. Pushes, deletions, migrations, outbound messages: human approval. The model's confidence is not an input to this decision — injected models are confident too.
• Quarantine untrusted content. The dual-loop pattern: a sandboxed reader loop with no privileges summarizes the untrusted page/issue; the privileged loop only ever sees the summary, never the raw payload.
• Treat MCP servers as dependencies. They execute inside your trust boundary: pin versions, review what they mount, prefer audited registries — a malicious tool description is a prompt injection with a handshake.
• Keep forensics. Full trajectory logs of tool calls and arguments are your flight recorder; injection incidents are diagnosed from trajectories, like everything else in this guide.
• Eval with canaries. Plant injection payloads in your replay suite (a booby-trapped README, a malicious issue) and assert the loop ignores them. Security regressions are regressions; test them like any other.

Practical notes from the trenches

• Write the stop condition before the prompt. "Done = pytest -q green + ruff clean + diff under N lines + no new deps." If you can't express done as a command exit code plus a checklist, the task isn't ready for an agent.
• Cap everything: iterations, tokens, wall-clock, diff size, files touched. Caps are anti-windup; hitting one is information, not failure.
• Make the workspace disposable. Run in a branch, a worktree, or a container; commit checkpoints every green state. Cheap rollback is what makes bold iteration safe — git is the agent's undo button and your sleep aid.
• Sandbox by default, gate the irreversible. Reads and local edits can be autonomous; git push, migrations, deletions, anything touching prod goes through a human gate. Sort actions by reversibility, not by how confident the model sounds.
• One concern per iteration. Encourage small diffs and a single hypothesis per turn. Giant multi-file edits are delay in the loop: by the time feedback arrives, you can't attribute the failure.
• Give the agent a fast lane. A make check-fast that runs the focused tests in seconds, with the full suite reserved for the stop gate. Loop bandwidth is test latency.
• Treat tool output as prompt engineering. Trim noise, keep file:line, surface the actual assertion. Return errors the way you'd want a junior engineer to report them.
• Persist memory outside the window. A CLAUDE.md / AGENTS.md with build commands, conventions, and known traps is the loop's long-term memory; a scratchpad / todo file survives compaction and keeps long runs on-plan.
• Compact on results, restart on confusion. Summarize old tool outputs aggressively; but when a loop is visibly thrashing (same two edits alternating), a fresh context with a better-written task beats iteration 14 of a rotten one.
• Fight reward hacking at the verifier. Agents will sometimes "fix" a failing test by deleting or weakening it. Protect the spec: make test files read-only to the agent where possible, or diff-check that assertions weren't loosened. The metric you verify is the metric the loop will optimize — exactly Goodhart's law.
• Eval the loop, not just the model. Keep a small suite of past real tasks and replay them when you change prompts, tools, or models. Loop changes regress silently; trajectories don't lie.
• Log trajectories. r, y, u, e for agents = task, diff, tool calls, verifier output. Most "the agent is dumb" reports dissolve when you read the trajectory and find a tool that lied or a test that flaked.

A loop engineering checklist

References & further reading

1. Anthropic, Building Effective Agents, Dec 2024 — the workflow-pattern taxonomy of §08 and the "start simple" doctrine. anthropic.com/research/building-effective-agents
2. Anthropic, Claude Code: Best Practices for Agentic Coding, 2025 — CLAUDE.md memory files, targeted test commands, plan-then-execute, git checkpointing. anthropic.com/engineering
3. Anthropic, Writing Effective Tools for AI Agents and Effective Context Engineering for AI Agents, 2025 — tool legibility, token-efficient results, compaction, and just-in-time context retrieval. anthropic.com/engineering
4. S. Yao et al., "ReAct: Synergizing Reasoning and Acting in Language Models," ICLR 2023 — the canonical interleaved think/act/observe loop. arXiv:2210.03629
5. N. Shinn et al., "Reflexion: Language Agents with Verbal Reinforcement Learning," NeurIPS 2023 — feeding verbal self-critique back as loop feedback. arXiv:2303.11366
6. C. Jimenez et al., "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?" ICLR 2024 — the benchmark that made test-verified agent loops the standard of evidence. arXiv:2310.06770
7. J. Yang et al., "SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering," NeurIPS 2024 — evidence that interface/tool design (the loop, not the model) drives large performance gains. arXiv:2405.15793
8. Model Context Protocol specification — the standard plumbing for the tool layer of Fig. 1. modelcontextprotocol.io
9. B. Brown et al., "Large Language Monkeys: Scaling Inference Compute with Repeated Sampling," 2024 — the empirical case behind Lab C: coverage grows with samples, but only verifiable domains can cash it in. arXiv:2407.21787
10. K. Greshake et al., "Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection," 2023 — the paper that named the attack of §11. arXiv:2302.12173
11. S. Willison, "The Lethal Trifecta for AI Agents," 2025 — the three-legged exfiltration checklist. simonwillison.net
12. OWASP, Top 10 for LLM Applications, 2025 — LLM01 (prompt injection) and friends, as a reviewable checklist for agent deployments. genai.owasp.org
13. K. J. Åström & R. M. Murray, Feedback Systems, 2nd ed., Princeton, 2021 — for the §03 mapping; sixty years of loop theory your agent harness quietly re-derives. fbswiki.org