---
slug: premature-termination
type: antipattern
summary: "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."
created: 2026-08-06
updated: 2026-08-06
related:
  loop-engineering:
    relation: contrasts-with
    note: "Loop Engineering supplies explicit done-checks and continuation rules; Premature Termination is what happens when a run exits before those rules are satisfied."
  bounded-autonomy:
    relation: contrasts-with
    note: "Bounded Autonomy defines legitimate limits that should stop an agent, while Premature Termination names stops that occur before the authorized objective is complete."
  park:
    relation: contrasts-with
    note: "Park is a deliberate, recorded hold awaiting new authority or state; Premature Termination is an incomplete stop without a satisfying terminal condition."
  task-horizon:
    relation: contrasts-with
    note: "Task Horizon measures how long an agent can work effectively, while Premature Termination asks why it stopped before reaching that limit."
  verification-loop:
    relation: prevented-by
    note: "An external Verification Loop prevents a self-reported success from counting as completion when the required checks still fail."
  hook:
    relation: mitigated-by
    note: "A stop hook can reject an early exit and return the agent to work when an executable completion predicate remains false."
  human-in-the-loop:
    relation: contrasts-with
    note: "A designed human checkpoint is a legitimate terminal state that continuation machinery must preserve rather than override."
  progress-log:
    relation: mitigated-by
    note: "A durable progress log makes an interrupted run diagnosable and gives the next run a precise place to resume."
  externalized-state:
    relation: mitigated-by
    note: "Externalized State preserves the goal, completed work, and pending obligations when the original agent context disappears."
  background-agent:
    relation: risks
    note: "Background agents make premature stops harder to notice because no person is present to see the run end."
  agentops:
    relation: detected-by
    note: "AgentOps can detect the combination of an unfinished objective, absent progress, and a dead or idle worker."
  circuit-breaker:
    relation: contrasts-with
    note: "A Circuit Breaker is an intentional safety stop with a recorded cause and recovery path, not an unexplained early exit."
---
# 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 visible symptom is always the same: silence before done. 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](loop-engineering.md) — how an outer loop decides whether work is actually done.
- [Park](park.md) — the difference between an incomplete exit and a deliberate hold that awaits new authority.
- [Bounded Autonomy](bounded-autonomy.md) — 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.

That last 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.

## 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.

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: the named tests pass, the expected file exists, the pull request URL resolves, every checklist item is closed, or the reviewer verdict is recorded. The agent can propose that it is done; the predicate decides. This is the [Verification Loop](verification-loop.md) applied to liveness.

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](progress-log.md) is enough for a coding session; a workflow engine may use structured [Externalized State](externalized-state.md). 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](agentops.md) is the operational home for that signal.

**Diagnose before retrying.** On each unexpected stop, classify it as model behavior, harness failure, protocol defect, or legitimate park. 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 those treatments wastes runs and can remove protections that were doing their job.

> **⚠️ 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.

## 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](bounded-autonomy.md): retry limits, spend caps, and a clear park path.

## Sources

- [*Push Your Agent*](https://arxiv.org/abs/2605.23574) (2026) treats quantitative goal persistence as a capability distinct from plausible local progress.
- [*When Agents Commit Too Soon*](https://arxiv.org/abs/2606.22936) (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*](https://arxiv.org/abs/2604.11978) (2026) places premature termination inside a broader taxonomy of long-horizon agent failures.
- [*AutoLab*](https://arxiv.org/abs/2606.05080) (2026) reports that persistence is more strongly associated with final performance than one-shot solution quality in its autonomous-work setting.
- [*SHIELDA*](https://arxiv.org/abs/2508.07935) (2025) develops structured exception handling for language-model agents, grounding the distinction between recoverable execution faults and terminal outcomes.
- [Verify-gated completion work](https://arxiv.org/abs/2605.17998) (2026) supplies the fail-closed principle used here: admit completion only after external verification passes.

---

- [Next: Garbage Collection](garbage-collection.md)
- [Previous: Agent Drift](agent-drift.md)