The HTTP response tells us the provider accepted a request for processing. It does not say the export succeeded. RFC 9110 is explicit that a 202 request may or may not eventually be acted upon. The agent's tool result should therefore say accepted, with the provider job ID and an operation ID owned by our runtime. It should not collapse accepted into completed merely because the initial API call returned a 2xx status.

I would create a durable operation record before submission: tenant, user, exact action and arguments, approval and policy version, idempotency key if the provider supports one, attempt ID, and deadline. Submission transitions it to accepted only when the provider response is known. The dependent step waits on a verified terminal outcome. Polling and callbacks are two ways to observe the same provider job. Normalize both into a single state machine and make each observation idempotent by provider job ID, event ID or revision where supplied, and operation identity.

A submitted export can be accepted and still fail. A callback or poll verifies success or failure. A timeout leaves an unresolved operation that must be reconciled, and cancellation does not erase a later provider completion.
Accepted is a waiting state. Only verified provider outcome can unlock the dependent step.

A callback might arrive twice or after the wait deadline. Both deliveries should attach to the same operation. An identical terminal event is a no-op. A contradictory terminal event is not silently overwritten by “last callback wins.” Check the provider's status resource or event ordering contract, record both observations, and reconcile. An expired wait is not proof that the provider job stopped. Keep the operation as unresolved, report that to the user, and continue to monitor or query it according to retention and product deadlines.

Cancellation adds a sharper edge. If the user cancels after 202, send the provider's cancel request if it exists and record whether cancellation was accepted or confirmed. The export may finish anyway. Do not mark cancelled solely because the local waiter stopped. If the late callback says succeeded, record the effect, stop dependent actions that were cancelled, and tell the user what happened. A follow-up cleanup action may be possible, but it has its own outcome and authorization.

If the provider has no status API, we can still wait for a signed callback within a bounded period, but after that the operation is unknown unless another authoritative reconciliation channel exists. Retrying submission with a new key risks a second export. If the provider documents idempotent resubmission using the same key, we can use that specific contract within its window. Otherwise escalate rather than invent a completed result. Temporal's asynchronous Activity documentation illustrates that a worker function can return while the activity execution remains incomplete. Our external provider still decides the actual effect.

I would test response lost before the job ID is stored, callback before the waiter starts, duplicate callbacks, poll racing a callback, wait timeout, cancel racing completion, and provider retention expiry. The answer the user sees must reflect the strongest verified state we have, even if that state is uncomfortable: accepted, still running, failed, succeeded, or unresolved.