How do I stop several AI agents from overspending a shared team budget when they pay at the same time?

What should I check, step by step?

1. Put the team pool in one place that every agent's payment path goes through: a row in your database, a ledger service or the card issuer's cardholder limit. Not a number in each agent's context.

2. Track three numbers for the pool: limit, settled and held. Available is limit minus settled minus held.
3. Reserve before paying with a single conditional write, for example UPDATE pool SET held = held + :amount WHERE id = :pool AND limit - settled - held >= :amount, and treat zero rows updated as a deny. Don't read the balance in one call and write the hold in another.
4. Give each hold an id, the agent, the amount, the merchant and an expiry. Pass the hold id as the payment's idempotency key or reference so a retry reuses the hold instead of taking a second one.
5. On settlement, move the hold to settled at the settled amount (it may be lower, or higher after tips and fees). On cancel, decline or expiry, release it. Run a sweeper so holds from crashed agents expire instead of locking the pool forever.
6. Give each agent its own ceiling too: issue_agent_credential plus set_spend_policy with per_tx_max_minor and daily_max_minor, so one runaway agent can't drain the whole pool before the others get a turn.
7. Call authorize_spend for the agent's credential after the pool hold succeeds, with reference set to the hold id, so the per-agent decision and the pool hold point at each other in the record.
8. Keep the card limit as the outer backstop (a Stripe Issuing cardholder limit covers all of that cardholder's cards), and reconcile holds against card authorizations and captures daily.

Why isn't a remaining-balance number a lock when several AI agents share one budget?

Each agent sees the balance as it was when it last read it. When two agents read, decide and pay in parallel, both reads can be correct and the total still overspends. Databases call this check-then-act race write skew: PostgreSQL's isolation docs show two transactions that each read a sum and then write a row, and both commit under Repeatable Read; only Serializable rolls one back.

• A conditional UPDATE avoids that without special isolation. Under PostgreSQL's default Read Committed level, a second UPDATE on the same row waits for the first to commit, then re-checks its WHERE clause against the updated row. If the hold no longer fits, it updates nothing, and that is your deny.
• Telling agents to check with each other, or giving them a shared notes file, has the same flaw: there's still a gap between reading and paying.

How do I hold and release a shared team budget when AI agents pay concurrently?

A hold is what card networks already do. Stripe's docs describe placing a hold that reserves funds and capturing later, with online card authorizations usually valid for 7 days; if not captured in time the funds are released. On Stripe Issuing, an approved authorization holds the amount and capture releases the hold and posts the transaction.

• Settled can differ from held. Stripe Issuing allows partial capture (less than authorized) and, in some merchant categories such as restaurants and ground transportation, over capture, and its spending controls note that tips and fees can be posted later and push spend past a limit. Settle the pool at the captured amount and keep headroom for categories that over-capture.
• Holds need an owner and an expiry. If an agent crashes between reserving and paying, its hold should lapse on a timer (a few minutes for API calls, longer for orders that capture days later) rather than wait for someone to notice.

What does Rightshold do for a shared team spend pool used by several AI agents?

set_spend_policy puts a per-transaction and daily cap on one agent credential, in one currency. authorize_spend reads that credential's total for the UTC day and records the allow or deny in one synchronous step on the server, so allows on the same credential can't race each other, and the signed receipt shows the total before the decision.

• An allow counts toward the daily cap as soon as it's recorded and isn't released if the purchase never happens: it stays counted until the day resets at midnight UTC. Merchants should accept the receipt only before its valid_until, 15 minutes after it was issued.
• There's no team pool with holds and releases across several credentials in authorize_spend. Build the pool reservation in your payment service or at the card issuer, use Rightshold for each agent's ceiling and the signed decision record, and put the hold id in reference so an auditor can match them.