Ask an AI agent a hard question and watch what happens to time. A minute passes. The screen says it is thinking. Nothing arrives. Is it building your answer, or has it wandered off somewhere inside itself, spending your money as it goes?
You cannot run a company on software whose working state is indistinguishable from its broken state. The first thing to know about any agent, before what it can do, is what forces it to stop. In the Cabinet, ArkOne’s reference design for an executive agent, that force has a shape you can say aloud: the Chair speaks at most fifteen times, and then the meeting ends.
What the loop is
Strip the mystery out and an agent is a meeting that runs in rounds. Each round, the Chair, the one voice that speaks for the whole room, does exactly one of two things. It asks for something: a specialist’s view, a document from the Library, a search. Or it answers you, and the meeting is over.
That is the whole machine. A question that needs nothing extra is answered in one round. A question that needs the contract read and Finance consulted takes a few. The loop is what lets an agent do real work instead of guessing; every round is a chance to fetch the thing the answer actually needs.
The danger is the same as the power. A round can raise a new question, which takes another round, which raises another. Left alone, a loop is a machine for continuing. So a well-built design bolts two rules onto it, and both live in code rather than in the model’s good intentions. The first is the stop condition: the meeting ends the first time the Chair answers without asking for anything more. The second is the cap: whatever is still unresolved, the meeting may not go past a fixed number of rounds. The reference design sets that dial at fifteen, and records it, with every other setting, on the Register.
You could instead instruct a model to be brief, and it would usually obey, the way a talkative colleague usually obeys a pointed look. A cap in code is different. When round fifteen arrives, there is no round sixteen, whatever the model would have preferred.
One meeting, traced
Suppose a client emails asking to renew at last year’s price, the worked example that runs through this whole programme, with the company and its numbers invented. Watch the rounds.
| Round | The Chair asks for | What comes back |
|---|---|---|
| First | The client’s contract and last year’s pricing, from the Library | Two documents, nothing else |
| Second | Finance’s view of the margin | A floor price, with the reasoning |
| Third | Marketing and Operations, consulted in parallel | Marketing: the client has been a reference twice this year. Operations: delivery on this account costs more since the route change |
| Fourth | Nothing. The Chair answers: hold the list price, offer the volume tier | The meeting ends |
Four rounds of a possible fifteen, ended by the stop condition rather than the cap. That is what a healthy meeting looks like: the ceiling exists and is rarely touched, the way a lift’s weight limit exists and is rarely tested.
Now suppose the unhealthy version, the one the cap exists for. A specialist’s reply mentions a second contract. Reading it raises a question about a third. Somewhere in the room a thread refuses to end, and without a ceiling the meeting simply continues, each round billed, no answer in sight. With the ceiling, the worst case has a known number of rounds before you ever ask the question. That is not yet a bill: what one round costs depends on how many specialists it consults and how much the Chair has to re-read, which the fifth paper and the ninth take up. But a meeting that must end is a meeting you can price; a meeting that need not end is one you find out about on the invoice.
Fifteen is the cap on the Register, not a target. Press run and count them.
A meeting has not been run yet. Press run to watch one count, fan out to the specialists, come back, and stop.
What this arms you to ask
When someone sells you an agent, ask how many times it can go around before it must answer you.
A good answer names a number, says where it is set, and can show you a run that hit it. Two thinner answers come back often enough to name: that the model knows when to stop, and that the limit is configurable. Both may be true, and neither answers you. Ask what enforces the limit when the model would rather continue, and whether that thing is a line of code or a line in the prompt. You are asking whether the safety rail is welded or painted on.
The dial itself is a judgement you are entitled to see argued. Set it too low and hard questions come back shallow, answered before the room could gather what it needed. Set it too high and you have bought slower answers and larger bills for no gain anyone measured. Fifteen is where this reference design places it; the point is less the number than the fact that it is a number, written down, owned by someone, and changeable without asking a vendor’s permission.
Everything else an agent does happens inside that boundary, which is why this paper comes first, and why the second asks who does the speaking.
Next paper: One voice: why your company never hears the specialists.
Asked plainly
Why do AI agents need an iteration cap?
An agent works in rounds, and each round costs money and time. Without a cap in code, a hard question can keep the loop turning indefinitely, which means an unbounded bill and an answer that never arrives. The cap turns the worst case into a known, budgeted quantity.
What happens when an AI agent reaches its cap?
In the reference design the agent must answer with whatever it has, and the run is marked as having hit the ceiling. The cap ends the meeting; it does not crash it.
How does an AI agent know when to stop?
It does not know; it is stopped. The meeting ends the first time the agent answers without asking for anything more, or at the capped round, whichever comes first. Both rules live in the surrounding code, not in the model's judgement.
Ask the vendor
The questions this part arms, each with the good answer and the answer that arrives instead.