What Loop Engineering Is
For a while, an AI coding agent got one shot. It read the request, produced a diff, and stopped. If the diff failed a test, a human had to notice and prompt again. Loop engineering removes that ceiling. The agent runs a cycle: plan the change, execute it, evaluate the result against some signal, revise based on what it learned, and repeat until a stop condition — tests green, a target met, or a maximum number of iterations reached.
Anthropic’s engineering guide describes this shape directly: agents are “typically just LLMs using tools based on environmental feedback in a loop,” and it is common to include stopping conditions such as a maximum number of iterations. See Building Effective Agents for the evaluator-optimizer pattern, where one call generates a change and another evaluates it, feeding correction back in until the result clears the bar. That feedback loop is what turns a one-shot generator into something that can carry a task to completion on its own.
Why Loops Are Valuable
The benefits are real and worth stating plainly, because the argument here is not that loops are a distraction:
- Automatic retries. A failed test no longer stalls the workflow. The agent reads the failure and tries again without a human in the middle.
- Self-correction. The agent inspects its own output against ground truth — a compiler error, a failing assertion, a type check — and repairs it before anyone sees the broken version.
- Less human intervention. Tasks that used to need a prompt at every step run end to end. The person supervising checks the result, not each keystroke.
- Longer autonomous workflows. Multi-file changes that would have exhausted a single pass now complete, because the loop can spend as many iterations as the problem needs.
These are genuine gains, and every serious coding stack will adopt some form of them. That is exactly why loop quality alone does not tell you whether the software an agent produces is sound — and why the interesting question is what the loop is actually optimizing.
The Missing Layer: A Worked Example
An agent is asked to add a notification service. It plans an event-driven design and reaches for Kafka, because Kafka is a reasonable default and appears constantly in its training data. It wires up a producer, writes the tests, and runs them. The tests fail — a serialization mismatch. The loop kicks in. The agent tweaks the config, retries. Another failure, a missing topic. It adjusts, retries. On the fourth iteration the tests pass. The stop condition is met. The agent reports success.
Every part of that loop worked. The retries were correct. The self-correction was real. The final code is clean and tested. And it is wrong for this system, because the project’s ADR says RabbitMQ is the approved messaging platform — already provisioned, already monitored, already the pattern every other service follows. The loop iterated four times and never once asked whether Kafka was allowed here. It could not ask. The evaluation signal it optimized against was “do the tests pass,” and a Kafka integration passes its own tests perfectly.
The loop improved the implementation. It never questioned the architectural decision. Twenty iterations converging on a well-tested Kafka service is still twenty iterations spent building the wrong thing, because the constraint that mattered — use RabbitMQ — was never expressed anywhere the loop could evaluate against it.
This is the same gap that lets architectural drift accumulate under any autonomous agent: a locally correct result that is globally inconsistent. A green test suite confirms the code does what the code says. It says nothing about whether the code should exist in this form at all. That question lives in the recorded decisions, and the loop has no line of sight to them.
Loops Optimize Execution, Not Intent
The cleanest way to see the split is to put the two next to each other. A loop is an execution engine, tuned to converge on a passing result. Architectural guardrails are a decision layer, tuned to preserve what the system already committed to. They answer different questions:
| Loop engineering | Architectural guardrails |
|---|---|
| Retries a failing change | Enforces the architectural decisions |
| Evaluates against a test signal | Evaluates against architectural intent |
| Converges on a passing result | Holds the line on engineering standards |
| Completes the task | Preserves system consistency |
Both columns are necessary. A loop with no guardrails is a fast, tireless way to build something that passes and still breaks the architecture. Guardrails with no loop are rules no agent can act on. The point is that the loop’s own evaluation function will never contain the architectural decision, because that decision is not in the tests, the diff, or the environment feedback. It lives in the ADRs, the standards, and the conventions — and it only becomes enforceable when it is expressed as executable architectural intent rather than prose in a wiki. This is why context alone does not prevent drift: even an agent that has read the ADR can loop right past it if nothing checks the output against it.
Deeper Loops Make the Gap Wider
Loop engineering is not standing still. Loops are getting deeper, and single agents are giving way to recursive ones — an agent that spawns sub-agents, each running its own plan-execute-evaluate cycle on a slice of the work. Every one of those sub-loops optimizes its local objective. That is what makes them effective. It is also what makes them drift.
A local optimization is, by construction, blind to system-wide intent. One sub-agent picks the convenient library. Another reaches around a service boundary because it is the shortest path to a passing test. Each is locally optimal and collectively inconsistent. As the loops multiply, so do the surfaces where a reasonable local choice diverges from a project-wide decision — the mechanism behind multi-agent architectural drift. The deeper the recursion, the more the architectural memory has to live outside any individual loop, because no single loop can hold the whole system’s intent in view. Durable, machine-checkable decisions become the only thing keeping a swarm of well-run loops pointed the same way.
Why This Matters: Better Loops, Inside Guardrails
None of this is an argument against loop engineering. It is an argument for pairing it with a layer it structurally cannot supply. The goal is not fewer iterations. It is better loops operating within architectural guardrails — so that every retry, every self-correction, every autonomous stretch is spent converging on an implementation that is also allowed to exist.
That is where Mneme sits. It records each architectural decision as structured data with its constraints, retrieves the ones relevant to the change the agent is making, and checks the proposed edit against them deterministically — the same verdict every time, independent of which model ran the loop. A violation is rejected before the change lands, and the violated decision is returned to the agent, so the next iteration of the loop can converge on a compliant answer instead of a merely passing one. The loop keeps doing what it is good at. The architecture stops being optional. If you want to see that on your own ADRs, the demo walks through it end to end.