Most AI agents in production today are glorified function calls. They take an input, run inference, produce an output, and forget everything the moment the response streams back. Ship one on Monday, and it's exactly as smart on Friday six weeks later as it was on day one — same edge cases, same wrong answers, same manual overrides eating the ROI you promised leadership.
There's a term circulating in the agent-building community for the architectural fix to this: loop engineering. It's not a new model, a framework you pip install
, or a prompt technique. It's a way of thinking about the difference between a system that answers and a system that compounds.
If you're running agents in production and they've stalled, this is almost certainly why.
Picture a claims-triage agent at a mid-sized insurance company. It reads incoming claims, classifies them, pulls the relevant policy, and drafts a recommendation for a human adjuster.
Launch day: 60% of routine claims handled without escalation. Leadership is thrilled.
Six weeks later: still 60%. The same ambiguous policy clauses get misread the same way, every Monday. Adjusters start double-checking everything, and the time savings evaporate.
The diagnosis isn't the model. It's the architecture. This is an open-loop system:
Input → Process → Output → (stop)
Nothing flows back. The agent has no way to notice it was wrong, no way to learn from the adjuster's correction, no memory of last week's mistake. It's a very expensive function call.
A closed-loop system looks like this instead:
Input → Process → Output → Feedback → Improve → (back to Input)
That second arrow — the one that bends back to the start — is the entire game. But it isn't magic. People talk about self-improving agents as if you sprinkle a feedback step on top and intelligence emerges. It doesn't work that way. The loop is held together by six real architectural decisions, each with real trade-offs.
flowchart LR
A[Automations<br/>trigger layer] --> B[Worktrees<br/>parallel execution]
B --> C[Skills<br/>procedural memory]
C --> D[Connectors<br/>real-world links]
D --> E[Sub-agents<br/>validation layer]
E --> F[Memory<br/>state layer]
F -.feedback.-> A
A self-improving system needs to start without you. Automations initiate workflows based on time, events, or system conditions — an email arrives, a database row updates, a claim lands in the queue.
This is the shift from "I asked it" to "it noticed and started on its own." An agent you have to invoke is a tool. An agent that responds to the world is a system.
The catch: triggers are where runaway loops are born. An event-driven agent that triggers another event can cascade. Before wiring automations, define the kill switch and the rate limit first. A loop that starts itself must also be a loop you can stop.
Once work starts itself, you hit a throughput wall. One agent processing one task at a time doesn't scale to enterprise volume.
The name borrows from git's worktree concept — the same one coding agents already use — where multiple branches exist side by side without stepping on each other. Applied to agents, it means multiple instances execute independently across isolated branches, with three properties that matter:
This is where the loop starts to feel intelligent. Skills are reusable units of logic — the "how to do this" an agent shouldn't have to rediscover on every run. A skill is:
The payoff: you stop stuffing every instruction into the prompt and instead give the agent a library of capabilities it composes on demand. Prompts get shorter, behavior gets more reliable, and the system gets cheaper to maintain.
An agent reasoning in isolation is a chatbot. An agent that touches real systems is infrastructure. Connectors are the links out:
The Model Context Protocol (MCP) has become the common standard here precisely because it bakes identity and policy into the connection instead of bolting it on afterward.
This is the layer separating teams that ship reliable agents from teams that ship confident hallucinations. The pattern: separate the builder from the judge.
Generator → produces output
↓
Validator → checks against rules, policy, known failure modes
↓
Approval gate → only validated output moves forward
↓
Feedback loop → flagged issues route back for another pass
One agent generates the claim recommendation. A separate agent — different prompt, different job — checks it against policy constraints, regulatory rules, and known failure cases. Pass, and it ships. Fail, and it goes back with a specific reason.
Why two agents instead of one checking its own work? Because a model grading its own output shares the same blind spots that produced the error in the first place. Multiple eyes — even both models — catch more. This is the operational version of "your evals are your moat": the validator sub-agent is where your eval logic lives at runtime, not just in a test suite. Continuous validation is what turns a 60% agent into a 90% agent without touching the underlying model.
The final layer is what makes the loop a loop instead of a circle that resets to zero. Memory preserves state across passes:
Here's the precise mechanism worth sitting with: the loop does not make the model smarter. The model weights never change. What changes is the context the system carries into each pass. Memory is the substrate that lets feedback from layer five accumulate instead of evaporate. Each pass leaves something behind for the next one to use — that's the whole trick.
Put all six on the loop and you see how they hand off:
Automations start it. Worktrees parallelize it. Skills and connectors do the work. Sub-agents validate it. Memory carries the lesson forward to the next pass.
When reviewing an agent architecture, don't start by asking which model was chosen. Ask one question first: where does the loop close?
If the answer is "it doesn't," that's the entire diagnosis — and no amount of prompt tuning fixes a missing feedback layer. For most teams, the fix isn't a better model. It's three of the six layers they skipped. Add a connector to read the adjuster's accept-or-override signal, a validator sub-agent that enforces policy constraints before drafting, and a memory layer that stores every override as a new case. Within a month, the agent moves off its plateau — because for the first time, it can actually learn from the humans correcting it.
As loops improve and grow more autonomous, there's a real cost that gets ignored: humans stop understanding the underlying mechanics. As the human-in-the-loop gets eliminated, teams accumulate comprehension debt — a widening gap between what the system does and what anyone actually understands about how it does it. Left unchecked, that becomes cognitive surrender: trusting these systems so completely that nobody's tracking what's happening at all.
Staying the engineer — keeping a working mental model of the system even as it improves without you — is the part of loop engineering that doesn't show up in the architecture diagram but matters just as much.
If your agent has stalled at some mediocre-but-tolerable accuracy for weeks, the fix probably isn't a bigger model or a cleverer prompt — it's a missing layer in the loop. Which of the six are you actually missing: the trigger, the parallelism, the skill, the connector, the validator, or the memory? And if you've closed all six, what's stopping your team from understanding the system it built?