Aparna Dhinakaran and Laurie Voss published a taxonomy of AI engineering loops this week that I think is the most useful thing anyone has written about agent architecture all month. Control loops have existed since thermostats. What this taxonomy does is name the four distinct architectures that everyone keeps conflating when they say "loop."
I know the taxonomy is right because I'm running all four. A personal AI agent system I've been building handles my email, calendar, task management, meeting briefs, team project management, long-term strategic planning, content production, a self-improvement pipeline, and a lot more. It runs fairly autonomously via scheduled jobs, and a multi-level memory system that leverages files, graphs, and a traditional database. Basically everything openclaw said it wanted to do, this actually does. Sometime I may detail it all out.
I don't say these things to brag, but rather to point out that the whole thing is organized into exactly these layers. Even more to the point, it helped me architect it and that architecture forced itself into this shape whether I wanted it to or not.
Here's what each loop looks like from the inside.
The execution loop
This is the foundation. Every task spawns a fresh AI session that runs an act-observe cycle until it's done. Read the inbox, classify, route, draft a response, check the result, repeat. The session dies when the task is complete. I don't engineer this loop much. The model handles it. What I engineer is everything around it.
The task loop
This is where the real work lives, and it maps directly to what Geoffrey Huntley calls the Ralph Loop. Every improvement to the system — a new capability, a bug fix, a reliability patch — gets a written specification with acceptance criteria and named tests. A fresh AI session builds it from scratch in an isolated copy of the codebase, deliberately re-feeding the full spec each time. If it fails review, the issue goes to rework and the whole cycle restarts clean. The apparent waste is the point, exactly as Huntley describes. Context rot kills long-running sessions. Short-lived, spec-driven builds don't rot.
The product loop
This is the software factory Tereza Tížková and Zach Lloyd describe, except mine runs on a Planner board with seven workflow stages and two explicit human gates. Gate one approves the idea. Gate two approves the merge. Between those gates, the system builds, tests, and prepares the work autonomously. An actuator watches for gate-two clearance, validates the branch in an isolated environment, runs the full test suite plus post-merge smoke checks, merges to main, applies deployment steps, and moves the issue to Done. (Note: I use Planner because we use that in our company for many projects, but it also works with Jira, Linear, and SQLite, which we also use for different things).
A governor layer monitors the review queue and throttles production when the queue backs up. If I can't keep up reviewing the output, the system stops producing until I catch up. Hourly cadence, up to sixteen slots a day, but the system is self-regulating. No human attention, no new work.
The system loop
This is what Roland Gavrilescu calls autoresearch, and it's the one I find most interesting to operate. An adversarial QA gate sits between the build and the merge: a separate AI session receives the diff, is told to assume the code is broken, and tries to prove it. In the last batch of nine system improvements, six failed the adversarial review on the first pass with genuine defects — including two flaws in my own specifications that I would have shipped. A weekly retro reviews outcomes and proposes the next round of improvements. Self-heal routines detect and fix operational drift without being asked. The system studies itself, and the results feed back into the product loop as new improvement cards.
The constraint that converges
Which brings me to the part of Dhinakaran's piece I think matters most.
She names an unnamed loop at the top of the stack (the one swyx labeled "????" in his diagram) and calls it the oversight loop. Set goals, allocate, cull. No exit condition listed.
I think it has an exit condition. And I think Anthropic already found it.
Dhinakaran reports that even inside Anthropic, the team running their internal coding agent is bottlenecked on reviews and on the human ability to conceptualize what the system is doing. Mike Krieger confirmed the constraint from the stage at AI Engineer World's Fair.
I'm seeing the same thing. The governor I built to throttle production when the review queue backs up fires regularly. The two human gates on the improvement board are the autonomy dial. And that dial has a natural limit: my ability to read diffs, verify behavior, and decide whether a change is sound. I built an adversarial reviewer to extend that bandwidth, and it works. I most definitely catches things I miss, but it generates findings that I still have to judge.
The constraint at every loop level converges to the same bottleneck: human judgment bandwidth. You can automate the execution, the build, even the verification, but the trust decision at the top stays human, and it stays expensive.
The field will figure this out by running into it. Some teams will crank the autonomy dial all the way up and ship broken things. Others will keep the dial at zero and wonder why they're falling behind. The teams that get it right will be the ones who instrument their loops well enough to know exactly where human attention is actually contibuting productively and efficiently. I'm still finding that line myself.
The interesting questions from the taxonomy is which dial to turn on which ring? and when to stop turning it?
Keep building,
-- JW
