A pending-result convention is a protocol-adjacent signalling pattern that tells the caller a tool invocation is waiting for human approval instead of having failed. It is only useful when the client understands the metadata and can branch correctly, otherwise the pause can be misread as an error or ignored altogether.
How Pending-Result Signalling Works
A pending-result convention is not the same as a success or failure response. It is a deliberate intermediate signal that says the request is still in progress, usually because a human approval step or other external decision is pending before execution can continue.
The key idea is that the caller must understand the convention as metadata, not as an exception path. In practice, the client needs a branch for “waiting on approval” so it can hold state, poll, subscribe, or notify the user instead of retrying a call that has not actually failed.
Why It Exists in Tool and Protocol Flows
Pending-result signalling is most useful in workflows where a tool invocation may be paused for review, policy approval, or controlled release. It lets the system preserve intent, avoid duplicate execution, and communicate that the action is neither denied nor completed yet.
This pattern sits close to protocol design because it depends on clear status semantics. If the receiving system treats the pending state as an error, it may trigger needless retries or alerts. If it treats the state as a silent no-op, the user may assume the action was lost.
Well-formed implementations usually make the pending state explicit enough for the client to distinguish it from transport failure, authorization failure, and ordinary asynchronous delay. That distinction is what makes the convention operationally useful.
What Can Go Wrong When the Client Misreads It
The main failure mode is ambiguity. A client that does not recognise the pending-result convention may misclassify the pause as a timeout, a rejected call, or a completed request with no output, which breaks the workflow and obscures the real status.
A second risk is duplicate action. If a caller retries because it thinks the first invocation failed, the system may create repeated approvals, duplicate tool executions, or conflicting state transitions. In human-in-the-loop flows, that can create confusion rather than control.
The design therefore depends on both sides agreeing on the signalling contract. If the caller and tool do not share the same metadata interpretation, the convention adds complexity instead of clarity.
Where It Fits in Reliable Automation
Pending-result conventions are part of making automation behave predictably under gated execution. They are especially relevant when a workflow can pause between initiation and release, because the system must preserve continuity without pretending the result is final.
For practitioners, the important question is whether the surrounding client can model a third state between “done” and “failed.” If it cannot, the convention is fragile and may be better replaced by a simpler asynchronous pattern with explicit job tracking. If it can, the pattern gives a clean way to represent approval latency without collapsing it into error handling.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security 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 | AC-1 — Access Control Policy and Procedures | Pending-result flows depend on clear access and approval policy semantics. |
| IA-5 — Authenticator Management | The convention often accompanies approved, controlled tool execution backed by credential handling. | |
| Recommendation — Define and document when a pending approval state is allowed and how callers must handle it. Ensure credential and token handling does not convert a pending approval into an unintended execution path. | ||
| NIST CSF 2.0 | PR.AA-05 — Least Privilege | Approval-gated tool calls are a least-privilege pattern for constrained execution. |
| PR.PS-05 — Integrity by Design | The pending state is a protocol integrity mechanism that must be unambiguous to clients. | |
| Recommendation — Require approval before granting the tool or agent the authority to proceed. Design the status model so pending, failed, and completed states cannot be confused. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Pending-result conventions commonly sit in authorization-gated tool and API flows. |
| Recommendation — Enforce function-level authorization before any pending request can advance to execution. | ||
Practitioner Guidance
Common misunderstanding: A pending result is often assumed to be just a slower success response. It is not, because the whole point is to communicate that execution is intentionally paused and still dependent on another decision.
What to watch for: Use this pattern only when the client logic, API contract, and user experience all recognise the intermediate state. Otherwise, the signal tends to disappear into retry logic or error handling, which defeats the purpose of the convention.