Claude Code Loop Types: A Practical Breakdown

The phrase "agentic loop" has developed that particular viral quality where everyone's using it and fewer people than you'd expect can explain what distinguishes one loop from another. AI LABS, a software company that's been running these patterns in production, recently put out a breakdown of five distinct Claude Code loop types—and whatever you think of the breathless title, the underlying taxonomy is genuinely worth sitting with.

The framing they open with is actually the most useful thing in the video: "That only happens when you're using the wrong type of loop for the job." The "that" being token burn so spectacular it makes your usage limit disappear in real time. The argument isn't that loops are good or bad. It's that they're tools, and like most tools, the damage usually comes from misapplication rather than the tool itself.

Before getting into the five types, they make a foundational distinction that's easy to gloss over. Loop engineering is defined as the shift from you writing the prompts that drive an agent to the system writing the loop itself. The agent learns as it goes, adapts to problems it hits, and decides what needs to happen next. This is meaningfully different from a sophisticated prompt—it's closer to handing off process ownership.

The Stateless Loop: Simple, But Not Dumb

The first type is the one most developers have encountered, possibly without realizing it had a name. AI LABS calls it the stateless loop: no memory, no self-improvement, just task execution with a verification step. The Ralph loop, which has its own growing mythology in Claude Code circles, is the canonical example. The goal command is another.

The mechanics are straightforward. You define a goal, Claude works toward it, a smaller model (Haiku, in Claude Code's case) checks the work against your original requirements, and if anything's missing, the agent gets re-prompted. Simple. Clean. And as they note, it "leans entirely on the model to decide whether a task's done with no standard to measure the work against."

That's not a fatal flaw—it's a design constraint that tells you exactly when to use it. Their solution is test-driven development: write the tests first, set the goal as passing every test, and let the loop run. The agent writes code, runs tests, iterates. When every test passes, the goal is complete by definition. The verification isn't left to the model's judgment; it's encoded in the tests themselves.

The cost data they share is worth pausing on. One run took around 39 minutes and burned through more than 200,000 tokens. For context, that's not a rounding error—it's the kind of number that makes you reconsider whether the loop is the right tool or whether you just handed a complex multi-step problem to a mechanism that will faithfully work on it forever. The stateless loop is efficient when the task is genuinely bounded. When it isn't, the meter just keeps running.

Learning and Multi-Agent: Where It Gets Interesting

The learning loop is conceptually the sharpest of the five. Instead of completing a task and stopping, it improves something you'll use repeatedly—a skill, a workflow, a reusable component. The mechanism involves running the skill both with and without the improvement, measuring the actual difference, and documenting everything in a learning.md file that lives inside the skill itself.

That documentation layer is doing more work than it might appear to. AI LABS describes it as "an improvement journal that documents everything the agent learns in a structured format"—what was tried, what the result was, what lessons emerged across multiple rounds. The agent isn't just improving the skill; it's building an explicit record of its own reasoning process. Whether you find that elegant or slightly uncanny probably says something about where you sit on the "AI autonomy is fine actually" spectrum.

The multi-agent review loop takes a different approach to a familiar problem: one reviewer misses things. Their solution—splitting review responsibilities across four specialized agents (factual, domain, safety, style), coordinated by an orchestrator—echoes Andrej Karpathy's LLM Council concept, which he described as multiple models arguing toward a conclusion. The framing matters here: a single agent reviewing across multiple dimensions isn't the same as multiple agents each accountable for their own dimension. The blind spots are different shapes.

The orchestrator design choice is interesting and not obviously correct. They chose it over direct agent-to-agent communication specifically because "one agent needs to hold the context of the previous rounds to coordinate the workflow properly." That's a real constraint—context coherence across rounds is genuinely hard—but it also creates a single point of coordination failure. Whether that trade-off is right depends heavily on what you're reviewing and how long the conversation gets.

Verification and Workflow Improvement: The Heavy End

The verification loop is, by their own description, expensive and slow—and they're refreshingly direct about when not to use it: "We wouldn't recommend it unless you've already built the whole app at a larger scale and want it thoroughly reviewed." One agent implements against a PRD; another scores the implementation against defined metrics; the implementer's entire job is to push that score up. What they call the "thermonuclear review" is a dynamic workflow that fans out across multiple sub-agents reviewing different dimensions simultaneously. It's thorough in the way that's also synonymous with "will take a while and cost real money."

The lighter alternative they mention—a normal reviewer agent without the dynamic workflow—is worth noting as a practical concession. The verification loop's value isn't in the specific architecture; it's in the scored-metric accountability structure. You can get most of that without the full thermonuclear apparatus.

The workflow improvement loop is the one that generates the most interesting questions. It's not improving a skill (like the learning loop) or refining an output (like verification). It's improving the process itself—what they describe as the loop looking at "the process itself and suggests improvements to the workflow." Three agents: a builder, a scorer, and a process optimizer that reviews each iteration and suggests structural changes to how the loop runs.

The promise is striking: "You walk away with a workflow that's been tested and refined with every step validated as one that actually needs to be there." The implicit claim is that the agent can distinguish necessary steps from vestigial ones—that it can, in effect, do some of the work that a thoughtful engineer does when reviewing process documentation. Whether current models are actually good at that, at scale, across diverse project types, is a question the video doesn't fully stress-test. It works in their use case. Generalizability is a different matter.

The Real Taxonomy Question

What AI LABS has actually built here is something more useful than a feature list: a cost-benefit framework for agentic patterns. Stateless loops are cheap and fast when you have hard verification criteria. Learning loops pay off when you're investing in reusable infrastructure. Multi-agent review is better than single-agent review, but the orchestration overhead is real. Verification loops are the right tool for the end of a large project, not the beginning. Workflow improvement loops are the most ambitious and the hardest to evaluate.

The underlying tension in all of this is the relationship between autonomy and cost. More sophisticated loops give the agent more latitude to make decisions—and they consume more tokens doing it. "The core idea of loop engineering," they explain, "is that you stop being the person writing the prompts that drive the agent and you turn it into a system that writes the loop itself." What you're actually trading is your time and judgment for computational cost. The question worth asking before any loop run isn't just "which loop?" but "what's the value of the human time this is replacing, and does the token cost beat it?"

That math is different for every team, every task, and every model pricing tier. No taxonomy resolves it for you—it just gives you better questions to ask.

Dev Kapoor covers open source software and developer communities for Buzzrag.