Two ideas are converging in how people build with AI agents right now, and it’s worth slowing down to look at how they fit together.
The first is loop engineering — a phrase that took off after mentions by Boris Cherny (Claude Code’s creator) and Peter Steinberger (OpenClaw’s creator) went viral. The second is agent self-improvement — the idea that an agent should get better from use, not just complete the task in front of it.
These are usually discussed separately. But they’re not two different topics. Self-improvement is what loop engineering becomes when you take it one level up. This post is a field note on why.
What loop engineering actually is
The core insight of loop engineering is that you don’t get real work out of an agent by prompting it once. You get it by putting the agent inside a loop: it acts, it checks its own work against a goal, and it iterates until the work meets the goal.
That last part — checking against a goal — is the whole game. A loop without a way to measure “am I there yet?” is just repetition. A loop with one is a search that converges. Give an agent a specification and, ideally, a set of evals, and it can write code, run the tests, read the browser or the logs, notice it’s wrong, and try again — for an hour at a stretch, without you.
A useful way to see the landscape is that there isn’t one loop, there are several, nested and running at different speeds:
- The agentic coding loop runs in minutes. Act, test, read the result, fix, repeat — until the code meets the spec.
- The developer feedback loop runs in tens of minutes to hours. A human looks at what got built and steers it: what to build, where the UI is wrong, how the flow should feel.
- The external feedback loop runs in hours to weeks. Real users, alpha testers, A/B tests. This reshapes the vision, which reshapes the spec, which drives the coding loop.
Loop engineering, as a craft, is the work of designing these loops well: picking the goal, wiring up the signal that tells the agent whether it’s meeting the goal, and setting how long each loop should run before it hands off. When people say they’re “finding new ways to engineer more effective loops,” this is what they’re tuning.
The thing every loop has in common — and the thing they all forget
Notice what all three loops share. Each one is a converging process: a goal, a signal, and iteration until the two line up. That’s a genuinely powerful pattern, and it’s why agents can now work productively for long stretches.
But notice what happens after a loop converges.
The coding loop lands on green, and the task is done. The next task begins — and the agent starts from zero. It rediscovers that this repo’s tests hang without a non-watch flag. It re-learns that “done” here means running the integration check. It re-encounters the exact quirk a user explained yesterday.
Every loop generates a rich stream of signal along the way: the corrections, the dead ends, the path that finally worked. And when the loop closes, that signal evaporates. The loop converges on the output. It changes nothing about the agent that produced it.
This is the ceiling of loop engineering on its own. You can make each loop tighter and faster, but a loop that converges and then forgets will reclimb the same hill every time.
Self-improvement is a loop over loops
Here’s the shift. Ask a different question about the loops:
Loop engineering asks: how do I make this loop converge on the goal?
Self-improvement asks: how do I make the next loop start closer to the goal than this one did?
The second question is answered by wrapping another loop around the first. The inner loop iterates on the task. The outer loop iterates on the agent — watching many runs of the inner loop, extracting what actually changed behavior, and folding it back in so the next run begins further ahead.
That’s the whole idea in one line: self-improvement is a loop over loops. Same machinery — a goal, a signal, iteration — but the thing being optimized is no longer the output. It’s the policy that produces outputs.
This is why self-improvement is best understood as the next stage of loop engineering, not a separate discipline. Loop engineering got us agents that converge within a task. The natural next move — the one you reach for the moment you’ve run the same kind of task fifty times — is to stop letting each convergence go to waste.
Concretely, the outer loop does four things:
- Learn — from a single run, extract a durable, procedural lesson. Not “the test failed,” but “for code fixes, verify before claiming done; prefer a targeted test or the runtime log depending on the failure.”
- Generalize — when the same lesson shows up across many runs and many users, promote it from a one-off into a shared behavior.
- Reflect — check whether a learning still helps when it’s applied. Learnings decay; the outer loop retires the ones that stop earning their place.
- Optimize — across many similar runs, find the better procedure for a whole class of tasks, not just an isolated fix.
We’ve written about this framework in more depth as LGRO — Learn, Generalize, Reflect, Optimize. The point for this post is narrower: each of those four is itself a loop, and together they’re the loop that sits above the loops loop engineering already gave you.
Why the connection runs through the human
There’s one loop in the stack that resists automation, and it’s the most revealing one: the developer feedback loop. It resists because the human knows things the agent does not — the users, the domain, the environment the product lives in. Call it a context advantage.
Watch what happens each time a human uses that advantage to steer the agent — “run the test before you say it works,” “this customer never wants confirmation prompts,” “a migration isn’t safe until integration checks pass.” In pure loop engineering, that correction is ephemeral. It steers this run and vanishes. The human pays the same context tax again on the next task.
Self-improvement is precisely the mechanism that makes the transfer stick. The outer loop captures that correction as a scoped, reusable lesson — so the thing a human taught once keeps applying without them teaching it again. The human stays in the loop (the context advantage is real and won’t vanish soon), but every pass through it now narrows the gap instead of resetting it.
That is the difference between an agent you steer and an agent that learns from being steered — and it’s the clearest place to see loop engineering and self-improvement as one continuous idea.
Not everything should compound the same way
One caution, because “make it a loop over loops” is easy to over-apply. The loops run at different speeds for a reason, and their lessons deserve different treatment:
- A fast coding-loop fact (“this repo’s test command needs
--no-watch”) is high-confidence and narrow — capture it, apply it locally. - A developer-loop preference (“this user likes end-to-end autonomy”) is real but conditional — it may reverse as the agent grows more capable, so it needs reflection, not permanence.
- An external-loop signal (an A/B result, a wave of similar feedback) is where careful generalization belongs — one correction becoming a shared behavior, without leaking across users or customers.
The failure mode of a naive outer loop is turning a throwaway workaround into a permanent global rule. That’s why self-improvement needs structure — scope, provenance, confidence, and evaluation — rather than a growing pile of remembered text. Reflection is what keeps a compounding loop from compounding the wrong things.
Where this is heading
This is the layer we work on at Reflexio: the outer loop that makes agents improve non-parametrically — by evolving the skills, playbooks, and context around a fixed model, so every learned behavior stays inspectable, scoped, and reversible. In teams running agents across many users, that outer loop is also where the hard boundaries live — one customer’s lesson generalizing to their organization, but never bleeding into another’s. In our internal evaluations, closing this loop reduced agent planning iterations by more than 80% on GDPVal-style knowledge-work tasks. But the framing matters more than any one product: self-improvement is what you get when you point loop engineering at itself.
So the takeaway is simple.
Loop engineering was the breakthrough that let agents iterate toward a goal without us watching. It works because a loop with a goal converges.
The next stage is a loop with a longer memory — one wrapped around the others, turning each convergence into a starting point instead of an ending. Not just iterating toward the goal, but compounding toward it.
If you’re engineering loops today, the most interesting question is no longer how tight can this loop get? It’s what loop should sit above it?
You can check out Reflexio on GitHub and try our open-source coding-agent plugin, claude-smart. If you’re thinking about the loop over your loops, we’d love to compare notes.