Boris Cherny put it pretty plainly: “I don’t prompt Claude anymore. I have loops that are running.” And honestly, that one line gets at the heart of Loop Engineering. Once AI agents start doing real work, the prompt stops being the main event. The system around the model takes over.
That shift matters more than a lot of people realize. If you’ve been treating agents like fancy chatbots, you might miss the bigger picture. The real leverage comes from how the loop behaves, how the harness supports it, and how the verifier keeps it honest. So, instead of obsessing over one perfect prompt, you start thinking like an engineer who’s designing a machine that can keep going, recover from mistakes, and know when it’s actually finished.
Quick Highlights
- Agents are becoming systems, not just prompts.
- The loop is simple; the support layers are where the hard work lives.
- Bad context and weak tools quietly wreck long runs.
- A verifier is what keeps the agent from congratulating itself too early.
Introduction
Boris Cherny, who built Claude Code, says he writes loops, not prompts — and that’s the point of loop engineering for AI agents. The idea sounds small at first, but it’s actually a pretty big mental shift. Instead of asking, “What prompt should I write?” you start asking, “What system should run around the model?”
The article takes apart why the model is no longer the main thing, and why the system around it now does most of the real work. That includes the way tasks are broken up, how tools are called, how failures are handled, and whether the agent can tell if it’s done or just temporarily stuck. In practice, that’s where the difference between a clever demo and something usable in the real world shows up.
Why the loop itself is the easy part
The core agent loop is basically already solved: model → tools → context → repeat. If you strip away all the fancy language, that’s the basic pattern. The model thinks, decides whether to use a tool, gets the result, updates its context, and keeps going until it stops asking for more.
The raw Python version is just a while True loop that calls tools when the model asks, then feeds the results back until the model stops asking. That’s not the hard part anymore. You can sketch that in a few lines, and most people who’ve built even a toy agent have already done something very close to it.
That’s why the interesting work moved away from the loop’s shape and into everything wrapped around it. The loop is just the skeleton. The real body is everything that helps it stay useful over time.
The six-line agent pattern every framework converges on
Most serious agent frameworks land on the same structure: read context, call tools, return results, repeat. It’s almost funny how quickly different systems start to look alike once they’re doing something real. The names change, the APIs change, the wrapper code changes, but the core rhythm stays the same.
The point is not the while statement. It’s what happens after the model starts acting inside that loop. That’s where loop engineering starts to separate itself from ordinary prompt tweaking. You’re no longer just asking the model to be smart. You’re building the rules of engagement around its decisions.
What actually matters now: the harness, context, and prompt layers around the model
The center of gravity in AI has shifted from the model to the layers around it. That’s a little uncomfortable if you’re used to thinking model quality is everything, but it matches what people are seeing in practice. Same model, different system, very different outcome.
The article separates prompt engineering, context engineering, harness engineering, and loop engineering, then points to LangChain’s line: “Agent = Model + Harness.” That’s a useful shorthand because it forces you to stop thinking in isolated pieces. A good prompt doesn’t save a bad harness. A smart model doesn’t rescue broken context. And a clean loop doesn’t help much if the surrounding code is sloppy.
It also makes the blunt claim that the harness now matters more than the model, with teams keeping the model fixed and jumping from the middle of a benchmark into the top five just by changing the code around it. That sounds dramatic, but it’s not really surprising. The harness decides what the model sees, what it can do, how it recovers, and when it’s allowed to keep going.
| Layer | What it controls | Why it matters |
|---|---|---|
| Prompt engineering | The words you send | Still useful, but only one piece of the system |
| Context engineering | Everything the model sees | Shapes what the model can reason about |
| Harness engineering | Code that runs tools, tracks state, and handles errors | Now more important than the model in practice |
| Loop engineering | The autonomous cycle toward a goal | Defines how the whole system behaves over time |
How loop engineering fails: stopping too early, rotting context, and bad tools
The article’s middle is about failure modes, because the hard part is not starting the loop. Starting is easy. Keeping it useful is where things get messy. And once you’ve watched an agent go off the rails a few times, the same patterns start to feel very familiar.
It names the three big ones clearly: an agent that thinks it is done when it only ended its turn, context rot that makes the model dumber over time, and tool design that gives the agent too much to choose from or too little guidance when something breaks. These are the kinds of failures that don’t always look dramatic at first. They just slowly drain the quality out of the system.
Why “the turn ended” is not the same as “the task is done”
A coding agent can write some code, see progress, and declare victory even while the tests still fail. That’s the tricky part. The model is reacting to the last thing it saw, not necessarily the whole problem.
That’s why good loops need max iterations, budget and time limits, no-progress detection, and a real completion check. “Done” should mean the tests pass, not that the agent feels good about the result. If you’ve ever had a task appear finished and then fall apart five minutes later, you already know why this matters.
What context rot does to long-running agents
Long loops collect old tool outputs, dead ends, and stale reasoning until performance drops. The context starts to feel crowded, and the model has to wade through its own history just to make the next decision. That’s not a small inconvenience. It changes how the agent thinks.
The article calls that drift context rot and describes the spiral as a doom loop: worse context leads to worse decisions, which adds more noise, which makes the context worse again. Once that starts, the agent can spend more energy recovering from itself than actually solving the task.
- Compaction: summarize when the conversation gets long, then continue from the summary.
- Offloading: push huge outputs to a file and keep only the slice you need.
- Sub-agents: hand messy subtasks to separate agents and return only the clean result.
The tool rules that prevent duplicate records and useless errors
A loop is only as good as the tools inside it, and too many tools make selection worse. This is one of those things that sounds obvious until you actually build it. Then you realize that adding more options can make the agent less reliable, not more capable.
The article points to Anthropic’s rule of thumb: if a human engineer can’t say which tool fits, the agent probably can’t either. That’s a very practical filter. It also calls out idempotent tool calls for agents, especially for write actions like “create customer,” where a retry should not create duplicate records or double billing. In other words, a retry should be safe, not catastrophic.
| Tool rule | Why it matters | Example from the article |
|---|---|---|
| Keep tools few and focused | Too many overlapping options confuse the agent | A hundred tools makes selection harder, not easier |
| Make writes safe to repeat | Loops retry, so repeat calls must not break state | A retried “create customer” call should not create a second customer |
| Write errors for the agent | Error messages should suggest the next move | An LLM reading the error should know what to do next |
Why every autonomous loop needs something that can say no
The loop’s quiet failure mode is self-approval. That’s the dangerous part because it can look like momentum. The agent keeps moving, keeps producing, and keeps acting like it’s making progress, even when it’s just making confident mistakes.
The article argues that designing the loop is only half the job; the other half is putting in a critic such as a test, a type check, or a real error. That’s the role of an agent verifier in loop design: the worker does not grade its own homework. This is one of those ideas that sounds strict until you’ve seen how useful it is. A system that can’t be challenged will usually drift toward saying yes to itself.
The cleanest fix is to separate the maker from the checker, often by using a different model or a hard test to evaluate the result. That split adds friction, sure, but it’s the right kind of friction. It keeps the agent from confusing motion with correctness.
What to build first if you want to stop prompting and start engineering loops
The practical shift is not “go fully autonomous tomorrow.” That’s usually how teams get into trouble. The smarter move is to build the control system in the right order, and to be honest about what the agent can and can’t be trusted to do yet.
Start with the basic loop, then add a max-iteration cap, a timeout, and a cost ceiling. Define completion with LLM agent completion checks before the run starts. Protect the context, audit the tools, and only then trust a critic inside the loop. That sequence matters because each layer depends on the one below it behaving well enough.
The larger point is simple: the model is becoming a commodity, while the loop around it is where the real engineering lives. That’s a big change, but it’s also a hopeful one. It means you can improve systems by improving structure, not just chasing the newest model release.
- Start with the basic loop and add a max-iteration cap, a timeout, and a cost ceiling right away.
- Define “done” as an automated check before you begin, not a vibe afterward.
- Compact long runs, offload big outputs, and isolate messy subtasks with sub-agents for coding tasks.
- Keep tools few and focused, make writes safe to repeat, and rewrite errors so an agent can act on them.
- Only go fully hands-off once you trust the thing that says no.
FAQ
These are the doubts people usually have after they understand the idea but before they trust it in production.
Q: What is loop engineering for AI agents?
It’s the work of designing the autonomous cycle around the model: how it runs tools, keeps context clean, knows when to stop, and checks whether the task is actually done.
Q: What is the difference between prompt engineering and harness engineering?
Prompt engineering is about the words you give the model. Harness engineering is the code around it that runs tools, tracks state, and handles errors.
Q: How do you stop an AI agent from running forever?
Use max iterations, time limits, budget caps, no-progress detection, and a real completion check so the loop can stop for the right reason.
Q: Why do agents get worse over long runs?
Because context rot builds up: old tool outputs, dead ends, and stale reasoning pile into the context until each new decision gets worse.
Conclusion
The point of loop engineering is not to make a smarter prompt; it is to build a system that can finish work without being micromanaged.
If you can define the goal, the brakes, and the verifier, you stop being the person typing instructions and become the person designing the machine. And that’s really the shift here: from prompting a model to engineering a reliable process around it. In a world where agents are expected to keep going on their own, that difference is everything.
