Agent verification: when the loop should stop
An agent is a version of an AI assistant that does not just reply: it takes actions, usually by calling tools - a search, a calendar, a payment - reading each result, and deciding what to do next. My first one had no good way to stop. I asked it to plan a trip as a series of tool calls, hit run, and it kept going: it checked availability, checked availability again, then asked a clarifying question nobody was around to answer. Nothing crashed. The run just billowed until I killed it. That afternoon was the shape of the whole subject. The loop itself is easy code - ask the model for its next action, run the tool, add the result to the conversation, repeat - and the hard part is the line that decides whether to repeat. There are really three ways a loop ends. The model says it is done, a cap ends it, or a check on the work itself says it is finished. Those three disagree constantly, and the interesting failures live in the disagreements. A model that stops while the work is unfinished ships a quietly wrong result. A cap that fires on a run that was about to succeed throws away real progress. And when no check exists, the only judge left is the thing being judged, which is the most comfortable and least trustworthy arrangement in the whole stack.
Most people have this backwards
The expensive agent failure is not the run that never stops. It is the run that stops early and reports success.
The catch
It holds whenever the loop already has hard caps around it - turn limits, dollar ceilings, timeouts - because a runaway hits its ceiling and announces itself in the spend, while a premature stop simply marks unfinished work complete, and nothing downstream of a confident artifact goes looking for the bug. The claim breaks when there are no caps at all: then the runaway is genuinely unbounded, and it becomes the failure that wakes people at night.
Baseline first - what is your honest read?
An agent burns its entire budget re-calling one tool that returns the same result every time, and the team wants to ship a maximum-turn cap as the fix. What is wrong with that?
Make each call, then see the verdict
Predict first
An agent has a maximum-turn cap of 40 while a typical successful run takes 6 turns. You raise the cap to 80. What happens to the cost of a typical successful run?
Four agent builds, four stop conditions. Pick the terminal condition each loop should run on.
An agent rewrites SQL for an analytics request. The warehouse executes any query the agent produces, and the harness can diff the returned row counts against the counts the request stated.
An agent compiles a research brief on an open-ended question. Nothing about a finished brief checks mechanically, and the brief lands with a human analyst either way.
A support agent answers in one turn, occasionally calling a refund-status tool first. A wrong answer annoys a user; nothing worse happens.
An agent repairs a failing test suite, where the suite is the spec. It is flaky at about 5 percent, so a red rerun does not always mean the fix failed.
How it works
The loop is small, and it has one exit. The harness - the ordinary code that runs this loop around the model - walks the same three steps every time. Ask: the model reads the transcript of results so far and emits either a tool call or a completion signal. Run: the harness executes the call, or takes the completion at face value. Append and check: the new result joins the transcript, and the stop condition gets its turn. What I did not see at first is that each state has its own failure. Ask can repeat a call whose result will never change, because the transcript looks unfulfilled no matter how many times the same answer re-enters it. Run can misfire quietly: a tool returns a fallback default on bad arguments, and the transcript records the default as if it were real data. The check state is the one teams skip, and skipping it is what makes the model the final judge of its own work. Cost compounds through the loop too, because the transcript re-enters the prompt on every turn, so later turns are more expensive than early ones even for identical effort. That is why the stop condition is an economics question and not only a correctness one: every extra turn pays the growing transcript rate.
The dissertation defense
I picture the loop ending the way a dissertation defense does. A student writes the thesis alone for months and believes it completely by the end, which is exactly why nobody lets the student grade it. The defense exists because the work needs an external check: an examiner with independent context asks, the student answers, and only a pass ends the process. The schedule protects the other direction - a defense has a date and a scope, so it cannot stretch forever - and when the examiners find gaps, the verdict is not try-again-alone but a list of revisions, which is the loop being handed useful state instead of a shrug.
Where it breaks
The analogy breaks at how often the check can run. An examiner reads a finished document once, at the end; an agent harness can run a verifier after every single turn, which changes the economics completely. Cheap per-turn checks make short loops better than long ones, because catching a wrong turn at turn two costs a fraction of catching it at the defense. A once-and-final model of verification quietly argues for the wrong architecture in a system that can re-check for the price of one tool call.
Why interviewers lean on it
Termination is where agents stop being a chat demo and start being an engineering liability, which is why interviews press on it. The question has a cost half and a correctness half, and candidates usually answer only one. What does a stuck loop spend while it re-reads its own results? What does an early stop cost the business that received the unfinished work? Which failures deserve a retry, and which retry just re-commits the identical mistake at full price? The sharpest version: how do you check the work when nothing about it runs, when the deliverable is prose and there is no test to execute? A candidate who has run these loops answers from the saved record - the repeated call, the tool that quietly returned a made-up default, the turn where the conversation stopped changing - and a candidate who has not talks about prompt phrasing. The cap-versus-check distinction is also the fastest architecture divider: caps are guardrails, checks are the stop condition, and shipping one while calling it the other is a design error an experienced interviewer hears within a minute.
The follow-up chain
Interviewers do not stop at the surface answer. Answer the way you would out loud, or skip - skipping reveals the strong answer and ends the chain.
The interviewer's next question
Your agent keeps calling the same tool with the same arguments. What broke, and what do you change?
Now answer one you have not seen
A teammate ships a code-repair agent whose loop ends when the model writes a DONE marker into the transcript. It works on the easy cases and quietly ships broken repairs on the hard ones. You have one review with the team. What do you bring, and what do you propose replacing the DONE marker with?
Expires fast - as of 2026-10-05
In 2026 agent harnesses, the model completion signal remains the default terminal, and writeups of runaway agent runs consistently describe the same mechanism this concept opens with: a transcript that looked unfulfilled to the model no matter how many times the same tool returned.
As of 2026-10, turn caps and spend ceilings are table stakes in publicly documented agent harnesses, while artifact-level verification tiers - execute-and-diff where possible, provenance and motion invariants elsewhere - remain the less common and more expensive half of the design.
The retryable-versus-permanent vocabulary (timeouts and rate limits versus bad auth and invalid arguments) is standard harness practice as of 2026-10; how many retries a transient failure deserves has no canonical default and remains a product decision.
Termination and verification surfaced in the 2026 postings mined for this track under agent-reliability wording - stopping conditions, retry policy, runaway spend - rather than as a standalone named interview round.