The AI Operator | October 9, 2026
This week, Fireblocks published a guide to how AI agents make payments. It follows the work from spending permission through payment and the records needed to match it against a budget.[1] That brings a practical failure into focus: the money can move before the agent receives a reply. What should the agent do when it cannot tell whether the payment went through?
That question deserves an answer before an agent gets permission to spend. A timeout means the agent stopped waiting. The action it requested may already have happened.[2][5] Sending a fresh request can turn one approved payment into two.
What's Happening This Week
The October 6 Fireblocks guide describes limits on spending, approved sellers and the time an agent has to act.[1] These controls give a payment a defined scope. A team also needs a rule for the gap between sending the request and learning the result.
PayPal's public developer guide gives a clear example. A request to capture a payment times out, but the server captures the payment. The caller then repeats the request with the same request ID. PayPal returns the payment's status without capturing it again.[2] This is an example in its documentation, rather than a reported customer incident.
Stripe describes a similar protection. A repeat request using the same key returns the saved result, including some errors.[3] The key is a label that lets the payment service recognize another attempt at the same action. Engineers call this idempotency. Its practical purpose is to let software ask again without doing the work twice.
These protections have limits. PayPal says support and the time it keeps an ID depend on the service being called.[2] Stripe says keys can be removed once they are at least 24 hours old. Reusing a key after removal creates a new request.[3] A team needs to know the rules of its actual payment connection.
Why This Is a CFO Problem
Consider an agent approved to pay one supplier invoice. This is a hypothetical example. The agent sends the payment, loses the reply and starts the task again. If the restart creates a fresh payment request, the original approval may now lead to a second transfer.
A spending cap alone leaves that problem open. Both attempts might sit below the cap. The missing control connects the approval to one intended payment, including its later attempts. Finance needs that connection because a duplicate ties up cash and creates work with the supplier. Getting the money back may require another decision and another person's time.
An unclear outcome also needs an owner. Marking the task failed can encourage another payment. Marking it complete can hide unfinished work. Keep it open as an unknown outcome until someone can match the request to the payment service's record. That status should stop a fresh payment from slipping through while the first is still being checked.
The Operator's Check
Test the case where the payment service accepts a request and the reply is lost. Use a test environment with no real money. Then restart the agent. Watch whether it keeps the original request ID and payment details, or creates a new payment.
For network errors, Stripe directs callers to retry with the same key and the same details.[4] That protected repeat can itself help resolve the unknown outcome. Checking first means checking which kind of failure occurred and whether a safe repeat is supported. It does not mean banning every retry.
A server error needs separate care. Stripe warns that a request returning a 500 error can have effects, advises against retrying it with a new key, and calls the result indeterminate.[4] In plain terms, the result is still unknown. A familiar error message should not give an agent permission to start over.
Money Move
Before expanding an agent's payment access, pick one workflow and test its lost-reply path. Have the builder and finance owner agree on how one approved payment is identified, how long duplicate protection lasts, and where unresolved outcomes go. Save that identity before sending the payment so a restart can find it.
Allow protected retries only within the payment service's rules, with a limit on attempts. Where protection is missing or has expired, pause the payment and assign a person to check the original result. Match the provider's record to the intended invoice before deciding whether another payment is needed.
The recovery path belongs in the spending decision. An agent given permission to pay also needs a clear way to stop when the result is unknown.
-dg