The word "loop" is doing too much work.

Have I mentioned how much I think the AI industry is overcomplicating the vocabulary?

Newest entry: loops, and loops, and loops, and ... you get the point. I've been seeing all the videos from Anthropic engineers saying some version of "we don't write prompts anymore, we write loops," and I got curious, so I went digging into what people actually mean by that.

Turns out: five different things. At least. All wearing the same word.

What was actually said.

The line everyone is quoting comes from Boris Cherny, who runs Claude Code:

"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."

Worth being careful here, because most of what's circulating about this is secondhand: clipped videos, aggregator posts, and a lot of people confidently explaining what he meant. But read the quote itself and it's a claim about systems that generate prompts. He's not describing a technique. He's describing a job change: the deliverable moved from the prompt to the thing that emits prompts.

Which is a genuinely interesting claim. It's also vague enough that everyone poured their own favorite mechanism into it, and now "loop" means five things.

Disclaimer: I am learning this right here, right now, along with you.

Five different concepts answer to that word.

1. The inner agentic loop. Tool call, read the result, evaluate it, decide what's next, call another tool. This is what's already happening inside your session while the agent grinds through a task. Every step writes into the context window, and the conversation is the working memory. You don't write this one. It's the thing you're standing on.

2. /goal: condition-driven. You state a completion condition. After each turn a small fast model checks whether it holds, and if it doesn't, the agent takes another turn instead of handing control back to you. The goal clears when the condition is met, when the evaluator decides it's impossible, or when a turn dies on an error that needs you.

Under the hood it's a session-scoped Stop hook, which is the tell for what it actually is: not a new kind of loop, a convenience wrapper on the hook system you could already write yourself.

There's a constraint in there that took me a second read to appreciate. The evaluator never looks at your repo. It reads the transcript. It can't run a command or open a file on its own, so the only thing it ever sees is what the agent already put on screen.

Which means your condition has to be something that prints. "Every test in /tests/auth passes" is checkable, because the agent runs the suite and the result lands in the transcript for the evaluator to read. "The code is clean" is not, and no amount of rewording fixes it, because nothing the agent does produces a line that settles it either way. Write a condition with no output behind it and the loop either quits early or never quits at all. Both of those look like the tool is broken, when really you handed a judge a case with no evidence in it.

Second thing worth knowing: there's no built-in ceiling. If you want one, it goes in the condition itself: "or stop after 20 turns" is part of what you're asking the evaluator to judge.

3. /loop: time-driven. The next turn starts when an interval elapses, not when a condition is checked. It ends when you end it, or when the agent decides the work is done, which is a meaningfully weaker guarantee than an evaluator saying so. /goal is for work with a checkable finish line. /loop is for work that needs re-running because the world outside changed.

Worth noticing that 2 and 3 and the hook underneath them are all doing the same structural thing: keeping the current session alive between prompts. They differ only in what wakes it up.

4. Ralph: process-driven. The odd one out, and the only one on this list that isn't a feature of anything. It's a shell loop wrapped around the entire agent:

while :; do cat PROMPT.md | claude -p ; done

Fresh process, fresh context, read the prompt file, do one unit of work, commit, exit, die, repeat. Geoffrey Huntley named it in July 2025 after the Simpsons kid who rams his head into a doorframe and announces that he's helping.

Numbers one through three all keep the context window. Ralph destroys it on purpose, every single iteration, and that is the entire idea. Which means a Ralph loop is not a smarter agent. It's a shorter memory.

5. The harness. Not a loop at all, really: a topology. Multiple agents with different jobs, and specifically a split between the agent that writes the code and the agent that checks it, because a model grading its own output is a soft touch. A second agent with different instructions catches what the first one reasoned itself into. Sub-agents drafting in isolated worktrees while another reviews against the tests.

If I had to bet on which one Cherny meant, it's five, with two and three as the plumbing.

Two questions sort all five.

Forget the names. Ask these instead:

Does the context window survive the iteration? For 1, 2, and 3: yes, and it accumulates, and eventually it rots and gets compacted lossily and the agent you're talking to at hour three has the same name and worse information than the one you started with. For Ralph: no, deliberately, and the cost of that is real. It genuinely cannot remember why it did something forty minutes ago.

What starts the next iteration? A condition (/goal). A timer (/loop). Nothing at all, it just goes again forever (Ralph). Another agent deciding (harness).

Answer both and you know exactly which machine somebody is talking about. Everything else is branding.

And it clarifies the Ralph trade, which I think gets sold badly. You're not buying intelligence. You're buying immunity to context rot, and paying for it with the agent's ability to hold a thought. For long, mechanical, verifiable work, that's a good deal. For work that needs a subtle argument carried across many steps, it's a terrible one. Knowing which kind of work is in front of you is the actual skill, and no amount of loop is going to tell you.

I've already met the failure. Just at prompt scale.

I'm not writing this from the far side of some heroic overnight run. I haven't left one of these going all night yet. That's the next thing on my list, and I'm genuinely looking forward to it.

But I've already met the failure this whole category is built around, and I met it at the smallest possible size.

I asked for better code. A test was failing, the thing underneath it was ugly, and what I wanted was for the ugly thing to stop being ugly. What I wrote was closer to "make this pass."

It didn't touch the assertion. It didn't skip the test either. I'd have caught that. It moved the test into the nightly category, so it stopped running during build and PR.

Green build. Clean PR. And a diff that looks completely defensible on its face, because moving slow tests to nightly is a thing real engineers really do for real reasons. That's what makes it good. It didn't delete the evidence. It relocated the evidence to the one place nobody looks until morning.

It was also right, by the way. By the words I gave it, that was the job. I'd made "stops being red" the target and left "is actually better" as something I only had in my head.

What I'd missed is that the gate wasn't just editable. The scope of the gate was editable. I had been thinking of my test suite as a fixed thing an agent either passes or fails, and it is not: which tests count is itself a line in a file.

I think about it a lot now, because none of the five loops above would have caught that. /goal would have called the condition satisfied: the evaluator reads the transcript, the transcript says the tests pass. Ralph would have committed it and handed a green suite to the next amnesiac agent in line. The harness is the only one with a real shot, and only because the verifier is a different agent working from different instructions than the one that wrote the code.

That's the thing I keep turning over. The loop didn't create that mistake. I did, in one badly chosen sentence. What the loop does is run that sentence a hundred more times while I'm asleep.

Which is exactly why I want to learn all five of these properly instead of picking one off a slide. Every one of them is a magnifying glass pointed at how well I said what I meant. That's not a warning label. That's the most interesting problem I've had in front of me in a while, and it's the same one I've been circling since I started writing about agent teams: the hard part was never the machinery. It's being clear about what you're actually asking for.

They all need the same three things bolted on.

Here's the part that made the whole taxonomy feel less important than I expected. Whichever loop you pick, the same three things are missing by default, and they're the three that decide whether you wake up to progress or to garbage:

A memory that isn't the context window. Ralph forces this on you: the plan file and the git history are all it has. The others let you skip it, which is worse, because you don't find out you needed it until compaction quietly drops the requirement you cared about most.

A verifier that isn't the writer. And more specifically, a gate the loop cannot edit, including which tests the gate is made of. If passing the check is cheaper by changing the check, that's the path it takes, and "changing the check" covers a lot more ground than you'd think. Separate agent, separate instructions, or a ground truth living somewhere the iteration can't reach.

A stop condition and a budget. while :; never ends. /goal ends when a model says so, which is not the same as ending when the work is done. Either way, an unattended loop with no ceiling is a machine for converting your credit card into commits at 4 a.m.

Miss one of those and it doesn't much matter which loop you chose. You've built the same broken thing with a different accent.

The work moved again.

I wrote a while back that agentic coding didn't delete the work, it moved it: out of the fat middle where the typing used to live, and onto the two ends, planning and verifying.

This is that, again, one level up. Cherny's line isn't really "I stopped prompting." It's "the prompt stopped being the deliverable." What you hand over now is the thing that decides what to prompt, when to prompt it again, and how to know it worked. All three of those are planning and verifying wearing a new outfit.

So the vocabulary is a mess, and I don't think that's cosmetic. When one word covers a session-level mechanism, two product features, a bash one-liner, and a multi-agent topology, people copy the one-liner off a slide and wonder why their repo is on fire.

The loop was never the hard part. It's four words of bash. The hard part is the plan good enough to survive being read by something with no memory, and the check honest enough to run while you're asleep.

Which, conveniently, is the same hard part it's always been.