Agent reliability guide
Stop an empty wallet from becoming a retry loop.
An agent running on a schedule can forget why its previous process stopped. Treat insufficient funds as a persistent operating state, with an explicit recovery path.
Keep the block across restarts
Store the blocked state durably for the relevant wallet and payment context. Show the operator what failed. A new process should read that state before attempting another payment.
Do not treat a seller's reported shortfall as authorization to top up a wallet. Recovery needs a verified balance change or an explicit operator decision, followed by the normal amount, recipient, asset and network checks.
A small offline acceptance test
- Start a process against a synthetic insufficient-funds response.
- Verify that it records the block and produces an operator-visible explanation.
- Start a second, fresh process with the same wallet context.
- Verify that it reads the existing block and makes no new signing or payment attempt.
- Simulate a verified recovery and confirm that normal authorization checks still apply.
Keep an unknown settlement separate from insufficient funds: an uncertain previous payment requires reconciliation, even when the wallet is funded again.
Fit the check to your runtime
The scheduler, wallet and payment client determine where durable state belongs. Start with one supported Base flow and an agreed acceptance test.
Explore the integrationA related public report: insufficient-funds retries in a scheduled agent. This is a test outline, not a claim that we reproduced or fixed that project's execution path.