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

Autonomous agents are gaining the ability to interact with external services through APIs and execute complex workflows. However, a problem arises when an agent attempts to make a financial transaction, the provider handles it, and the orchestrator fails to receive confirmation before timing out. Consider this situation: an agent initiates a money transfer.

The orchestrator verifies the request and chooses a service to handle it. The service processes the transaction successfully, but the response either gets lost or delayed on its way back to the orchestrator. The orchestrator then times out. Does this mean the transaction succeeded or failed? We cannot simply assume the transaction failed.

If we immediately try to retry, it could lead to two identical transactions taking place. The main architectural issue is that we need clearly defined roles and responsibilities in a reliable agentic financial system. The orchestrator should coordinate the execution, enforce policies, and start the operations. The transaction ledger should maintain the unique identifier of each transaction, its execution state, and the confirmed result.

A separate reconciliation engine should investigate any unresolved operations and determine their actual outcomes. The orchestrator should not be solely responsible for keeping track of transaction records. If a timeout occurs, an ambiguous state needs to be established, such as OUTCOME_UNKNOWN. Instead of blindly attempting another execution, the system should retain the original transaction identity, verify the provider's status using a reference or idempotency key, reconcile the final outcome, and only allow execution again when it is confirmed to be safe.

Concurrent retries by multiple workers pose another challenge. To address this, we need atomic state transitions and durable execution claims. There are several questions that need to be addressed. Should the unresolved transaction state be stored entirely within the ledger, with a separate reconciliation process handling resolution?

Should the decision on whether a retry is allowed be managed by the orchestrator or a specialized execution-state mechanism? What should happen when a service does not provide reliable idempotency or transaction-status queries? How can we strike a balance between system availability and financial safety when the ledger is temporarily inaccessible?

My current perspective is that autonomous agents can make decisions, but financial operations should still be governed by strict controls and recoverable transaction records. What approach would you take to design this system, and what changes would you make?