How to Fund an Autonomous Agent: Float, Top-Ups, and Gas

Size the float from a failure budget

The instinct is to fund an agent based on what it typically spends. That produces a number that is comfortable and wrong, because it optimizes for the case where nothing goes wrong.

Start from the other end. If this agent malfunctions, loops, or is manipulated for an entire refill period, what is the maximum loss you can absorb without it being a serious event? That number is your float ceiling.

Then check it against normal usage. If the failure budget is smaller than what the agent legitimately needs to do its job, you have learned something important before deploying rather than after: either the task is too expensive to delegate at your current risk tolerance, or it needs to be split into smaller units of work with tighter authority.

This ordering matters because the two numbers answer different questions and only one of them is about safety. Funding to expected usage means your worst case is defined by how long it takes a human to notice.

Top-ups: automatic, bounded, and observable

Manual refills fail in both directions. Refill too late and the agent stops mid-task. Refill generously to avoid that and you have recreated an unbounded float with extra steps.

The pattern that works is a threshold trigger with limits on the refill itself. When the float drops below a low-water mark, top it up to the ceiling, subject to a maximum number of refills per period.

That second constraint is what preserves the safety property. Without it, an agent draining its float repeatedly simply pulls the same amount again each time, and your bounded exposure becomes a per-refill quantity multiplied by however many times the system was willing to refill.

Make the refill visible. A top-up is a signal about behavior: an agent refilling more often than usual is either doing more work or doing something wrong, and both are worth knowing. Refill frequency is often a better leading indicator than total spend, because it moves before the total looks unusual.

Gas is a separate problem

An agent needs the network's native asset to pay fees, and that balance is separate from what it spends on purchases. Conflating them produces a specific and avoidable failure: an agent with plenty of settlement currency that cannot transact because it cannot pay fees.

Keep a working balance sized against expected transaction volume with real margin, since fee levels move and your agent does not choose when. Monitor it independently and alarm before exhaustion rather than at it, because a refill takes time to confirm and during that window the agent is stopped.

The exhaustion failure is worse than it sounds for agents specifically. A human developer who hits an empty fee balance sees an error and tops it up. An unattended agent may retry, may treat the failure as a transient network problem, and may abandon a task it had already partially paid for.

This is one of the reasons a low-fee network matters for agent workloads beyond the obvious economics: the fee balance becomes small enough to manage as a rounding detail rather than a treasury operation.

What happens when funds run low

Decide this explicitly, because the default behavior of most systems is bad.

Stop before starting. An agent should check that it can afford the whole task before beginning it, not discover halfway through that it cannot finish. Partial completion is usually worse than not starting, especially when the early steps already cost money.

Fail loudly and specifically. Insufficient float is a distinct condition from a payment error, and an agent that cannot tell them apart will retry a funding problem forever.

Do not let the agent fund itself from a wider source. An agent that can move money from a treasury into its own float has no ceiling, only a delay. The refill decision has to sit outside its authority.

Preserve the record. A task abandoned for funding reasons should leave a clear record of what was paid for and what was not, so the retry after refilling does not repurchase what already succeeded.

CryptoCadet is built around this shape: a non-custodial USDC rail on Base where the agent spends from a session-key bounded float with custody in the OS keychain, supporting x402-style pay-per-call and ERC-20 subscriptions. The float is the containment boundary, and keeping refill authority outside the agent is what keeps that boundary meaningful.