Premature termination (AI agents)

Premature termination in an AI agent system is a stop that lands while the task’s objectives are still unmet, with whatever the run assembled handed back as a finished result. The exit takes the ordinary success path, so the shortfall reaches the caller wearing a completion label rather than an error. MAST, the multi-agent failure taxonomy presented at NeurIPS 2025, files this as failure mode FM-3.1. The definition it gives is “ending a dialogue, interaction or task before all necessary information has been exchanged or objectives have been met, potentially resulting in incomplete or incorrect outcomes.” An LLM-as-judge pipeline puts it at 6.20% of the failure modes annotated across 1,642 execution traces collected from seven agent frameworks (arXiv v3, October 2025), a set scaled up from the 150 traces human experts annotated by hand at kappa 0.88.

The denominator does real work here. Runs that never terminated at all sit outside the quantity, so a suite that culls its hangs at a timeout and then scores the survivors has quietly changed the population it describes; publishing answer coverage beside the rate keeps that shift visible.

The mode sits in the verification and termination family that our map of multi-agent failure modes ties to containment levers, and its effect there depends on where you are standing. An early stop bounds error propagation inside the system, since the fault gets no further hop to travel, while it maximizes escape at the boundary where a person acts on the result. Reconstructing which agent made the stop call, and on what evidence, is failure attribution work. Treat any completion an agent asserts about its own run as unscored until something outside that run agrees.

How to measure premature termination

Write the completion criterion for every task before the suite runs, and keep it somewhere the agent cannot read. Then sort each terminated run into two piles: the runs whose objectives the criterion certifies as met, and the runs where it finds something outstanding. Premature termination rate is the second pile over every run that terminated. It carries a confidence interval for the same reason any other eval confidence interval is compulsory, and the pass-rate interval calculator will compute one from k of n. Report the trial count beside it, and read it against the other numbers a single pass rate hides.

Isolate the early stops that also claim completion. Those are the expensive ones in production, because nothing downstream questions a result that arrived labeled as done. Instrument at the orchestrator’s stop decision and at the final handoff, recording the criterion’s verdict in one column and the agent’s own claim in the other. When the two disagree on a run that exited green, you have found one, and silent failure and false success covers what to do when they part company across a whole suite.

The rate says nothing about whether the missing work mattered, since a run that stopped one cosmetic step short scores exactly like a run that stopped before the deliverable existed. Pair it with a severity label assigned by hand on a sample.

Premature termination vs a run that will not stop

A run that will not stop keeps going after its objectives are met, or after they have become unreachable: the planner re-plans, the supervisor re-delegates, and the step budget drains into work nobody needed. MAST gives that its own label, FM-1.5, unaware of termination conditions, defined as a “lack of recognition or understanding of the criteria that should trigger the termination of the agents’ interaction”. The same pipeline puts it at 12.4% of that distribution, twice as often as the early stop. Premature termination is the opposite reading of the same missing criterion, where the system asks whether it is done and answers yes too soon.

The two move against each other under most fixes.

Tighten the stop rule with a hard step cap or a sharper completion prompt and some non-stopping runs convert into early ones; loosen it to recover the early stops and you pay in tokens and in runs that never come back. So both rates belong in one table, computed off the same suite, since a change that moves one while the other goes unmeasured has not been shown to help anything. The framework-level detail on stalls, ignored cancellations and timeouts that never fire lives in why agents hang.

Premature termination vs verification failure

Verification failure is a check falling short on work the run actually produced, and MAST splits it in two: no check ran or the check was partial (FM-3.2, 8.20%), or a check ran and returned the wrong verdict (FM-3.3, 9.10%). Premature termination happens earlier, at the moment the run decides there is nothing left to do. The three modes together form the taxonomy’s verification and termination category, 23.5% of everything the pipeline labeled.

The two separate most cleanly on what repairs them. A stronger verifier catches a wrong answer whatever produced it, and it catches a short answer only once task completeness is written into the rubric, which is a separate authoring decision from writing the verifier. The consequences differ too, and they differ in a way that shows up at the boundary. An early stop hands back work that was never done, so what arrives is short by construction and a reader comparing it against the brief can see the gap. A wrong verdict hands back finished work carrying a stamp, and nothing downstream can tell a certified wrong answer from a certified right one. Task verification failure takes the verifier side of this in full.

Star topologies with no fixed workflow produce more early stops

MAST’s per-framework breakdown singles out one benchmark: AppWorld “frequently suffers from premature terminations (FM-3.1), potentially due to its star topology and lack of a predefined workflow making termination conditions less obvious.” When a hub agent improvises the plan, no stage boundary exists to say what finished looks like, so the completion judgement falls back on a model reading its own transcript. A sequential pipeline with named stages at least gives you somewhere to hang an acceptance gate, which is one reason topology choice is a reliability decision.

Is a step budget premature termination?

A step budget, a cost ceiling and a deadline cutoff are deliberate stops, modeled on early stopping in machine learning, where halting a training run once a held-out metric stops improving is the whole technique. Agent systems inherit that shape honestly, and a bounded run is good engineering. The deliberate stop and the failure differ in the exit contract they return: a cutoff that returns “incomplete, budget exhausted” with the partial state marked as partial belongs with graceful degradation, while the same cutoff returning a completion claim is FM-3.1. Log the stop reason as a first-class field, because your eval cannot tell those apart otherwise.

The phrase carries far heavier traffic in contract law and clinical research, where it names an agreement ended before term and a participant who left a study early. Both readings are established, and this lane qualifies the term for that reason: every use on this page refers to an agent run.

A calibrated stop rule shows up as two numbers held together, since either one on its own is easy to move by breaking the other. Where the early stop sits among MAST’s other thirteen failure modes, and which containment lever bounds each of them, is worked through in multi-agent LLM failure modes and how to contain error propagation. Not every neighboring mode has a term page of its own; the terms this lane maintains are the ones that do. A stop rule nobody wrote down is still a stop rule.