Loop Engineering: Why AI Agents Need More Than One Loop

Every agent that uses tools has a loop inside it. Call the model, look at the result, run the tools, feed observations back, repeat until done. That's the agent loop — and for most demos, it's all you need.

But the moment your agent leaves a notebook and starts touching real systems, the single loop starts to break. The model says it's done, but it isn't. It writes code that doesn't compile. It calls an API and ignores the error. It summarizes a document and misses the most important section. The loop ran, but it ran without quality control.

That's where loop engineering comes in. LangChain's 2026 framing — laid out in "The Art of Loop Engineering" by Sydney Runkle — describes this as a stack of loops, not one magic while-statement. Each layer adds a different kind of feedback and quality control. The stack has four levels, and each one solves a specific failure mode.

The Four-Loop Stack

Loop 1: The Agent Loop. This is the baseline — model calls tools until it returns a final answer. It's what every agent framework gives you out of the box. It automates work, but it has no quality control. The agent decides when it's done, and agents are terrible judges of their own work.

Loop 2: The Verification Loop. This is where it gets interesting. After the agent produces output, a separate evaluation step checks it against a rubric. Does the code pass tests? Do the links resolve? Does the summary contain the key facts? If verification fails, the agent gets specific feedback and tries again.

The critical design principle here: loop on evidence, not confidence. "The agent says it is done" is not a stopping condition. "The tests pass, the schema validates, and the reviewer approves" is. Anthropic calls this the evaluator-optimizer pattern — generate, critique, revise, repeat. The loop converts a one-shot instruction into a managed process with measurable quality gates.

Loop 3: The Event-Driven Loop. Instead of waiting for a user prompt, the agent wakes up when something happens. A cron schedule fires. A webhook arrives. A new file lands in a watched directory. A Slack message mentions it. This is how agents go from reactive tools to autonomous workers that operate on their own schedule. CopperRiver uses this exact pattern — cron jobs trigger agent runs that browse, process, and report without human intervention.

Loop 4: The Hill-Climbing Loop. This is the most advanced layer, and it's where loop engineering starts to feel like magic. An outer agent analyzes execution traces from the inner loops, identifies failure patterns, and rewrites the harness configuration to fix them. It might adjust the system prompt, restructure the tool definitions, or change the verification criteria. Each cycle of the outer loop makes the inner loops more effective.

LangChain describes this beautifully: "The return arrow doesn't just loop back to the top — it reaches inside and updates the agent loop directly." It's a self-improving system. The agent isn't just getting better at the task through repetition — the infrastructure around the agent is getting better at enabling it.

Why Loop Engineering Is Not Prompt Engineering

This distinction trips people up constantly. A prompt tells the model what to do during a call. A loop specifies what the system does after the call: how it observes results, chooses feedback, decides whether to continue, persists progress, and terminates.

You can have the best prompt in the world and still fail if your loop is broken. A prompt that says "write correct code" doesn't help if the loop has no test runner to verify correctness. A prompt that says "be concise" doesn't help if the loop has no length check. The prompt is the instruction; the loop is the enforcement.

The tradeoff is cost and latency. Each verification step, each retry, each grader adds another model call or tool execution. Anthropic's guidance is pragmatic: add complexity only when the failure cost is higher than the verification cost. For a casual chatbot, a single loop is fine. For an agent writing production code or processing financial documents, the verification loop pays for itself many times over.

The Anatomy of a Well-Engineered Loop

LangChain and practitioners have converged on a common anatomy for production loops. Every loop needs six components:

Trigger — what starts a cycle. A user request, a schedule, a failed test, new data, or evaluator feedback. Without a clear trigger, the loop either never fires or fires randomly.

Goal — a specific state to reach, not a vague instruction to "keep improving." "All tests pass" is a goal. "Make it better" is not.

State and memory — what the next cycle needs to know without replaying everything. The agent should pick up where it left off, not start from scratch each iteration.

Action policy — what the agent may change, call, delegate, or spend during this cycle. Without boundaries, the loop becomes a cost leak.

Evidence — tests, schema validation, citations, diffs, metrics, or human review. This is the objective signal that determines success or failure. No evidence means no quality control.

Stopping rule — success, budget limit, timeout, irrecoverable error, or human escalation. An unbounded retry loop is not engineering — it's a credit card fire.

The Expensive Mistakes

Infinite reflection cycles. The agent critiques its work, revises, critiques again, revises again, and never converges. Each iteration costs tokens without making progress. The fix: a hard iteration cap (20 is reasonable) and a score threshold that forces termination.

Self-grading without safeguards. Letting the same model write and evaluate its own output creates a shared blind spot. The model makes an error, then fails to catch the error because the error exists in both the output and the evaluation. Prefer deterministic checks (tests, schema validators, linters) where possible. When you must use an LLM grader, use a separate model or at least a separate context.

"Keep trying" as a specification. This is the most common loop anti-pattern. Someone builds an agent, it fails, and they add a retry loop that says "try again." No feedback. No evidence. No maximum attempts. The agent will retry the exact same approach, fail the exact same way, and burn your budget. Every retry needs fresh evidence and specific feedback about what went wrong.

No escalation path. When the loop exhausts its budget, what happens? If the answer is "nothing," you have a silent failure. Every loop needs a named escalation — notify a human, file a ticket, log the failure with context, or fall back to a simpler approach.

The Real-World Example

LangChain's own documentation agent demonstrates all four loops in production. Loop 1: the agent clones a repo, reads files, writes documentation, and opens a PR. Loop 2: a grader checks that all links resolve, CI passes, and the diff is scoped correctly. Loop 3: a Slack channel triggers the agent whenever someone requests docs for a specific module. Loop 4: a separate engine analyzes traces from completed runs, identifies patterns (the agent consistently misses certain doc types), and files issues to improve the prompt and tools.

The result is a system that doesn't just automate documentation — it improves at documentation over time. And the improvement happens at the infrastructure layer, not through retraining the model.

This is what loop engineering actually delivers. Not a smarter model, but a smarter system around the model. The model stays the same. The loops make it reliable.

---

CopperRiver ships with built-in loop engineering — scheduled triggers (cron), evidence-based verification, memory that persists across runs, and budget controls. All running on open-source models locally. Plans from $9/mo. Check it out.