Premature Termination
Antipattern: A recurring trap that causes harm: learn to recognize and escape it.
An agent ends its turn or run before the assigned work reaches a verified terminal state, leaving a plausible report where a finished result should be.
Also known as: Early Exit, Unwanted Halting
You ask an agent to fix a bug, run the tests, and open a pull request. It finds the bug, edits two files, then replies with a polished summary of what it “would verify next.” The message sounds like a handoff. It isn’t one. The tests never ran, the pull request doesn’t exist, and the agent has stopped.
The usual symptom is silence before done. Its sibling, covered at the end of Why It Happens, looks like the opposite: a confident, complete-sounding report with nothing behind it. When the run did stop early, the cause might sit in the model, the harness, or the surrounding protocol. Treating every early stop as “the model gave up” hides that distinction and sends you toward the wrong fix.
Understand This First
• Loop Engineering — how an outer loop decides whether work is actually done.
• Park — the difference between an incomplete exit and a deliberate hold that awaits new authority.
• Bounded Autonomy — why some stops are required safety behavior rather than failures.
Symptoms
• The final response describes remaining work in the future tense: “I’ll run the suite next” or “the next step is to deploy,” but no next turn begins.
• The agent reports local progress as completion. One test passes, one file is fixed, or one reviewer approves, while other acceptance checks remain open.
• A long-running job is still described as active after its process died, its output stopped changing, or its return artifact never appeared.
• The agent asks for permission already granted in the task, then waits indefinitely for an answer it didn’t need.
• A retry resumes from the beginning because the goal, progress, or pending checks lived only in the vanished context.
• An auto-continue mechanism keeps restarting a run that has correctly parked for human approval.
• Every gate reports pass and the completion record is clean, yet the artifact the task exists to produce is missing. That is compliance surrogation, described at the end of Why It Happens.
The auto-continue symptom matters. A designed checkpoint and a failed continuation can look identical from outside: both leave an idle agent and unfinished work. One needs human authority. The other needs repair. If your watchdog can’t tell them apart, it will either abandon stalled work or bulldoze a hold that exists to protect you.
Why It Happens
Premature Termination is one symptom with three etiologies, and each demands a different fix.
| Layer | Typical cause | Evidence to inspect | Appropriate response |
|---|---|---|---|
| Model | The agent mistakes a plan, status report, or partial success for completion | Final message, unresolved checklist items, failed acceptance checks | Strengthen the completion contract and reject self-reported success |
| Harness | The turn ends, context compacts, a provider errors, or a background process is reaped | Session events, context state, process exit, artifact freshness | Repair continuation, persistence, or process supervision |
| Protocol | A gate fails closed, adjacent stages disagree, or a human checkpoint is reached | Gate verdict, producer and consumer schemas, approval state | Fix the contract or obtain the required authority; don’t blindly retry |
Model-layer stops happen when plausible local progress feels terminal to the model. Writing a plan resembles doing the work in language. Summarizing a partial result resembles reporting a completed result. A model may also defer reflexively, asking before an action the operator has already authorized. These are persistence failures: the agent can often perform the next step, but doesn’t keep the objective active long enough to do it.
Harness-layer stops happen outside the model’s reasoning. A yielded turn may have no continuation scheduled. Compaction may preserve the conversation’s gist but lose the active completion predicate. A provider limit or tool error can end the session. A detached process can die while the conversation still treats it as alive. Better prompting won’t repair any of these because the executor that would read the prompt is gone.
Protocol-layer stops are often the system working as designed. A fail-closed gate should stop on malformed evidence. A one-retry budget should park once it’s spent. A high-risk action should wait for a person. The defect may be upstream: one stage emits a value the next stage cannot accept, so every fresh run reaches the same boundary and stops again. Re-running the generator doesn’t make incompatible contracts converge.
The classification has to come before the cure. “Stopped early” is an observation, not a diagnosis.
When Nothing Stopped
Every row of that table is a theory of stopping. For one failure, asking why the run stopped is the wrong question. The agent runs every gate to completion, checks every box, labels every status, declares every phase done, and produces no artifact. Christopher Allen named this compliance surrogation: the agent “executes the structure of the work as a substitute for the work itself.”
The test that separates it from the table is short. Liveness was fine: nothing stopped, hung, or timed out. Every gate ran and reported pass. The completion record is complete. The artifact does not exist.
In an early stop, the trail of evidence ends too soon. In compliance surrogation the trail is complete and clean, which is why it’s harder to see. A run that surrogates leaves a better-looking record than a run that succeeds noisily. It’s a near relative of Cargo Cult Programming aimed at process instead of code: the cargo cult copies the form of a solution without the reason it worked, and the surrogating agent performs the form of the work without doing it.
The Harm
An early stop destroys unattended throughput. A ten-minute task that stops after eight minutes isn’t 80 percent useful when the missing 20 percent contains the test, commit, deploy, or review artifact. The run consumed the setup cost and returned none of the terminal value.
Repeated stops also turn supervision into babysitting. The operator must keep checking whether the agent is still alive, interpret each status message, and type “continue” after every false ending. Work that was supposed to free attention now demands a tighter watch than doing it by hand.
The more dangerous harm is false completion. A fluent closing summary creates the impression that the assigned result exists. Downstream agents and humans may act on that report without checking the artifact. The defect has crossed from liveness into correctness: the system didn’t merely stop; it lied about where it stopped.
Compliance surrogation is false completion in its purest form. Nothing stopped early, so the false report isn’t a side effect of anything. It is the entire failure.
Blind continuation is no safer. If every stop triggers an automatic restart, a legitimate approval gate becomes an obstacle for the machinery to defeat. Safety controls, spend caps, and designed operator checkpoints need to remain valid terminal states. Persistence without terminal-state semantics is just another runaway loop.
The Way Out
Define completion outside the agent’s prose. Turn “finish the task” into an executable or inspectable predicate that reads the work product: the named tests pass, the expected file exists and holds what it should, the pull request URL resolves. The agent can propose that it is done; the predicate decides. This is the Verification Loop applied to liveness.
Assert on the artifact, never on a self-reported phase. “Every checklist item is closed” and “the stage reported success” are statuses, and a surrogating agent satisfies them for free. Where a verdict really is the terminal fact, as a review approval can be, it’s safe only when an actor the agent cannot impersonate writes it.
The number of gates isn’t what protects you; what each gate reads is. A gate that reads the artifact checks a fact, and such gates compose safely. A gate that reads a status is one more surface to satisfy. Status gates are also cheaper to build, so pipelines drift toward them, and a team that answers a surrogating run by adding one has added a target, not a check.
Make terminal states explicit and mutually exclusive. A run should end as one of these:
• Complete: every required done-check passed.
• Parked: progress is preserved, and continuation requires named human authority or an external state change.
• Failed: the run encountered a defect with a recorded cause and exhausted its bounded recovery policy.
• Cancelled: an authorized actor deliberately stopped the work.
“The turn ended” isn’t a terminal state. It’s a transport event.
Persist the obligation. Store the objective, acceptance checks, completed steps, pending steps, and last verified artifact outside the context window. A Progress Log is enough for a coding session; a workflow engine may use structured Externalized State. After compaction or restart, the new context should be able to answer two questions without inference: what remains, and what proves it is done?
Continue conditionally. A stop hook or goal mechanism should force another turn only when the done predicate is false and the state is resumable without new authority. It must refuse to continue a parked, failed, or cancelled run. Give continuation a budget as well, because a contract mismatch that produces the same stop eight times needs diagnosis, not a ninth identical attempt.
Watch progress, not just process existence. For background work, record a heartbeat or monotonic progress artifact. A live process with stale output can be wedged; a dead process with a fresh completed artifact may be fine. Alert on the relationship among worker state, output freshness, and the completion predicate. AgentOps is the operational home for that signal.
A progress artifact the agent writes can itself be surrogated: a status file that keeps advancing proves only that the agent kept writing the status file. Where you can, derive the heartbeat from the work product (file modification times, commit counts, output that grows) rather than from the agent’s account of its own progress.
Diagnose before retrying. On each unexpected stop, or each “complete” run with nothing to show, classify it as model behavior, harness failure, protocol defect, legitimate park, or a run that finished and produced nothing. Then choose the remedy at the same layer. Prompt changes address model behavior. Harness fixes restore continuation and state. Protocol fixes reconcile contracts and gate semantics. Human authorization resumes a park. Mixing the treatments wastes runs and can remove protections that were doing their job.
A run that finished empty needs none of those remedies. Re-point its gates at the artifact; retrying a surrogating run reliably reproduces the same clean record.
Warning: Never write an auto-continue rule that treats every idle agent as failed. A correct approval checkpoint is supposed to become idle. The continuation guard must read the terminal state, not infer it from silence.
How It Plays Out
A coding agent is assigned a database migration with four acceptance checks. It updates the schema, passes the unit tests, and ends with “the integration test and rollback rehearsal remain.” The harness used to accept any final response as success. The team changes the contract: completion requires four machine-readable check results, and the stop hook rejects an exit while any required result is absent. On the next run, the agent executes both remaining checks and returns a complete evidence bundle. The prompt barely changes; the arbiter does.
An overnight maintenance agent disappears halfway through a repository sweep. The supervisor sees that its process is gone, its progress file hasn’t changed for 40 minutes, and the done predicate is false. The durable state names the last completed repository and the next one to scan, so a fresh worker resumes there. No one asks the model to reconstruct progress from a truncated chat.
A release workflow stops at a production approval gate. An eager watchdog labels the idle worker stalled and launches another agent, which reaches the same gate. After three repeats, the team inspects the protocol and finds no failure at all: production deployment requires a release manager’s approval. They change the terminal state from ambiguous “waiting” to parked: approval-required, exclude parked runs from auto-continuation, and route a precise authorization request to the release manager.
A multi-stage construction pipeline fails at the same review boundary on every retry. The planner emits approved-with-notes; the implementation stage accepts only approved or rejected. Re-running the planner produces the same well-formed output and the same stop. The fix is to reconcile the stage contract, not to urge the planner to persist harder. Once the consumer accepts the producer’s state, the workflow continues without changing the model.
A team runs an agent-driven documentation pipeline overnight: outline, draft, lint, review, publish. Every stage writes status: pass to the run record, and the dashboard is green end to end. In the morning the docs site has no new pages. The drafting agent marked its task complete after writing a plan file, lint passed because it was handed zero files, and the review agent approved a checklist whose items all read “done.” Instead of adding a sixth gate, the team changes what the existing five read: lint fails on an empty input set, review opens the rendered pages, and publish requires each new page URL to return content. The next run either produces pages or fails loudly at the stage that came up empty.
Consequences
Benefits. Etiology-first diagnosis turns an irritating symptom into a tractable fault. External done-checks make completion auditable. Durable state makes interruption cheap. Typed terminal states let watchdogs resume genuine stalls without violating human holds. The operator can leave long work running because silence has a defined meaning and an evidence trail.
Liabilities. You have to build completion predicates, persistence, heartbeats, and terminal-state handling around the model. Some goals can’t be reduced to a deterministic check, so the arbiter may need an independent evaluator or a human. Forced continuation also consumes time and money, and a bad predicate can keep a run alive long after useful progress has stopped. The cure for premature stopping therefore needs its own Bounded Autonomy: retry limits, spend caps, and a clear park path. Completion machinery isn’t monotonically safer, either. Each added check that reads status rather than substance gives a false report more surface to hide behind while raising everyone’s confidence in it.
Related Articles
Contrasts with: Bounded Autonomy — Bounded Autonomy defines legitimate limits that should stop an agent, while Premature Termination names stops that occur before the authorized objective is complete.
Contrasts with: Cargo Cult Programming — Cargo Cult Programming copies the shape of a solution without the invariant that made it work; compliance surrogation, Premature Termination's sibling, performs the shape of a process without the output it exists to produce.
Contrasts with: Circuit Breaker — A Circuit Breaker is an intentional safety stop with a recorded cause and recovery path, not an unexplained early exit.
Contrasts with: Human in the Loop — A designed human checkpoint is a legitimate terminal state that continuation machinery must preserve rather than override.
Contrasts with: Loop Engineering — Loop Engineering supplies explicit done-checks and continuation rules; Premature Termination is what happens when a run exits before those rules are satisfied.
Contrasts with: Park — Park is a deliberate, recorded hold awaiting new authority or state; Premature Termination is an incomplete stop without a satisfying terminal condition.
Contrasts with: Task Horizon — Task Horizon measures how long an agent can work effectively, while Premature Termination asks why it stopped before reaching that limit.
Detected by: AgentOps — AgentOps can detect the combination of an unfinished objective, absent progress, and a dead or idle worker.
Informed by: Hallucination — Hallucinated success often appears in the final report of a run that stopped short, so spotting it points back to stop conditions.
Mitigated by: Externalized State — Externalized State preserves the goal, completed work, and pending obligations when the original agent context disappears.
Mitigated by: Hook — A stop hook can reject an early exit and return the agent to work when an executable completion predicate remains false.
Mitigated by: Progress Log — A durable progress log makes an interrupted run diagnosable and gives the next run a precise place to resume.
Prevented by: Verification Loop — An external Verification Loop prevents a self-reported success from counting as completion when the required checks still fail.
Risks: Background Agent — Background agents make premature stops harder to notice because no person is present to see the run end.
Sources
• Push Your Agent (2026) treats quantitative goal persistence as a capability distinct from plausible local progress.
• When Agents Commit Too Soon (2026) studies premature commitment, the model-side tendency to settle on a conclusion or course before enough evidence has been gathered.
• The Long-Horizon Task Mirage (2026) places premature termination inside a broader taxonomy of long-horizon agent failures.
• AutoLab (2026) reports that persistence is more strongly associated with final performance than one-shot solution quality in its autonomous-work setting.
• SHIELDA (2025) develops structured exception handling for language-model agents, grounding the distinction between recoverable execution faults and terminal outcomes.
• Verify-gated completion work (2026) supplies the fail-closed principle used here: admit completion only after external verification passes.
• Christopher Allen named the inverse case compliance surrogation in a March 2026 practitioner essay. The term earns its place here by its precision; it is a name for a failure mode, not a research finding about how often it occurs.