Loop engineering: when an agent should stop
An agent is a loop. The model looks at the situation, picks an action, sees the result and goes again.
Most teams spend their time on the prompt and let the loop design itself. Then, in production, the failures are loop failures: an agent that never stops, one that stops too early, one that keeps calling the same broken tool with slightly different arguments, or one whose context has grown so large it forgets what it was asked.
I call the work of designing this loop engineering. It comes down to four decisions, which I write down before the first real run.
Hand-drawn agent loop with labels for done condition checked by code, turn cap, error policy per tool and state carried forward
1. The done condition
How does the system know the task is finished?
The weakest answer is "the model says it is done". Models are agreeable and will often declare success early. Wherever possible, the done condition is checked by code: a required field is filled, a test passes, a document exists with the right sections, a record matches a schema.
When the task is open ended, such as research or drafting, I still define a checkable minimum: the sections that must exist, the sources that must be cited, the questions that must be answered.
2. The turn cap
How many steps does the agent get before it stops and hands over to a person?
I do not guess this number. I run the agent on a set of real tasks without a cap, log how many steps each successful run took, and set the cap a little above where successful runs end. Runs that go past that point almost never succeed. They loop.
When the cap is hit, the agent does not fail silently. It writes a short summary of what it tried and where it got stuck, and passes that to a human. A good handoff at the cap is worth more than a few extra turns.
3. The error policy
What happens when a tool call fails?
There is no single answer. A search that returns nothing might be retried with a different query. A timeout on a slow system might be retried once after a pause. A permission error should never be retried, it should stop and escalate. A failed write should stop immediately.
So the error policy is per tool: retry, try another way, or stop and escalate, with a retry limit for each. "Retry forever" is how a loop burns a budget overnight.
Errors also need to be readable by the model. "Invoice not found, check the format INV-123456" lets the agent correct itself. A stack trace does not.
4. State
What carries from one step to the next?
The default in many frameworks is to carry everything: every tool result, every thought, every message. It works in a demo. On long tasks it makes the context noisy, raises the cost of every call, and makes the agent more likely to repeat earlier mistakes it can still see.
I decide explicitly what state carries forward. Usually: the task, decisions made, open questions, and a compact summary of results so far. Raw tool output is summarised or dropped once it has been used.
Design the exit first
If I had to keep one rule, it would be this: design how the loop ends before you design how it runs. The done condition, the cap and the escalation path are what make an agent safe to leave alone. Everything else is tuning.
These four decisions also connect to what the agent is allowed to do at each step. An agent that hits an amber action should pause, which I covered in designing the pause. The wider frame around the model is in harness engineering.
How to test the loop
Three tests I run before go live:
- The stuck test. Break a tool on purpose. Does the agent stop and escalate within the cap, with a useful summary?
- The early stop test. Give a task with a missing piece of information. Does the agent ask, or does it declare success?
- The long task test. Give the longest real task you have. Does the cost stay reasonable, and does the agent still remember the original instruction at the end?
If an agent passes these three, I trust it far more than one that passes a hundred easy demo questions.
We build and test agent loops this way in the AIXL Academy Forward-Deployed AI Engineering cohort. Details are on the AIXL Academy page.
Common questions
What is loop engineering?
Designing how an agent loop starts, continues and stops: the done condition, turn cap, error policy and the state carried between steps.
How do you choose a turn cap?
Run the agent on real tasks without a cap, look at how many steps successful runs take, and set the cap slightly above that.
Who should decide that an agent task is done?
Code, wherever possible. A filled field, a passing test or a produced document, not the model saying it has finished.
Why does agent state matter?
Carrying everything forward makes the context noisy, raises cost and makes the agent more likely to repeat old mistakes.