An agent loop: a goal, a tool set, carried state and a stopping rule
In short
An agent loop has 4 mechanical parts: a goal something other than the model can judge satisfied, a tool set the model chooses from at runtime, state carried from one iteration to the next, and a stopping rule that fires with nobody watching. Remove one and what you have is a pipeline with a model in it.
Key takeaways
- 4 parts define a loop: judgeable goal, runtime tool choice, carried state, stopping rule.
- If the tool order appears in your architecture diagram, the author chose it — this is a pipeline.
- A goal only the model can judge is not a goal. Something outside it must be able to check.
- Carried state makes iteration 3 different from iteration 1. Without it you have a retry.
- Give every loop a step cap, a wall-clock deadline, a spend ceiling and a no-progress halt.
An agent loop repeats a decide-act-observe cycle until a condition is met. Mechanically it needs 4 things: a goal that can be judged satisfied by something other than the model's own opinion, a set of tools the model selects from at runtime, state carried from one iteration into the next, and an explicit stopping rule. All 4, or it is something else.
The reason to be pedantic is commercial. Loops cost more to build, run and debug than fixed sequences, and many systems described as agentic in a proposal are chained scripts with a fashionable label. Checking the 4 parts against a spec takes minutes and occasionally saves a quarter.
A goal something other than the model can judge satisfied
The loop must be able to ask "am I done?" and get an answer it did not invent. "Produce a good summary" fails: the only judge available is the thing being judged. "Every invoice line in this document appears in the accounting system with a matching total" passes, because a query settles it.
Most specifications skip this, and skipping it is why loops run long. A goal nobody can evaluate cannot terminate a loop, so termination falls back to a step limit, which is a timeout in costume. The judge belongs outside the model, in the deterministic core of an AI feature.
Tools chosen at runtime, not written into the sequence
The model must select which tool to call, from a set that exists before the run. If the order of calls is drawn in your architecture diagram, the author chose it and the model is filling slots in somebody else's sequence. That is a chain, and a perfectly good thing to be — defined in prompt chaining as a design primitive.
Runtime choice also makes each tool's advertised contract load-bearing rather than documentation: a tool picked wrongly is an interface problem, not a prompt problem. See the tool contract for an agent.
State that makes iteration 3 different from iteration 1
Something must persist between turns: what was tried, what came back, what remains outstanding. Without it the loop rediscovers the same dead end and you have built an expensive retry. With it comes a second question — where that state lives, and whether a run resumes after a crash.
The answer converges on a durable, enumerable representation rather than a growing transcript, which is why so many working systems end up inside the state machine behind a reliable AI feature. Piling it into context instead has its own failure curve: why more context makes an agent worse.
The stopping rule, which is the part that gets left out
A loop needs a condition that halts it without a person noticing something is wrong. Most designs have one by accident — a rate limit, a bill, a support ticket — which is why a 2-step job takes 11 steps, traced in when an agent takes 10 steps for a 2-step job.
One trap deserves naming. A loop treating a tool's success response as proof the work happened stops satisfied while the record it was meant to write is missing — the failure in sync says success but records are missing. Verify the effect, not the acknowledgement.
Two lines to run against your own spec
Can the number and order of steps be known before the run starts? Is there a check outside the model that says the work is finished? Yes to the first means you do not need a loop; no to the second means you cannot safely run one yet.
| Missing part | What the system becomes | The tell in the spec |
|---|---|---|
| Judgeable goal | A generator. Somebody downstream decides if it was any good. | Success reads "a good summary", with no checkable condition. |
| Runtime tool choice | A pipeline. The author picked the steps; the model fills them. | The order of tool calls is in the architecture diagram. |
| Carried state | A retry. Iteration 3 knows nothing iteration 1 learned. | Nothing says where intermediate results live. |
| Stopping rule | An open-ended process, halting on a timeout, a bill or a person. | No step cap, no budget, no definition of done. |
If the order of the steps is in your diagram, the author chose it. That is a pipeline, and it will be easier to operate than whatever replaces it.
Whether a loop is the right shape at all is argued in agent loop or fixed pipeline; the step arithmetic sits in chained step reliability. Building and operating one is what we do under AI agents and automation, with the habits in AI agents in production. This belongs to choosing the shape of the system, part of the engineering library.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is an agent loop?
A system that repeats a decide-act-observe cycle until a stopping condition fires. It needs a goal something other than the model can judge satisfied, a tool set the model selects from at runtime, state carried between iterations, and an explicit halting rule. Missing any one, it is a different shape with a different cost.
What is the difference between an AI agent and a script that calls a model?
Who chooses the next step. In a script the author fixed the sequence and the model fills in content; in an agent the model picks the next tool at runtime. Both can be excellent. Only one has an unknown number of steps, which is what makes it harder to test, price and operate.
Does an agent loop need memory?
It needs carried state, which is narrower than memory. State is what this run has tried and learned; without it each iteration repeats the last. Memory across sessions is a different feature, and usually a request for a record that already exists somewhere queryable.
How do you stop an agent loop running forever?
Give it 4 limits: a maximum iteration count, a wall-clock deadline, a spend ceiling, and a halt when the last 2 iterations produced no new information. The last matters most, because a stuck loop is rarely idle — it keeps issuing plausible calls that change nothing.
- agents
- system design
- definitions
- architecture
The work behind this page
Builds from our portfolio that this page draws on.
Captcha-Resilient ATS Agent
AI-powered job application automation platform that auto-applies across Lever, Greenhouse, and Workday with a 5-tier CAPTCHA bypass stack.
HR & RecruitingInbox Zero
AI email triage that gets you to inbox zero by lunch — smart lanes, drafted replies, and a daily debrief.
Productivity AIRead next
- Prompt chaining, defined: the primitive between one call and a loopThe author fixed the path. That one property separates a chain from a state machine, which branches, and from an agent loop, which chooses its own next move.definition
- "Dedicated team" defined by what it does not promiseThe phrase commits a supplier to almost nothing on its own. What it usually means in practice, and the three artefacts that turn it into something you can verify.definition
- A freshness SLA is a promise about the worst case, not the averageFreshness is the age of the data behind an answer when it is served, held under a stated ceiling. Latency is how fast a run finishes, and the two can disagree by a week.definition
- A subset of the PDFs came through as gibberish and nobody lookedA chunk of mojibake embeds happily, indexes happily and retrieves for nothing. No stage errors, so the only defence is a screen that reads the text before it is indexed.diagnostic
- Adding one new source made unrelated answers worseNothing about the old passages changed. A new source ranks moderately well on a great many queries, and a fixed top-k has to give it those slots by taking them from something else.diagnostic
- An upstream field changed and the pipeline carried on regardlessA renamed source field does not raise an error. It returns nothing, coalesces to an empty string, and quietly hollows out every record ingested since — until someone plots completeness by day.diagnostic
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation