Key facts.
- Anthropic's computer use model card (2024) identifies premature task declaration as a documented failure mode in long-horizon agent tasks: agents stopping at plausible completion points before the actual objective state has been achieved (Anthropic Computer Use, anthropic.com, 2024).
- OSWorld (arXiv:2404.07972) data shows that agents over-declare success: they report task completion at higher rates than the actual end-state validation confirms, with false completion declarations occurring in cases where the agent took all the right steps but the final state check fails.
- Premature completion occurs most often at natural cognitive stopping points in the task flow: after submitting a form, after clicking "Save", after the completion modal appears - without checking whether the save actually persisted, the form actually submitted, or the modal reflects actual completion rather than a pending state.
- The structural cause of premature completion is a missing goal-state verification step after the last planned action: the agent plans a sequence of actions and executes them, but has no step that explicitly checks whether the cumulative effect achieved the stated goal.
- Agents trained with human feedback often reinforce premature completion because human raters in labeling pipelines judge completion at the action level ("did the agent perform the right actions?") rather than at the outcome level ("was the goal actually achieved?").
Why agents stop before they should
Anthropic's computer use card documents agents calling success at a plausible stop, not the goal; a more capable model believes it as sincerely. (arXiv:2404.07972)
The agent's plan has a finite number of steps. When the last step completes, the planning architecture has no more steps to execute. The session transitions to a completion state. This is appropriate when the last step was a goal-state verification that passed. It is inappropriate when the last step was any action other than a goal-state verification. But most agent plans end with an action (click Save, submit the form, apply the change) rather than with a verification (confirm the save persisted, confirm the form submission created the record, confirm the change is now visible in the system). The last step is the action, not the check. The agent stops at the action.
This is an architectural gap, not a reasoning error. Adding a mandatory final verification step to every task plan - one that explicitly checks whether the goal state has been achieved - is a plan construction rule, not a model capability. It can be enforced at the scaffolding level regardless of which model is driving the agent.
The mandatory final verification step
The pattern that prevents premature completion is simple to state: every task plan must include, as its final step, a verification that the goal state has been achieved. The verification step is not "review what I did." It is "check whether the system is now in the state the task required." For a file save task: confirm the file exists at the expected path with the expected modification date. For a form submission: confirm the confirmation email was received or the record appears in the relevant system. For a configuration change: confirm the configuration endpoint returns the new value. The verification step is specific, measurable, and passes only when the goal is actually met.
Premature completion patterns by task type
| Task type | Common premature stopping point | Required verification | Failure if skipped |
|---|---|---|---|
| File save | After clicking Save button | File exists at path with correct modification date | File not saved (disk full, permission denied) |
| Form submission | After clicking Submit | Confirmation email or record in system | Submission rejected silently |
| Configuration change | After applying change | Config endpoint returns new value | Change not persisted (cache not cleared) |
| Data transfer | After transfer job completes | Row count and checksum match in target | Partial transfer, silent truncation |
VibeModel's Pattern Intelligence Layer identifies which task types in your specific deployment have the highest premature completion rates, measured by the gap between task declaration and subsequent user re-engagement on the same task. By surfacing these patterns, it gives you the specific task types where mandatory final verification steps would eliminate the most re-work. The fix is architectural and low-cost; the pattern data tells you where to apply it first.
Frequently asked questions
Is premature completion more common in long tasks or short tasks?
Long tasks, significantly. Short tasks typically have a single clear completion signal (the API returned success). Long tasks accumulate multiple plausible stopping points - every modal that appears, every progress indicator that reaches 100%, every "done" message that appears mid-task - any of which the agent may treat as the terminal completion signal rather than an intermediate one.
Can we add final verification as a prompt instruction rather than an architectural change?
Partially. Prompting the model to "always verify the goal state before declaring completion" improves behavior in many cases but is unreliable because the instruction competes with the agent's plan completion heuristic. The architectural approach - enforcing a mandatory verification step in the plan structure regardless of the model's completion judgment - is more reliable than prompt engineering for this failure mode.
How do we define the goal state for open-ended tasks where completion is not clearly binary?
Decompose into verifiable sub-goals. If the overall task is "prepare the report," the verifiable sub-goals are "document contains required sections," "all cited figures are present," "document is saved in the specified format and location." Each is binary. Together they constitute the verifiable goal state for a task that seemed open-ended at the goal level.