A Timeout Is Not a Failure: Handling Financial Transactions in Autonomous Agent Systems

Autonomous agents are becoming increasingly capable of calling APIs, executing tools and coordinating complex workflows.
But what happens when an autonomous agent initiates a financial transaction, the provider processes it, and the orchestrator times out before receiving confirmation?
Consider this scenario:

1. An agent requests a money transfer.
2. The orchestrator validates the request and selects a provider.
3. The provider receives and processes the transaction.
4. The response gets lost or delayed.
5. The orchestrator times out.

Did the transaction succeed?
We cannot safely assume it failed. Retrying immediately could result in a duplicate transaction.

The architectural challenge

I believe reliable agentic financial systems need clearly separated responsibilities:

• Orchestrator: Coordinates execution, applies policies and initiates operations.
• Transaction ledger: Maintains durable transaction identity, execution state and confirmed outcomes.
• Reconciliation engine: Investigates unresolved operations and establishes their actual outcomes. The orchestrator should not be the sole owner of transaction history. Recovery must survive application crashes and process restarts. ## What should happen after a timeout? An uncertain outcome should become an explicit state, such as OUTCOME_UNKNOWN. Instead of blindly retrying, the system should:

1. Preserve the original transaction identity.
2. Check the provider's status using an available reference or idempotency key.
3. Reconcile the outcome.
4. Allow another execution only when it is established to be safe.

Concurrency introduces another challenge: multiple workers could attempt to retry the same operation simultaneously. Atomic state transitions and durable execution claims are therefore essential.

Questions I'd like to explore

1. Should unresolved transaction state live entirely in the ledger, with a separate reconciliation process responsible for resolution?
2. Should retry eligibility be controlled by the orchestrator or a dedicated execution-state mechanism?
3. What should happen when a provider offers neither reliable idempotency nor transaction-status enquiries?
4. How should we balance system availability against financial safety when the ledger is temporarily unavailable?

My current thinking is that autonomous agents should be allowed to make decisions, but financial execution must remain governed by deterministic controls and recoverable transaction state.

How would you approach this architecture? What would you change?