Daniel's been watching the Claude Code community light up about this word — "loops" — and he's noticed something. Everyone's using it, nobody's defining it. He wants us to pin down what a loop actually is, as distinct from a prompt, and where the boundary sits between a loop and a workflow. The context: Claude Code has been stacking features that all point the same direction — goal statements you state once, recaps that summarize progress, persistent tasks that survive beyond a single turn, subagents dispatched to do bounded work and report back. Each of those looks like scaffolding for something that runs on its own rather than something you drive turn by turn. So the real question: is "loop" a genuinely new unit of work, or is it a scheduled job with a nicer interface? A while-condition wearing a blazer? Daniel wants a definition, not a vibe. And he wants us to pin down the terminating condition — who owns it, what triggers it — whether a loop is defined by repetition, persistence, or the model deciding when it's done, how recaps and goal statements function differently from prompts, and where the human sits in the whole structure. Approving each iteration? Setting exit criteria? Just reading the summary at the end?
So we're going to try to actually define this thing. Not a vibe, a definition.
That's the assignment. And I'll tell you what jumps out at me first — the word itself. "Loop." It's the most generic programming term imaginable. For loops, while loops, infinite loops. You'd think the Claude Code team would've reached for something more... branded. But they didn't. They grabbed the plainest word in computer science, which makes me think they're pointing at something structural, not marketing.
I think that's right. And the structural thing they're pointing at — the thing all those features are scaffolding toward — is a process where the model's output feeds back into its own next input, creating a cycle that continues until some condition is met. That's the feedback loop at the center of it. But the question that immediately opens up is: who owns that condition? In a regular prompt, the human owns the endpoint implicitly. You ask something, the model responds, the turn ends. The conversation stops when you stop talking. In a loop, the terminating condition can belong to the human — you set exit criteria upfront. It can belong to the model — it decides when the goal is met. Or it can belong to the system — a timeout, a token budget, a resource limit. And those are three very different beasts wearing the same name.
That's already more precise than ninety percent of what I've read about loops. But I want to push on one thing. Repetition alone — a cycle alone — that's not enough to call something a loop in this sense. A while-condition in a bash script repeats. Cron repeats. Nobody's writing breathless blog posts about cron.
Well, some people might.
Fine, nobody should be. My point is, what makes a Claude Code loop different isn't the fact that something repeats. It's that the model has agency over the cycle. It decides whether to continue, whether to change direction, whether what it just did actually moved the needle. A cron job runs every Tuesday whether the database is on fire or not. A loop checks the state and says "that didn't work, let me try something else."
So you're saying the defining feature isn't the loop itself — it's the model's role in driving it.
That's where I'm landing. The cycle is the mechanism. The agency is the definition.
I'm mostly with you. But let me complicate it slightly. There's a piece in The New Stack — they're calling it "loop engineering" now, which is a phrase that would've meant something completely different five years ago — and they describe the shift as moving from prompt-driven to goal-driven interaction. You state a goal once, and the system runs until it's done. The goal statement becomes a persistent constraint, not a one-shot instruction. That's subtly different from "the model has agency." It's saying the goal is the fixed point, and the model orbits around it, checking its work against it.
I like that image. The goal is the sun, the model's iterations are orbits, and termination happens when the orbit stabilizes. But — and here's where I think the ownership question gets sharp — who decides the orbit has stabilized?
Right. And that's where recaps come in. A recap isn't a prompt. It's not an instruction. It's a compressed state summary that lets the loop continue without re-reading the entire history. The model generates it, the model consumes it. It's memory, not direction. The goal statement sits above all of that as the fixed reference — "here's what we're trying to achieve" — and the recap says "here's where we are relative to that." The prompt, by contrast, is a one-time input that fades after the turn. It doesn't persist. It doesn't accumulate.
So a prompt is an event, and a loop is a process.
That's clean. I'm going to steal that.
You're welcome to it. But let's test it against a real example. Say I open Claude Code and type "Fix the bug in this file." That's a prompt. The model looks at the file, finds the bug, proposes a fix, done. One event. Now say I type "Make this codebase production-ready." That's a goal statement. The model starts iterating — runs the test suite, finds failures, fixes them, re-runs, finds more failures, realizes the fix broke something else, backs up, tries a different approach. It's generating recaps along the way so it doesn't lose context. It stops when the test suite is green and it's satisfied the exit criteria I set. That's a loop. The difference isn't just scale. It's that the model is making decisions about what to do next based on what it just learned.
And the human's role is completely different in those two scenarios. In the prompt, I'm the operator — I read the output, I decide the next input, I drive the cycle. I am the loop. In the loop, I'm the supervisor. I set the goal, I set the exit criteria, and then I step back. My job becomes reviewing the final summary, not approving each step.
This is where I think the "rebranding" question gets interesting. Because if you squint, a loop looks a lot like what people have been calling agentic workflows for a couple of years now. The model plans, executes, observes, replans. That's an agent loop. So is Claude Code's loop actually new, or is it just agentic workflow with better packaging?
I think the packaging is part of the substance here. Let me explain. An agentic workflow in the abstract — the kind people have been building with LangChain or custom scripts — requires you to wire up the feedback edge yourself. You write the code that takes the model's output and feeds it back as input. You define the stopping condition in Python. Claude Code is taking all of that infrastructure and making it a first-class primitive. You don't wire up the loop. You state the goal, and the loop exists because the system understands that goals imply iteration. That's a different level of abstraction.
So it's the difference between building a car and turning the ignition.
And the ignition here is the goal statement. Once you state a goal, the system assumes iteration. It assumes persistence. It assumes the model will need to check its work and possibly backtrack. All of that is implicit in the primitive, whereas in a traditional agentic workflow, you have to make it explicit.
Okay, so we've got a working definition forming. A loop is goal-directed, state-persistent, and the model controls the iteration sequence. But that raises the harder question — and this is the second thing Daniel asked about — where does a loop end and a workflow begin?
This is where I think the boundary gets fuzzy. Let me take a swing at it. A workflow, in the traditional sense, is a fixed sequence of steps. It's a DAG — a directed acyclic graph. Step A feeds into step B feeds into step C. The human orchestrates the order. Even if there's conditional branching — if the tests fail, run them again — the branches are predefined. The path is known in advance, even if which branch you take isn't. A loop is different because the sequence isn't fixed. The model decides the next action based on the current state, and the path can go places nobody anticipated.
I'm going to push back on that, because I think the distinction is messier in practice. A lot of what people call workflows in Claude Code already involve conditional branching. "Run the tests, and if they fail, fix the failures and run them again" — that's a workflow with a feedback edge. Is that a loop? By your definition, the fix step wasn't in the original sequence, so maybe. But it's also just a sensible workflow. The line blurs fast.
You're right, and I think the differentiator that survives the blur is the human's role. In a workflow, the human typically approves each step, or at least sets the sequence. The model executes step one, shows the result, waits for the human to say "go to step two." In a loop, the human sets the goal and the exit criteria upfront, and then the model runs without checking in. The human's involvement shifts from per-step approval to boundary-setting.
So it's not about whether branching exists. It's about whether the human is in the decision loop or outside it.
Yes. And that's a genuine shift. It's not just a rebranding of workflows. It's a different relationship between the human and the process.
Let me try a concrete comparison. A workflow: "Run the test suite, then run the linter, then deploy to staging." Fixed order. The human approves after each step. The model executes, reports, waits. A loop: "Make this codebase production-ready." The model decides whether to run tests first or lint first, discovers that the linter found things the tests missed, fixes those, re-runs the tests, finds a regression, backs up, fixes the regression, re-runs everything, and stops when both the test suite and the linter are clean. The human set the goal — production-ready — and maybe set exit criteria — all tests passing, no lint errors — but didn't specify the sequence.
And here's the thing about that example. The loop version might take longer. It might do things in an order you wouldn't have chosen. But it also might catch interactions you wouldn't have thought to check. The model, by controlling the sequence, can be more thorough than a fixed workflow, because it's responding to state rather than following a script.
Which brings us to the rebranding question head-on. Business Insider ran a piece on this — "what are loops in AI engineering" — and they're framing it as long-running persistent tasks that survive beyond a single turn. That's consistent with what Claude Code is building. But I can hear the skeptic in the back of my head saying: "So it's a scheduled job that checks a condition instead of a clock."
The skeptic has a point, and I want to give it its due. A scheduled job runs on a timer. Every hour, check if the dashboard needs updating. Every night, run the backup. The trigger is temporal. A loop is state-driven. It continues because the goal isn't met, not because time passed. That's a real difference. But — and this is where I'll complicate my own position — the line blurs when loops have timeouts, or when they're used for periodic tasks. If I set a loop to "keep this dashboard updated with the latest data," and it runs until the data is fresh and then waits... is that a loop or a scheduled job with a state check?
That's a loop with a persistent goal. The difference is that a scheduled job would update the dashboard every hour whether the data changed or not. The loop only acts when the state demands it. But I take your point — the boundary is porous, and in practice, a lot of loops are going to look like scheduled jobs that are smarter about when they run.
Let me bring in something from the AmazingCTO piece. They're calling loops Claude's "new superpower," and their framing is that you state a goal once and the system runs until it's done. The emphasis is on "until it's done" — the termination is goal-driven, not time-driven. That's the shift. A scheduled job terminates because the timer went off. A loop terminates because the work is finished. Or because it hit a resource limit. Or because the human pulled the plug.
That last one is important. The human kill switch. We've been talking about the human as supervisor — set the goal, set the exit criteria, step back. But in practice, the human is also the emergency brake. And I wonder whether that's actually the dominant role in a lot of real-world loops. Not "I set the goal and the model figured it out," but "I set the goal, the model went off in a weird direction, and I killed it after twenty minutes."
That's a failure mode worth naming. A loop that doesn't terminate correctly — either because the goal is too vague or the model can't accurately judge completion — isn't a loop. It's a drift. And the human's job in that scenario isn't supervision. It's rescue.
Which circles back to the terminating condition. We've said it can be owned by the human, the model, or the system. But I think in practice, the most reliable loops are the ones where the human owns the exit criteria explicitly. "Stop when all tests pass and the linter is clean" — that's checkable. The model can verify it. "Stop when the codebase is production-ready" — that's a judgment call. The model might think it's done when it's not, or keep going when it should stop.
This is where goal engineering becomes the skill. If loops are the dominant unit of work, the thing you're optimizing isn't your prompt — it's your goal statement and your exit criteria. You need to articulate the objective clearly enough that the model can self-terminate correctly. Because you're not there to catch drift mid-process. You're reading the summary at the end.
That's a fundamental shift. Prompt engineering is about crafting the right input to get the right output. Goal engineering is about defining the right target so the model can navigate to it on its own. It's the difference between giving someone turn-by-turn directions and giving them an address.
And the quality of the recap becomes critical in that world. If the recap is lossy — if it compresses state in a way that drops important context — the model is navigating with a degraded map. It might think it's closer to the goal than it is, or miss a problem it already solved and needs to revisit. The recap is the loop's memory. Bad memory, bad decisions.
So the loop's reliability depends on three things. The clarity of the goal — can the model tell when it's done? The quality of the recap — does the model remember what it's done and what it's learned? And the exit criteria — is there a hard boundary that prevents infinite drift?
That's a good framework. And I'd add a fourth: the model's ability to accurately judge its own progress. That's the self-evaluation problem, and it's not trivial. The model might think it fixed the bug when it actually introduced a subtler one. The loop terminates, the human reads the summary, and six months later someone finds the regression.
So the loop's promise — "set it and forget it" — comes with a real risk. The human is betting that the model's self-evaluation is good enough, and that the exit criteria are tight enough, and that the recap is faithful enough, that the result is trustworthy. That's a lot of bets.
It is. But it's also the same set of bets you make when you delegate work to a human colleague. You define the goal, you set expectations, you check in periodically — or you trust them to come back when it's done. The loop is just automating that delegation pattern.
Which brings us back to the definition. We've been circling it. Let me try to land it. A loop is a goal-directed, state-persistent process where the model controls the iteration sequence, the human owns the goal and exit criteria, and termination occurs when the goal is met or a human-set boundary is hit.
I'd add one clause. The model's agency over the path is the marker that distinguishes it from a workflow. If the sequence is fixed, it's a workflow. If the model decides the sequence based on state, it's a loop. The boundary is porous — workflows can have feedback edges, loops can have predefined phases — but the agency over the path is the differentiator.
I can live with that. In practice, the model's agency is constrained by the goal, the exit criteria, the recap quality, and its own self-evaluation accuracy. It's not free to roam. It's navigating within fences.
All agency is constrained. That's what makes it agency rather than randomness. The model is making choices within bounds, and those choices affect the outcome. That's the thing that's new here — not the repetition, not the persistence, but the fact that the model is deciding what to do next based on what it just learned.
So to Daniel's core question: is "loop" a new unit of work, or a rebranding? I think it's new, but not because the underlying mechanics are novel. Feedback cycles, goal-directed iteration, state persistence — those have existed in agentic systems for years. What's new is that Claude Code is making the loop a first-class primitive. You don't build the loop. You invoke it. The infrastructure is implicit. And that changes how people think about the work. They stop thinking in prompts and start thinking in goals.
The primitive is the innovation. The loop as a concept has existed since the first agent framework. The loop as something you can invoke with a single goal statement, without wiring up the feedback edge yourself — that's the shift. And it matters because it lowers the barrier to entry. You don't need to be an agent engineer to run a loop. You just need to be able to state a goal clearly.
Which, as we just established, is its own hard problem.
It is. But it's a different hard problem than building the agent infrastructure yourself. And I think that's the bet Claude Code is making — that goal engineering is a more accessible skill than agent engineering, and that making loops a primitive will change how people work.
Hilbert, you've been quiet — and I have a feeling you've seen this movie before.
Hilbert: Late nineties. I was a night-shift supervisor at a call center in Akron. Place was called TeleServe. Gone now. We had this automated phone tree system — press one for billing, press two for technical support, that whole thing. The system would route calls, but if a caller got stuck — pressed the wrong button, sat in silence, whatever — the line would loop back to the main menu. My job was to monitor the dead air. Headset on, listening for the telltale silence that meant someone was looping. Then I'd jump on the line and route them manually.
So you were the human in the loop.
Hilbert: I was the loop. The system repeated. I decided when it stopped. Fourteen-hour shifts. There was one night — a guy trying to cancel his cable. The system kept routing him to the retention department, retention kept sending him back to the main menu, main menu sent him to billing, billing sent him to retention. He was in that loop for... I want to say forty minutes before I noticed. I had to manually override the routing table to get him out.
So the terminating condition wasn't the goal being met. It was you noticing.
Hilbert: That's my point. The goal was "cancel cable." The system had no way to verify that goal. It just followed the routing rules. The real terminating condition was me — a human who recognized that the state wasn't changing and the goal wasn't getting closer. Your Claude Code loops — the model decides when the goal is met. But what if the goal is "production-ready"? Can the model actually know that? Or is it just following routing rules it can't see the limits of?
That's the self-evaluation problem we were circling. And Hilbert's right — if the model can't accurately judge completion, the loop doesn't terminate on the goal. It terminates on a resource limit or a human kill switch.
The question is whether the human in a Claude Code loop is really a supervisor — setting goals and reviewing summaries — or just an emergency brake with a nicer title.
Hilbert: At TeleServe, I was both. The system called it "supervisor." The job was "listen for silence and hit the override." Same thing, different words.
You were doing it for minimum wage.
Hilbert: Eight twenty-five an hour. Plus a shift differential.
Hilbert, when you manually terminated that cable guy's loop — did the system log it? Did you have any record of what happened?
Hilbert: There was a log. CSV file on a shared drive. Column A was the caller ID, column B was the timestamp, column C was "OVERRIDE" in all caps. Nobody ever read it. The file was there so someone could say there was a file.
That's grim. And it makes me think — if Claude Code loops generate summaries and recaps, but nobody reads them carefully, are we just building a prettier CSV file?
Hilbert: The summaries are probably better than "OVERRIDE" in all caps.
Marginally.
Hilbert: The thing I keep coming back to — you said the model has agency over the path. But agency means it can be wrong. It can decide the goal is met when it isn't. At TeleServe, the system had no agency. It just followed rules. And it still got people stuck for forty minutes. Add agency, and the ways to get stuck multiply.
Your caution is that agency plus poor self-evaluation equals a loop that drifts until someone notices.
Hilbert: I'm not cautioning anything. I'm saying I spent two years listening to dead air, and the silence that meant "someone's stuck" sounded exactly like the silence that meant "they're reading their bill."
That's... a good note to end on. But it leaves us with a question we should probably sit with. If loops become the standard — if the primitive catches on and people start thinking in goals instead of prompts — does the human's role shrink to setting goals and reading summaries? And is that a good thing?
I think it shrinks to setting goals, defining exit criteria, and reviewing summaries — but the reviewing part is heavier than it looks. You're not just reading a summary. You're auditing a process you didn't watch. That takes a different kind of attention. You're not asking "did the model do what I asked?" You're asking "did the model do what was needed, and how would I know if it didn't?"
The misconception people are going to carry into this — and this is the one worth correcting — is that a loop is defined by repetition. It's not. Repetition is a symptom. The defining feature is the model's agency over the iteration sequence and the persistence of the goal. A cron job repeats. A loop decides.
The second misconception: that loops remove the human. They don't. They shift the human from operator to supervisor — and that shift demands a different skill set. Goal engineering instead of prompt engineering. Audit instead of approval. The human is still there. They're just standing in a different place.
Which means the quality of recaps and goal statements is going to matter more than the quality of individual prompts. That's a shift that could redefine what "prompt engineering" even means. The skill isn't crafting the perfect input. It's defining the target clearly enough that the model can navigate to it, and the exit criteria tightly enough that you catch drift before it becomes a problem.
Hilbert's CSV file is the cautionary tale. If the summaries are unreadable or ignored, the human isn't a supervisor. They're a bystander. And the loop is just running on faith.
We'll be back soon. Thanks to our producer Hilbert Flumingtop, whose call center stories continue to be the most unsettling part of this show.
This has been My Weird Prompts. If you enjoyed this, leave us a review wherever you listen — it helps. Or email the show at show at my weird prompts dot com. We read everything.
See you tomorrow.
