Any verifiable indication that an agent has actually finished the requested work, such as a required finish call, state change, or validated output. Strong completion signals reduce the chance that a transcript looks complete while the underlying task is still open.
What a completion signal actually proves
A completion signal is not the work itself, it is the evidence that the work reached a defined end state. That distinction matters because transcripts, logs, or conversational turn-taking can look finished even when the underlying task is still incomplete.
Strong signals are verifiable, not merely suggestive. A required finish call, a committed state transition, or validated output gives you something concrete to test, audit, and automate against. Weak signals, such as a friendly closing phrase or an assumed timeout, are easier to spoof or misread.
Why completion signals matter in agentic workflows
Completion signals become important wherever an agent has execution authority, tool access, or a downstream workflow that depends on the task really being done. Without a clear completion condition, a controller may release follow-on steps too early, record success incorrectly, or leave hidden partial work in place.
They also create a boundary between “still in progress” and “safe to advance.” That boundary is especially useful in orchestration, human review loops, retries, and handoffs between systems that need an explicit end condition before they can proceed.
Common forms of completion signal
Completion signals can take several forms, depending on the system design. Some are explicit, such as a finish or done call from the agent. Others are state-based, such as a persisted status change from running to complete. Others are output-based, such as a validated artifact, passed check, or accepted result.
The best signal is the one that is hardest to fake and easiest to verify. In practice, that often means combining a declared end state with evidence that the required output exists and meets the acceptance criteria. That reduces the chance that a session appears closed before the actual deliverable is usable.
How completion signals fit into control design
Completion signals are part of the control plane around automated work. They help a supervisor, orchestrator, or downstream system decide when to advance, commit, notify, archive, or release resources. If the signal is ambiguous, every dependent step inherits that uncertainty.
Good designs treat completion as a contract, not an assumption. The contract should be explicit about what counts as finished, what evidence must accompany the signal, and what should happen when the signal never arrives or the output fails validation.
Risk and Threat Considerations
Completion signals are vulnerable to false positives, which can make an unfinished task look closed and create downstream exposure. In agentic and automated workflows, that can lead to premature approvals, incomplete remediation, stale state, or a mistaken belief that a task was safely handed off.
Failure mechanism: The controller trusts a weak or spoofable end indication, such as a transcript ending, a timeout, or an unverified self-report, instead of validating the required terminal condition.
Impact: Dependent systems may proceed on bad assumptions, open work may be lost, and incomplete actions may be treated as successful completion.
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 SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Completion signals depend on auditable evidence of task termination and state changes. |
| SI-7 — Software, Firmware, and Information Integrity | Validated output is a completion signal only when its integrity can be confirmed. | |
| IA-9 — Identification and Authentication (Non-Organizational Users) | Agent-style completion signals often sit beside machine-to-machine authenticated workflows. | |
| Recommendation — Log terminal task events so completion can be verified after execution. Validate outputs before treating them as completed work. Require authenticated task execution before accepting a completion state. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity Management, Authentication and Access Control | A completion signal changes when access or authority should advance or stop. |
| Recommendation — Tie task completion to access revocation or workflow transition controls. | ||
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | An agent that appears finished but still holds authority can create privilege and workflow abuse. |
| Recommendation — Verify task termination before allowing the agent to keep or reuse authority. | ||
Practitioner Guidance
What to watch for: Treat the completion signal as part of the system’s integrity boundary. If the signal cannot be independently verified, it should not be used as the only proof that work is done. The practical question is whether a downstream system can rely on it without also checking state or output validity.
Practitioner takeaway: The safest completion signals are explicit, verifiable, and tied to the actual acceptance condition, not to conversational closure or presumed intent.