Join our Newsletter — 33% off our NHI Course

How should teams prevent AI agents from exiting early when models narrate before acting?

Use an explicit or adaptive finish condition that requires evidence of completed work, not just a text response that sounds final. Harnesses should check for tool execution, state change, or another verifiable completion signal before they break the loop.

Why an agent needs a real finish condition, not a final-sounding sentence

Teams should treat “I’m done” as a hypothesis, not a completion event. In agent loops, narration can appear before the work is actually finished, so the harness needs an explicit finish condition tied to evidence, such as a successful tool call, a state transition, or a recorded output artifact. That shifts control from language confidence to verifiable completion.

This matters because a model can generate a convincing summary after partial progress, while the underlying task remains open. If the loop stops on prose alone, you get premature termination, missed side effects, and misleading success signals. A completion gate should therefore be defined in operational terms, not rhetorical ones.

When the finish rule is too loose, early exit becomes a control-plane failure: the agent appears to have completed the task, but the system has no proof that the intended action actually happened. The practical fix is to separate the assistant’s narrative from the harness’s acceptance criteria, so only observable evidence can close the loop.

How to design the stop rule for an agent loop

Use a stop rule that checks whether the agent produced a verifiable result, not whether it sounded decisive. In practice, that means the harness should wait for an expected tool invocation, a changed state, a confirmed write, or another domain-specific completion signal before halting the run. If the task is multi-step, the finish condition should encode the last required step, not the first plausible conclusion.

Adaptive finish conditions are useful when the work cannot be reduced to one fixed checkpoint. For example, a harness can require a minimum evidence set, then stop only when the evidence matches the task type: successful retrieval plus synthesis for a research task, or tool execution plus state update for an operational task. That reduces both false positives and endless looping.

A good implementation also distinguishes “done with reasoning” from “done with action.” A model may finish its explanation before it finishes the workflow, so the harness should treat explanation as informational only. The authoritative stop signal should come from the task result contract, not from the agent’s self-report.

What reliable completion looks like in practice

Reliable completion is visible, testable, and tied to the intended side effect. If the agent was supposed to update a record, the harness should verify the record changed. If it was supposed to call a tool, the harness should confirm the tool response and resulting state. If it was supposed to gather evidence, the harness should require the evidence payload, not a recap of what the agent believes it gathered.

This is the same basic discipline used in other security and automation controls: trust the observable outcome, not the claim of success. It also improves debuggability, because a failed finish condition tells you whether the problem was tool execution, state verification, or loop control. That makes false completion easier to detect and reproduce.

Teams also need to define what counts as partial progress versus completion. If the agent can narrate useful intermediate work, the harness should preserve that output but keep the loop open until the final verifiable condition is met. That keeps intermediate reasoning available without letting it masquerade as task closure.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Agentic AI Top 10 addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework Control / Reference Relevance
OWASP Agentic AI Top 10 ASI02 — Tool Misuse The finish condition must confirm tool execution before stopping an agent loop.
ASI10 — Rogue Agents Premature self-termination can let an agent behave outside the intended control loop.
Recommendation — Require verified tool outcomes before treating an agent as finished. Constrain agent autonomy with explicit stop conditions and loop checks.
NIST CSF 2.0 PR.AA-05 — Identity Management, Authentication and Access Control Action gating and proof of completion depend on controlled, attributable execution paths.
DE.CM-01 — Anomalies and Events A harness should detect mismatches between narrated completion and actual system state.
Recommendation — Bind automated actions to controlled execution and verification points. Monitor for completion claims that are not matched by observable system events.
NIST SP 800-53 Rev 5 AU-6 — Audit Record Review, Analysis, and Reporting Verifiable completion requires logs or records that prove the action occurred.
Recommendation — Review audit records to confirm an agent actually completed the required work.

Practitioner Guidance

What to verify: Make sure the finish condition is grounded in an external signal the harness can check, not in a sentence the model writes about its own status. If the only completion evidence is textual, the loop is still vulnerable to early exit.

Decision rule: If the task has any side effect, require proof of that side effect before stopping; if the task is purely explanatory, accept text as the output but still validate that the output format and required components are present.

What good looks like: The agent can summarize progress at any point, but the harness only closes when the expected tool call, state change, or completion artifact is observed. That gives you a clean separation between narration and execution.

Practitioner takeaway: The safest finish condition is the one a model cannot fake with fluent prose, because durable automation depends on evidence of work completed, not confidence that work sounds complete.