- An agent loop does not replace a prompt. It wraps one, then calls it repeatedly with new evidence until a stop condition fires.
- Four things change when you wrap a prompt in a loop: state becomes yours to manage, tools become part of the interface, the stop criterion becomes code you write, and cost stops being predictable per call.
- The technique is older than the hype. The ReAct paper interleaved reasoning with actions in October 2022 and reported a 34 point absolute gain on ALFWorld.
- Prompt engineering matters more inside a loop, not less, because tool descriptions are prompts and the model reads them on every single turn. If you want a concrete server to point a loop at, our MCP server exposes commerce projects as tools.
- Anthropic's own guidance says agentic systems trade latency and cost for task performance, which means a loop is the wrong default for anything you can express as a fixed path.
- Most production failures in loops are stop-condition failures, not reasoning failures.
You have a prompt library that works. Ten or twenty templates, tuned over months, each one reliable enough that you stopped thinking about it. Then a colleague tells you prompting is finished and everything is agents now, or that a generator will write your prompts for you, and your first honest reaction is that this sounds like the last four things that were going to change everything.
The claim is half right in a way that matters. Nothing about your prompts became wrong, and the patterns that make a prompt work apply inside a loop exactly as they did outside one. What changed is the wrapper around them, and the wrapper introduces four responsibilities that a single call never had. If you understand those four, you can decide case by case rather than migrating on faith.
What is an agent loop, exactly?
It is a while loop with a language model inside it. That is not a simplification for beginners, it is the actual shape.
You send a prompt. The model responds with either an answer or a request to use a tool. If it asked for a tool, your code runs the tool, appends the result to the conversation, and sends the whole thing back. Repeat until the model produces an answer or your code decides to stop. Anthropic's engineering write-up on building effective AI agents draws the line precisely: a workflow is one where models and tools move through predefined code paths, while an agent is one where the model directs its own process and decides how to accomplish the task.
The distinction is not academic. In a workflow you decided the sequence in advance. In a loop the model decides, which is why the loop can solve problems whose step count you could not have predicted, and also why it can spend forty turns doing something you would have done in two. Deciding what the surrounding code owns once that happens is the subject of our piece on what an AI orchestration layer has to take responsibility for.
What does the loop actually change?
Four things, and only four. Everything else in your existing practice survives intact.
| Concern | Single prompt | Agent loop |
|---|---|---|
| State | Lives in the one message you send. You control it completely because you wrote it. | Accumulates every turn from tool results you did not author. Grows without you deciding it should. |
| Tools | Optional. If present, usually one call, result handled by your code. | Part of the interface. The model reads every description on every turn and picks among them. |
| Stop criterion | Implicit. The response arrives and you are done. | Explicit code you must write. Turn caps, token ceilings, repeated-action detection, success checks. |
| Cost per task | Roughly the prompt plus the answer. Predictable enough to budget. | Unbounded until you bound it. Every turn resends the accumulated history. |
| Failure mode | A wrong answer you can read. | A plausible answer built on a tool result that failed silently eight turns ago. |
| Debugging | Read the prompt, read the output, adjust. | Replay a trajectory. The interesting turn is rarely the last one. |
Read that table as a bill rather than a feature list. Each row is work you now own that you did not own before. A loop is worth it when the problem genuinely cannot be laid out in advance, and it is a tax when the problem could.
Where did the loop come from?
Not from a product launch. The pattern was published as research years before anyone sold it, and the dates are worth knowing because they tell you how much of the current noise is genuinely new.
- 6 October 2022. Shunyu Yao and co-authors post ReAct: Synergizing Reasoning and Acting in Language Models. The method interleaves reasoning traces with actions so the model can query an external source, read the result, and revise its plan. On ALFWorld it beats the baselines by 34 points of absolute success rate, on WebShop by 10, using one or two in-context examples. This is the loop, described in full, in 2022.
- 25 November 2024. Anthropic publishes the Model Context Protocol as an open standard for connecting assistants to external systems. The significance is not the protocol itself but what it standardises: the tool half of the loop stops being bespoke per integration.
- 25 November 2025. The November 2025 specification release ships task-based workflows with explicit states covering working, input required, completed, failed and cancelled, plus SEP-1577, which adds tool calling to sampling so a server can run its own agentic loop. The loop becomes a first-class protocol concept rather than something each client improvises.
- 9 December 2025. Anthropic donates MCP to the Linux Foundation under the new Agentic AI Foundation, co-founded with Block and OpenAI. The post cites over 10,000 active public MCP servers and 97 million monthly SDK downloads across Python and TypeScript.
Three years separate the research from the infrastructure. What arrived recently is not the idea of looping a model over tools. It is the plumbing that made it cheap enough to do casually, which is a different and much more consequential thing.
Does prompt engineering still matter inside a loop?
More than before, and in a place most teams overlook. The prompt you spent months tuning gets sent once per task. The tool descriptions get sent on every single turn, and they are the text the model uses to decide what to do next.
Anthropic's guidance on writing tools for agents is blunt about this: tool definitions deserve as much prompt engineering attention as the main prompt, and small refinements to descriptions produce outsized changes in behaviour. The company attributes a state of the art SWE-bench Verified result to exactly that kind of tuning, which is the same benchmark we broke down in our explainer on what SWE-bench Verified actually measures.
So the skill transfers. You are still writing instructions for a model that reads text literally and rewards specificity. The surface moved from one long template to a set of short tool descriptions, an operating instruction about when to stop, and a system prompt that has to survive twenty turns of context growth without being forgotten, which is the allocation problem set out in treating the context window as a token budget.
If you have never written a tool description for a model to read, the practical starting point is standing up a server yourself. Our walkthrough of setting up an MCP server covers the primitives, and our explainer on how MCP connects an assistant to your systems covers why the protocol exists at all.
What does a stop criterion actually look like?
This is where homegrown loops break, and it is the part nobody demos.
A naive loop stops when the model stops asking for tools. That works until the model gets stuck in a pattern: call search, read nothing useful, call search again with a near-identical query, forever. It never emits a final answer, so it never terminates, and your bill grows on a curve.
A usable stop criterion is several conditions in a disjunction, and each one should be there because you saw the failure it prevents.
- Turn cap. The blunt one. Pick a number from your traces, not from intuition, then log every task that hits it because those are your real failures.
- Token ceiling. Independent of turns, because one tool that returns a large payload can blow the budget in a single step.
- Repeat detection. If the same tool is called with arguments you have already seen, the loop has stopped making progress. Break, and say so in the result.
- Success check. Something outside the model that can verify the goal. Tests pass, the row exists, the file compiles. Without one you are trusting the model's own claim that it finished.
- No-progress timeout. Wall clock, for tools that hang rather than fail.
The success check is the one that separates a loop you can run unattended from one that needs a human watching. It is also the hardest to write, because for many tasks there is no cheap oracle. When there is no oracle, you do not have an autonomous agent. You have a fast draft generator with a review step, which is a perfectly good thing to build as long as you name it correctly.
Why does cost per task rise so fast?
Because a loop resends. Every turn ships the entire accumulated conversation back to the model: your system prompt, the tool definitions, every prior message, every tool result. A ten-turn task does not cost ten times a single call. It costs closer to the sum of a growing series, because turn eight carries everything from turns one through seven.
Anthropic's own framing is that agentic systems trade latency and cost for better task performance, and its writing on context engineering for AI agents treats the context window as a finite budget with diminishing returns rather than a free container. The same post describes context rot: as the token count climbs, the model's ability to recall accurately from that context degrades, a consequence of attention scaling with the square of sequence length.
That gives you the uncomfortable pairing. Long loops cost more per turn and get worse per turn. The mitigations Anthropic describes are compaction, where a conversation nearing its limit is summarised and restarted from the condensed version, and clearing raw tool outputs once they have been referenced. Both are things your code does, not things the model does for you.
Do more agents fix a long loop?
Sometimes, and for a reason that is about context rather than intelligence. If one loop degrades because its history grew too long, splitting the work across several agents that each keep a short history can genuinely help. Anthropic's context engineering post describes the pattern: specialised sub-agents handle a focused piece and return a condensed summary, typically one to two thousand tokens, to the parent that coordinates them.
What that buys you is context isolation. The parent never sees the twenty tool results the child waded through, only the conclusion. What it costs you is a second copy of every problem in the table above, because each sub-agent is a loop with its own state, its own stop condition and its own bill. Plenty of teams reach for multiple agents when they should be reaching for a shorter single loop, and the tell is that nobody can state what each agent's success check is.
The cheaper move, when a loop runs long, is usually one of two techniques from the same post. Compaction summarises the conversation as it approaches the window limit and restarts from the condensed version, keeping architectural decisions and unresolved bugs while dropping redundant tool output. Tool result clearing is the lighter variant: once a raw payload has been referenced further down the history, drop the payload and keep the reference. Both are a few dozen lines inside your loop and neither requires a second model.
There is also a protocol answer emerging. The November 2025 MCP release added task-based workflows with explicit states for working, input required, completed, failed and cancelled. That matters because it moves the question of whether a long-running job is finished out of your loop's guesswork and into a state machine the server owns. A tool that can say it is still working is a tool your stop condition can reason about.
When is a loop the wrong tool?
Whenever you can write the steps down. If the sequence is knowable, encoding it in code gives you a cheaper, faster and far more debuggable system than asking a model to rediscover it on every run.
Anthropic's post lists five patterns that sit between a single call and a full agent: prompt chaining, routing, parallelisation, orchestrator with workers, and evaluator with optimiser. Four of the five are ordinary software with model calls inside them. Most of what gets described as an agent in a product announcement is one of these, and that is not a criticism. It is usually the correct choice.
The honest test is whether you can predict the number of steps. If you can, you want a workflow. If you genuinely cannot, and you have a way to verify the result, and you accept the cost, you want a loop. Note that the second condition does more work than the first: an unpredictable task with no verification method is not a good agent candidate, it is a research project.
What happens to your existing prompt library?
Almost all of it survives, reclassified rather than discarded. The migration is less dramatic than the discourse suggests.
Templates that transform text stay exactly as they are. Summarise, rewrite, extract, classify: single call, no loop, no benefit from one. Templates where you were manually feeding the output back in and running the prompt again are already loops, badly implemented, and those are your first candidates. Templates where you pasted in data you had fetched by hand become tool definitions, which is where you will spend your rewriting effort.
The one genuinely new artefact is the operating instruction: the paragraph telling the model how to behave across turns rather than what to produce in one. When to ask for help. When to stop. What counts as finished. That paragraph has no equivalent in your old library, and it is the piece most teams write last and should write first.
A useful sanity check before building a loop: write down the stop condition first, in code, before writing any prompt. If you cannot express it without hand-waving, the task is not ready to be automated, and no amount of prompt tuning will fix that.
What to take from this
Prompting did not end. It got a wrapper with a bill attached, and the bill is paid in state management, tool authorship, termination logic and tokens. The reasoning itself, the part everyone talks about, is the piece that changed least. ReAct described it in 2022 and the mechanism has not moved much since.
The practical posture is to stay boring. Use a single call where a single call works. Use a fixed workflow where the steps are known. Reach for a loop where the step count is genuinely unknowable and you have something outside the model that can tell you when it is done. When you do reach for one, spend your first hour on the stop condition and your second on the tool descriptions, because those two files determine whether the thing is useful or merely expensive.
Anyone measuring whether the loop is worth it should also read how these systems are scored, since the gap between a benchmark number and a working agent is where most of the disappointment lives. Our look at how agent benchmarks bend with compute budget is a reasonable next stop, as is our piece on what happens when a model games the rules it was given, which is the failure mode a weak success check invites.