What Are Agent Spend Limits?

What is an agent spend limit?

Spend limits predate agents. Corporate cards and expense systems have long capped spending per transaction and per period. Agents change who makes the decision, and how often. An agent can make many purchases or paid calls in a minute, with no person approving each one, so the limit becomes the main control.

Limits show up at several layers. Card programs set them on the payment instrument: Stripe Issuing, for example, lets a platform set spending_limits on cards and cardholders, with amounts per authorization or over intervals such as monthly (Stripe Issuing spending controls). Agent payment protocols carry them in the authorization itself: in Google's Agent Payments Protocol (AP2), an open Payment Mandate "Captures the user's constraints on payment (e.g., budget, allowed instruments) for autonomous execution." And the platform running the agent usually keeps its own budgets, per agent, per team and per tenant, before any payment rail is involved.

Tacnode treats agent spend as a case of contended, unmergeable state: a shared total that several agents decrement at once and that cannot be reconciled after the fact. In its framing, per-agent limits, holds and spend records are decision state, written by the decisions themselves and read by the next ones.

How agent spend limits work

A limit check has three parts: the cap, the amount already committed, and the new request. The cap is easy. The committed amount is where limits fail, for two documented reasons. Stripe's docs note that "Spending aggregation is done on a best-effort basis. You might notice a delay of up to 30 seconds between spend occurrence and spend aggregation," and that "Additional tips and fees can be posted at a later time, causing a spending limit to be exceeded" (Stripe). In other words, the total can lag the spend, and the final amount can differ from the amount approved.

A platform-side limit that holds up under concurrency records a hold for each approved spend and checks the cap against committed holds in the same transaction:

BEGIN;
-- lock the agent's limit row so concurrent checks for this agent queue
SELECT cap FROM agent_limits WHERE agent_id = $1 FOR UPDATE;

SELECT coalesce(sum(amount), 0) AS committed
FROM   spend_holds
WHERE  agent_id = $1
  AND  period = current_date
  AND  status IN ('held', 'settled');

-- approve only if committed + $2 <= cap
INSERT INTO spend_holds (agent_id, period, amount, status, request_id)
VALUES ($1, current_date, $2, 'held', $3);
COMMIT;

When the real cost arrives, the hold is settled at the actual amount. A unique constraint on request_id makes retries idempotent, so a retried call cannot place a second hold.

A single per-agent cap like this is a solved problem: a row lock serializes it. It gets hard when the check spans more than one total: a per-agent cap inside a team budget inside a tenant budget, spend summed across regions, or holds that settle later at different amounts. Each agent then reads several derived totals, and each can trail the commitments it should include.

Why agent spend limits matter in real-time systems

A limit written into an agent's prompt is a request, not a control; the check has to run in code, before the spend. And a check that reads a lagging total is a control with a hole in it, largest exactly when many agents spend at once.

Where the limit lives decides what can be guaranteed. For limits, holds and spend records Tacnode holds, writes are transactional, so two agents cannot both commit spend past the same cap. For a card issuer's or payment network's own ledger, Tacnode enforces nothing; it gives the agent's decision accurate, current context, so the agent doesn't request what it would have declined had it seen the full total. The issuer's controls still apply on their side. Concurrency for agent decisions is covered in ACID for agents.

FAQ