Record external effects and uncertain outcomes

A successful local function return does not prove that an external effect completed. The destination may queue work, accept only part of a payload, return before downstream processing, or complete after the caller times out.

Create an action event before sending the request. It includes the approved proposal, destination, stable action ID, idempotency key and redacted request shape. After the call, record the transport result and the destination's own identifiers.

Classify outcomes precisely:

• confirmed: the destination returned evidence of the expected committed state;
• accepted_async: the destination accepted work that still needs completion tracking;
• rejected: the destination made no requested change and returned a known reason;
• partial: only part of the requested effect is confirmed;
• uncertain: the request may have reached the destination but confirmation is missing;
• reversed: a later compensating action is confirmed.

An accepted_async action needs follow-up events from polling, webhook delivery or another status mechanism. Do not close the task until its task contract permits that state or the final result is known.

Send an uncertain action to reconciliation before retrying it. Query by idempotency key or destination reference. If the system offers no lookup, route the task to an operator with the request time, target and expected effect. Keep the uncertainty visible until somebody records a supported resolution.

A reversal should link to the original action and use its own proposal, approval and destination evidence. Removing the original event would destroy the sequence needed to explain both effects.

Capture downstream identifiers where available. A changed record may start a notification or job. Linking those effects helps later review without claiming that the agent directly controlled every downstream process.