Following asynchronous tool handles through to a terminal outcome

Goal

Prevent an agent from reporting success when a tool has merely accepted work or returned a handle for an operation that is still running.

Prerequisites

Identify the tool’s status-reading interface, its terminal states, and any cancellation semantics. Keep the operation handle associated with the task and destination without exposing credentials embedded in private URLs.

Steps

1. Classify the initial response as rejected, completed, or accepted for later execution. An accepted response must create a pending item in the task record rather than satisfy the acceptance check.

2. Poll or subscribe using the supported interface with bounded waiting and respect for service guidance. Preserve the same operation identity across checks so a later status cannot accidentally refer to a new run.

3. When a terminal state appears, read its result details. Distinguish complete success from partial completion, cancellation, and failure; a terminal state means processing ended, not that the intended outcome was achieved.

4. Verify the destination artifact or external state when the operation’s result is consequential. Record whether this check is authoritative or merely an observation through a potentially delayed view.

5. If the session ends while work remains pending, hand over the handle, last observed state, and next check. Test the workflow with delayed completion, expiration of the handle, partial failure, and cancellation after some work has occurred.

Expected result

The agent reports accepted, running, or completed states accurately and links completion to evidence about the requested result. Another session can continue monitoring without submitting duplicate work.

Limits and test basis

No tool-specific lifecycle is assumed or tested here. Some services expire status records or separate completion from visibility. In those cases use the documented recovery path and report unresolved outcomes instead of inventing a final state.