Pink data: 3 AI agents, 40 concurrent payments, one $6,000 daily limit. Did it hold?

Pink Agentic AI Payments enforces a shared company daily ceiling across all of a company's agents before a payment executes. We wanted to know what happens when 3 different agents hit that shared ceiling with concurrent requests at the same time, instead of one agent spending alone.

What we tested

Pink Agentic AI Payments is an MCP server and REST API that sits between AI agents and company money: an agent asks to pay someone, and a set of plain-language rules (per-agent budgets, per-payment caps, a shared company daily ceiling, payee lists, human approval for anything unusual) decides allow, block, or ask-a-human before any payment goes out. There's a free public sandbox with fake money at https://agentic-sandbox.pinkwallet.com, no signup required.

The question: if 3 agents fire a lot of payment requests at the same time, does the shared daily ceiling actually stop the company's total spend at the limit, or can concurrent requests slip past it before the running total updates?

Method

Using the sandbox's coffee template (seeds 4 agents sharing one company_daily_ceiling, here $6,000), we used 3 agents (a_purch, a_inv, a_pay) and deliberately kept each agent's own monthly budget and per-payment cap far out of reach, so the only rule that could block a request was the shared ceiling. We then fired 40 POST /v1/payments requests from all 3 agents concurrently (one thread pool, no delay between them), for a requested total noticeably above the $6,000 ceiling, and checked:

1. Client side: how many requests came back allowed vs blocked, and the allowed dollar sum.
2. Server side: GET /v1/budget → company_spent_today, which should match the client-side allowed sum exactly if the ceiling held.
3. The exact rule and why text on every blocked request.

We ran this three times against the sandbox on 2026-10-12: two earlier runs in the same workspace (the second after resetting the day), and a third fresh run using the cleaned-up, public version of the script (see "how to reproduce" below).

Results

In every run, the client-side allowed sum matched the server's own company_spent_today exactly, and the total never went over the $6,000 ceiling.

Every single blocked request across all three runs cited the shared ceiling specifically, not a per-agent rule. The exact response body looked like this:

{
  "agent_id": "a_pay",
  "requested_amount": 210,
  "status": 403,
  "decision": "blocked",
  "rule": "Company daily ceiling reached",
  "why": "$5,840 + $210 > $6,000"
}

The why text shows a running total that increments across requests from different agents (a_purch, a_inv, a_pay all draw against the same counter), which is what you'd expect from a shared, not per-agent, ceiling.

Reconciliation

For run 3 (the one you can reproduce yourself): client allowed_sum ($5,840) + spent_before ($0, fresh workspace) = $5,840, and the server's own GET /v1/budget reported company_spent_today = 5840 after the burst. Same number, two different sources (what the client counted vs what the server's ledger says). That's the check that matters here: if the running total were only checked after the fact, or if concurrent requests raced past each other before the counter updated, you'd expect the allowed sum to land above $6,000 at least sometimes. We did not observe that in any of the three runs.

How to reproduce in 2 minutes

The cleaned-up script is public: 11-shared-ceiling-test in sandbox-examples. It creates its own disposable sandbox workspace, reads each agent's budget, plans the request amounts itself, and asserts the two checks above.

pip install requests
python3 shared_ceiling_test.py

No signup, no API key to configure, no money at risk, it's the public sandbox.

Limits

• This is the public sandbox only: fake money, test credentials. Production is not covered by this test.
• One template (coffee), 3 agents, 40 concurrent requests, a handful of runs on one day. This is not a large-scale concurrency stress test with hundreds of parallel agents, and it only exercised one sandbox instance.
• This describes what the API returned, not how the ceiling check is implemented internally. We can't rule out that a much higher concurrency level, or a distributed deployment, behaves differently from what we saw here.

Disclosure

I work on Pink at PinkWallet.