Talk to Formance about agentic payments
See how funded accounts, atomic postings, and nested budgets can turn AI agent spending limits into hard structural controls.
AI agent spending limits only hold when they bind at the ledger that records the transaction. Prompts, application counters, and card controls sit above the transaction layer, so concurrent execution turns a stale budget check into an immediate overspend. A ledger-enforced reservation from a funded account makes the budget movement and the payment succeed or fail as a single posting, resolving the concurrency race.
When your wire agents are in production, payments fail. Three of your procurement agents fire payment requests inside the same 200-millisecond window. Each calls the budget service and reads the full $40,000 of remaining headroom. Each passes the check and commits $32,000. The team cap was $40,000, but the three agents had committed $96,000 before the first response came in. Nothing malfunctioned.
The check-in application code was advisory, and every agent honestly reported a balance that was stale by the time the money moved. Prompt-based and application-counter limits sit above the layer that records and controls the transaction. Without a human-on-the-loop check between an error and its repetition, losses arrive at machine speed.
The problem is that AI agent spending limits in prompts are advisory
A limit written into a prompt guides the model, but enforcement happens in the system that executes the transaction. In production, failure modes include:
The patterns point to the prompt stating an intent, but the money moves through a different system that never reads that intent. Any limit that lives above the transaction layer can be bypassed by a model that misbehaves or miscalculates. The only place a spending limit binds is the ledger layer that records the debit.
Agent guardrails for payments stack in four layers, from weakest to strongest: prompt instructions, application-level checks, card-level controls, and ledger-enforced balances.
The three other layers above the ledger restrict what an agent can attempt, but the ledger is the strongest layer because it structurally prevents overspending and determines whether the money moves.
Prompt instructions are advisory text that the model can ignore, misread, or duplicate on retry. They can shape what an agent tries to do, but they cannot stop a debit because the lower layers handle the transaction enforcement.
Application-level checks create a concurrency race when the pre-flight balance read is a separate operation from the subsequent debit. Concurrent retries read the same earlier balance, both pass, and both execute. The counter and the money then live in different systems. This split between check and debit is the architectural gap that lets the race happen.
Card-level controls scope what an agent presents at the network, but they do not enforce a shared budget. Depending on the issuer's configuration, issuer-side controls decline transactions at the network level.
Card-level velocity limits and MCC (merchant category code) locks scope a card before an agent presents it. Velocity limits how often the card can be used, and MCC locks restrict which merchant categories it can transact with. A single-transaction virtual card locks one purchase to one use. Brought together, velocity limits, MCC locks, and single-use cards restrict what an agent is allowed to try before it tries anything.
As Simon Taylor has argued in Fintech Brainfood, agents will use cards first, then stablecoins, but whichever rail carries the transaction, the instrument-level controls sit above the shared budget.
Emerging mandate and token frameworks authorize purchases on a per-scope basis before execution, while shared budget consumption remains a ledger function. Simon Taylor's Agentic Payments Map lays out how these competing commerce, B2B, and agent-native protocols fit together above the payment rail layer.
Ledger-enforced balances post the budget movement and the spend as one atomic operation, which is the only rung that closes the concurrency race. The agent spends from a funded account and cannot overdraw it; if the source balance is insufficient, the posting fails and no money moves.
The reservation is modeled as a single posting that transfers funds from an available-balance account to a reserved-balance account, and the ledger commits the multi-account movement as a single unit. Double-entry enforcement keeps the posting balanced.
The account model and transaction logic can be inspected and run locally before production funds are committed. The ledger check runs independently of any separate application read, which goes stale the moment another agent posts. The core ledger is the system of record in which every disagreement between the layers is resolved in its favor.
Partial, layer-local blocks are not enough. Each upstream layer blocks what it can see, but the layer where the money moves is the only one that can issue an authoritative hard stop. Only a ledger-enforced balance closes that gap.
Controlling AI agent spend across a fleet requires nested budgets at the organization, team, user, workflow, and agent levels to collectively prevent overspending of a shared cap, with enforcement through a human-on-the-loop policy at scale.
A fleet needs nested budgets, organization → team → user → workflow → agent, and every parent balance movement must post as one unit alongside the child reservation.
When an agent reserves $5,000, the reservation consumes recorded headroom from its workflow budget, its owner's budget, the team budget, and the organization budget in a single transaction.
If checked sequentially, the parent caps reintroduce the concurrency race one level up. A fleet of agents, each within its own cap, collectively overspends the team budget they share. When the account model and transaction logic represent all levels in a single atomic posting, each unit of recorded parent headroom funds only one reservation.
Human-on-the-loop beats human-in-the-loop at fleet scale because policy, encoded as budget structure, runs at machine speed, while humans handle only the exceptions.
At tens of thousands of agent tasks per day, transaction-by-transaction approval is not humanly possible because it either blocks the fleet or encourages rubber-stamping.
A human-on-the-loop policy encodes policy as budget structure, with escalation only when thresholds are exceeded. The limits sit beneath the agent's reasoning, in the control plane, and secure fleet-scale agent execution.
An agent needs three runtime mechanics to operate under a ledger-enforced budget: it has to read its own remaining headroom, request more when it hits the ceiling, and escalate above-threshold spend to a human.
The one thing it must never be able to do is raise its own limit. That authority stays outside the agent, in the application layer or an approval workflow.
Reads return the current recorded balance directly from the ledger. That balance can change the moment another agent posts, so a read is only accurate at the instant it's taken.
A customer application sends typed increase requests to an approval queue and waits on the response. Budget-editing authority stays outside the agent. A granted increase is recorded as new funding to the agent's account and appears in the same history as every spend.
Above-threshold amounts route to a human approver before the reservation posts. The application or workflow gates the configured posting path and keeps the approval gate outside any optional flag in the agent's code path. Encoding the threshold in the gated path prevents an application path from bypassing the approver.
An AI agent spending limit becomes a hard block the moment it is expressed as a single Numscript posting (a purpose-built language for describing financial transactions) against a funded account. The reservation either records the entire transaction or fails, with no state written in between.
Consider a settlement agent with a $4,000,000 weekly cap that needs to reserve $1,200,000 for a batch. Two accounts hold the budget state before the agent initiates anything on an external rail:
The reserve leg, written in Numscript, moves $1,200,000 from the first account to the second in one atomic step:
// AGENT_BUDGET_RESERVATION
// Reserve USD 1,200,000 from the settlement agent's available budget.
// If @platform:agents:settlement:budget:available holds less than
// USD 1,200,000, the entire posting fails atomically: no funds move,
// no partial state is written, and the reservation is rejected.
send [USD/2 120000000] (
source = @platform:agents:settlement:budget:available
destination = @platform:agents:settlement:budget:reserved
)
set_tx_meta("event_type", "agent_budget_reservation")
set_tx_meta("reservation_id", "res001")
When the source account has sufficient funded headroom, the posting succeeds, and $1,200,000 moves from available to reserved in a single atomic step.
When the balance is insufficient, the Formance Ledger rejects the entire transaction: nothing is deducted, so nothing is reserved. The agent receives an insufficient-balance error that cannot be bypassed. Actual agentic payments then settle through the connected payment provider once the reservation is captured.
Six controls must hold before an AI agent posts to a production rail: a funded ledger account, atomic reserve-before-authorize, deduplication, parent-budget consumption, released holds on decline, and reconciliation against settlement.
With all six controls in place, an AI agent's spending limit stops being a hopeful instruction and becomes a hard structural constraint. There is no concurrent fleet that can breach a parent cap, no retry can double-spend, and no prompt injection can raise the ceiling.
How to control AI agent spend in production comes down to the underlying ledger that offers funded accounts, atomic postings, and nested parent budgets, all in a single system of record.