Termination

In one line: the agent cannot tell you it is stuck, because from inside the loop every step looks like the next sensible thing to try.

Why the model cannot do this

Ask the model whether it is making progress and it will say yes, because it generated the step and its justification in the same breath. Self-assessment inside the loop is the least reliable signal available — it is the component under evaluation grading itself, with no external reference.

So progress detection is mechanical. It compares states rather than asking for an opinion.

Three shapes of stuck

Each needs a different detector.

Exact repetition. Same tool, same arguments. The published guidance is direct about this one: fingerprint the call — tool name plus normalised arguments — and if the same fingerprint appears two or three times, stop or force a strategy change. Fingerprinting is more precise than an iteration cap, which fires on any repeated tool type rather than on identical calls, so it triggers on legitimate behaviour like reading several files.

Cycling. A short sequence repeating — search, read, search with a trivially different query, read again. No single fingerprint repeats. Detect it by hashing the recent sequence of fingerprints and looking for the same window twice, or by noticing that the set of distinct states visited has stopped growing.

Plausible drift. Every step is different and reasonable, and nothing moves toward the goal. This is the hardest and the most expensive. There is no clean mechanical signal, and the practical answer is a state-change check: has anything in the world actually changed in the last N steps? An agent that has taken six steps and written nothing, retrieved nothing new, and answered nothing is drifting even if each step differed.

What to do when it fires

Stopping is not the only option, and the ladder matters.

Force a strategy change. Tell the model explicitly that the current approach is not working and it may not repeat it. Sometimes enough, and it costs one more step.

Re-plan from the goal. Discard the current plan, restate the goal and the current state, and ask for a different approach. More expensive and it clears accumulated confusion.

Ask the user. Often the correct answer for a personal assistant, and the one designs under-use. "I've tried to find the booking reference in your email and can't — do you have it?" is a good outcome, not a failure.

Stop and report. Budget exhausted. Report where it got to and what it would try next.

The ordering matters: escalate through them rather than jumping to stop, because a single nudge resolves a meaningful share of stuck loops.

Budgets, and what they are for

Three, and each catches something the others miss.

Steps bound the iteration count. Crude, necessary, and the number depends on the task — a lookup should never take ten steps, while a research task might legitimately take thirty. So the cap is per task class, not global.

Cost is the one that protects the business, because steps vary in size by orders of magnitude. A step cap does not bound spend.

Wall clock is the user-facing one. A user waiting ninety seconds needs an answer or an update, whichever comes first.

The important design point: exceeding a budget is a result, not an error. The agent should report where it got, what it learned, what it would do next, and what it needs. An agent that goes quiet at the budget is far worse than one that reports partial progress — and partial progress is often genuinely useful.

Success detection

The other half, and it is nearly as hard.

Knowing the task is done is a judgement the model is also poor at, in the opposite direction: it will declare success on a plausible-looking outcome that does not satisfy the goal.

Two mitigations that do not rely on the model's opinion.

Verify against the world. After booking, read the calendar back. After sending, confirm it appears in sent items. A check against actual state is worth far more than the model's assertion, and it is one extra cheap tool call.

State success criteria in the plan. If the plan says "the meeting appears on both calendars at the new time", that is checkable. A plan whose steps have no success criteria produces a loop with no way to know it finished.

The failure to design for explicitly

Worth stating because it is the one that reaches users.

The agent takes eleven steps, exhausts its budget, and reports failure — having along the way sent an email, created a calendar hold and cancelled something. Partial completion of a multi-step task leaves the world in a state nobody chose.

Three responses, in order of preference.

Order the plan so writes come last. Do all the reading and deciding first, then act. A failure before the write phase leaves nothing to unwind.

Make writes reversible. A cancellable hold, an outbox with a delay, a soft delete. Then a failed task can be rolled back cleanly.

Report what was done, precisely. If neither is possible, the report must enumerate every action taken so the user can undo what they want to. "I couldn't complete this" without that list is the worst possible outcome, because the user now has to discover the changes themselves.

Next: memory, and what is worth keeping.