Continuous Enforcement and Continuous Verification
TL;DR. Everyone has rediscovered that an agent is a model in a loop, but a loop that stops when the model decides it is finished is not a control loop, it is an unguided projectile. Toyota closed exactly this kind of loop seventy years ago with jidoka, stop the line the instant a defect appears, and kaizen, turn every defect into a permanent change to the process. Their agentic equivalents are Continuous Enforcement , which makes an agent's recurring mistake non-committable rather than discouraged in a prompt, and Continuous Verification , which makes "done" something a kernel computes against a specification rather than something a model declares. Together they are the comparator and the stop-cord the loop discourse leaves unspecified: loose enough to let the agent roam, tight enough to converge. The same idea explains why a small model in a tight loop can beat a frontier model asked once, why two individually sound rules can combine into a harmful one, and why an agent that cannot feel the cost of your time will spend it freely.
Listen to this essay (55 min)
Your browser does not support audio. Download MP3.
Narrated by Charlie via ElevenLabs
The loop is having a moment, and for once the excitement points at something real. Anthropic ships the agentic loop as a documented primitive in its Agent SDK: receive a prompt, call a tool, feed the result back, repeat. It writes, more ambitiously, about recursive self-improvement, the loop that builds the next loop. And across every feed someone is explaining, with the air of a revelation, that an agent is "just a model in a loop". They are right that the loop is the unit, and right that it is the thing that separates a chatbot from an engineer.
They are also describing the oldest idea in control engineering, which means the interesting question is not whether you have a loop but what closes it. Feeding a tool result back and conditioning the next action on it is already feedback, and a capable model deciding what that result means is already a kind of comparator. The careful articulations go further: the Agent SDK lets you cap turns and spend, and exposes hooks that fire before a tool runs and when the agent stops, which are precisely the places a real check belongs. None of that is the strawman. The strawman is what the loop does by default, when you specify none of it, and the default is stark in the SDK's own words: the loop ends "when Claude produces a response with no tool calls". The stopping condition, the comparator that rules the work done, is the actuator's own say-so. A loop that halts when the thing doing the work declares victory has no comparator at all. The two things that rush in to fill that gap are an agent grading its own homework in prose and a prompt stuffed with "always remember to" guardrails. Both feel like control. Neither is.
Manufacturing settled this argument seventy years ago, across a great many ruined batches. The discipline that came out the other side has a name, the Toyota Production System, and the two ideas I want to borrow from it are jidoka [autonomation: building in the ability to stop the instant a defect appears] and kaizen [continuous improvement: every defect becomes a permanent change to the process, not a patch to the part]. Software already imported both, more thoroughly than the loop discourse admits. The problem is that it tuned them for a slow, careful, human author, and the agent is neither slow nor careful nor, in any sense that matters, an author with a stake in the outcome.
So I want to give two names to the parts of the loop that the agent breaks, because naming a thing is how you get to enforce it. Continuous Enforcement : the andon cord recalibrated for machine speed, where the agent's recurring mistake becomes non-committable, not merely discouraged in a prompt. Continuous Verification : the part of the specification you can make decidable, turned into a checkable artefact, so that on that part "done" is computed rather than claimed. These are the comparator and the stop-cord. Without a specified comparator and a real stop-cord you do not have an agentic engineer. You have an extremely fast, extremely confident open loop, and an open loop with a powerful actuator is not autonomy. It is an unguided projectile: committed, quick, and blind to where it lands.
(A note on the name. "Continuous Verification" is also used for an unrelated chaos-engineering practice, and for an ML-rollback feature in at least one deployment tool. I mean neither. I mean the verification half of the same control loop the CI/CD world already built, pushed down into a decidable specification.)
A loop is a control loop, or it is nothing
Strip the language model out and look at the shape. A control loop has five parts, and you cannot remove any of them and still call what is left "control":
A setpoint : the target. The dimension the part must hit, the property the code must...