Post Your First Mandate-Scoped Agent Hold
Start with Formance Ledger as the system of record, then post an agent-initiated hold with a mandate ID in the posting metadata to enforce the balance and retain the mandate chain.
Agentic commerce is software with delegated spending authority acting on behalf of a human. Instead of clicking checkout once, the human issues a mandate and the agent transacts inside it, sometimes for hours, sometimes for an entire procurement cycle.
The category is small today and set to grow. The transaction value of agentic commerce is projected to grow from $8 billion in 2026 to $3.5 trillion by 2031, with agent users rising from fewer than 300 million to 1.3 billion.
But handing an agent that kind of authority opens a failure mode a human checkout never had. A procurement agent calls the payout endpoint, the rail returns a 503, and the agent retries. A second copy of the agent tries again with a new request ID, then the ledger records both, and the duplicate payment shows up three days later on the supplier's statement. The agent cannot decide whether the money already went out.
In this case, the ledger, and not the agent, must remain the system of record. Payment protocols cover how the agent proves it's allowed to spend, but they don't tell the ledger how to record the payment, avoid duplicates, or reconcile it later. Those rules are the operator's problem.
Agentic commerce is software that holds delegated authority over money and executes spending decisions within a scope defined by a human.
An AI agent receives a budget, an allowed set of counterparties, and a validity window from the human. The agent then finds purchase options and executes payments inside the mandate scope without a human approving each transaction.
Delegated authority changes what a payment system must defend against. A human checkout produces one authorization for one amount at one moment, while a delegated agent produces a stream of authorizations against a shared envelope, retries on failure, and runs in parallel with copies of itself. The one checkout click turns into a standing permission to spend, and the agent can stay live for hours, days, or a whole procurement cycle.
The agent requests transactions and is never the system of record. Any architecture that lets the agent's own state decide whether money has moved will eventually post the same capture twice, send a duplicate payment, and surface the error days later during reconciliation when it flags the mismatch.
An agent transaction moves through a six-step lifecycle: mandate, evaluation, hold, capture, finality, and reconciliation. The ledger records each transition as its own posting with the mandate attached. Formance Ledger is one open-source implementation of the operational-ledger model, and the six-step lifecycle uses it as the reference posting engine.
Every live agentic payment protocol specifies authorization evidence. Agent Payments Protocol (AP2) signs mandates, Agentic Commerce Protocol (ACP) issues scoped tokens, and x402 signs payment payloads over Hypertext Transfer Protocol (HTTP).
No protocol specifies ledger posting, so the ledger operator decides which account is debited when a hold is placed, how a capture consumes the hold, and what happens to captured funds when the mandate is revoked.
The mandate is a signed authorization that the agent cannot widen. It carries a budget, an allowed set of counterparties, and a validity window.
AP2 is the closest protocol analog. AP2 represents a purchase as three signed credentials (an Intent Mandate, a Cart Mandate, and a Payment Mandate), each a Verifiable Credential. Regardless of the protocol, the mandate ID is the key every downstream record joins on.
Policy evaluation runs at posting time against the live envelope. It uses the agent ID, mandate ID, and policy version carried in the agent's request.
Timing matters with request submission. An agent may plan a $412,000 payment at 09:00 against a $2.5 million envelope, but by 09:40, sibling sub-agents may have spent $2.3 million of it, or the human may have revoked the mandate.
Only the check at posting time counts, and the result is itself a record the ledger keeps.
Before calling the rail, the ledger moves funds from the approved available balance into a hold account named for the mandate. It's a real double-entry accounting posting into a mandate-specific hold account, so the remaining envelope is a ledger balance. It is not a counter the agent tracks in memory. If the account is short, the posting fails, and the agent never reaches the rail.
Enforcing double-entry at the storage layer keeps the hold safe under concurrency because two sibling agents can't both use the funds. Application-layer checks don't give you that guarantee.
When the agent captures a payment, the rail needs a way to spot duplicates. The idempotency key belongs to that job, and it has to come from the ledger. The ledger assigns a transaction ID when it accepts the capture, and that ID (or a hash of it) is what gets sent to the payment rail.
The agent doesn’t generate the key because an agent-generated universally unique identifier (UUID) is different every time. A retry gets a new one, and a sibling agent gets a new one, so the rail sees two different keys and treats them as two different payments.
A ledger-derived key stays the same across every retry of the same posting, which is what idempotency guarantees actually need.
ACP's payment specification shows the pattern to copy. ACP requires an Idempotency-Key header on every request and returns idempotency_conflict with HTTP 409 when the same key shows up with different parameters.
The capture below is written in Numscript, Formance’s transaction language. Acme's spendable funds sit at @buyers:acme:available, the mandate hold sits at @buyers:acme:hold:7f3a, and the supplier liability sits at @sellers:northwind:payable.
Step 3 has already funded the hold with the $2,500,000.00 mandate envelope. Numscript captures a $412,000.00 payment to the supplier and stamps the posting with the metadata reconciliation will need.
// AGENT_PAYMENT_CAPTURE
// Event: capture $412,000.00 from Acme's mandate hold for Northwind
send [USD/2 41200000] (
source = @buyers:acme:hold:7f3a
destination = @sellers:northwind:payable
)
set_tx_meta("event_type", "agent_payment_capture")
set_tx_meta("payment_id", "po_7c91")
set_tx_meta("agent_id", "procure-agent-14")
set_tx_meta("mandate_id", "mandate_7f3a")
set_tx_meta("policy_version", "42")
set_tx_meta("principal_id", "acme")
set_tx_meta("execution_attempt", "1")
set_tx_meta("rail_reference", "psp:provider:po_7c91")The capture can't pull more than what's in the hold account, so the envelope enforces itself. The integration layer sends the transaction ID (or a stable hash of it) to the payment provider as the idempotency key.
It also saves the provider's reference transaction as rail_reference metadata, so the two sides of the payment link without a separate lookup table.
The rail accepting a payment request is not the same as the money settling. The ledger must record settlement evidence explicitly before anything downstream runs against it.
The gap between acceptance and settlement is where duplicate payments and reversals live. If a dependent action fires on acknowledgment alone (releasing goods, triggering a follow-on transfer, or marking an invoice paid), a later settlement failure leaves the ledger out of sync with the money.
Wait for the settlement record, then finalize the payment.
Reconciliation matches every ledger posting to rail and settlement evidence. Any mismatch goes to an exception queue for a human or a policy rule to close. The agent never resolves it.
Take a retry case: a sub-agent captures $412,000, the rail returns a 503, and the sub-agent retries with the same ledger-derived key. The integration reuses the original ledger transaction instead of submitting a second capture, and the rail returns its original acknowledgment.
If the rail response is ambiguous, like a timeout with no acknowledgment, the posting stays pending and enters the exception queue. The agent's job ends at the request, so a human or a policy rule closes it out instead.
Safe agentic commerce requires four architectural pieces enforced at the ledger. The four requirements are actor separation, mandatory posting metadata, five-record reconciliation, and governance-aware ledger controls.
The ledger requires four actor roles to stay separate: the human, the agent, the policy layer, and the execution infrastructure. No role does another role's job.
The human owns the mandate and can cancel it at any time. The agent sends requests and carries ID tags, but has no authority of its own.
The policy layer holds the rules the agent must follow; the agent can read them but can't change them. The execution infrastructure checks the limits when the payment posts and hands the instruction to the rail.
Every payment an agent kicks off needs to carry six tags: agent ID, mandate ID, policy version, human ID, attempt number, and rail reference.
The mandate ID and policy version tie a settled payment back to the permission that allowed it and the rules in force when it cleared. Without them, teams end up digging through agent logs to prove to an auditor that a payment was allowed.
The agent ID and human ID address which agent submitted the request, and on whose behalf. The attempt number tells a real retry apart from a second copy of the agent submitting fresh, which is the first question an auditor will ask when the rail shows one payment and the request log shows two.
The rail reference links the ledger posting to the provider's own record, so the two sides of the payment reconcile without a separate lookup table.
Reconciling agent payments requires lining up five records: the agent's request, the policy decision, the ledger postings, the rail instruction, and the settlement evidence.
With human checkouts, an operations team could clear the day's exceptions by hand every morning. Agentic commerce agents increase volume, creating thousands of small payments against shared budgets and increasing mismatches that no team can work through.
Reconciliation resolves the volume increase because each record proves something different, and mismatches point to different failures:
The mismatches tell you where the process broke. A policy decision with no matching ledger posting means the hold never funded. Two rail instructions tied to a single ledger capture means the same key reached the rail twice, which is the duplicate-payment case the ledger-derived key exists to prevent.
Governance-aware ledger controls are the balance limits, state transitions, and metadata guarantees that settle cap spending, revoke a mandate mid-flight, and produce an audit trail regulators can accept.
No standards body has decided who's liable when an agent spends outside its mandate. Liability in law rests on a legal persona assumption: either a human or a company stands behind an action, which is a bar an AI agent doesn't meet. No regulation yet assigns the loss when an agent exceeds scope, leaving the ledger's metadata as the only defensible record of who authorized what.
Humans issuing mandates want two things: a spending cap and a kill switch. The ledger enforces the spending cap with a balance limit on the hold account, so no capture can exceed what the mandate reserved.
It enforces the kill switch the same way: revoking a mandate moves the hold account from active to revoked in one write, and every capture request is checked against that state before it can succeed.
Agentic commerce only works if the ledger backing it can prove, on demand, who authorized every payment an agent made. Every agent-initiated transaction must be traceable to a principal, mandate, policy version, and settlement record.
Here's the test: pick any agent payment from last quarter and ask: Who authorized it? Under which mandate? Against which policy version? How did it settle? If the answer requires digging through agent logs or opening a rail dashboard, the audit fails.