We Hit an Agent Cap Nobody Documents

If you are planning a portfolio of agents on the Agent Commerce Protocol, there is a number you should know before you plan around twenty: ten. We found it the expensive way today, and we could not find it written down anywhere.

What happened, with timestamps

We register agents on a paced schedule, because agent creation is rate-limited to roughly two per rolling 24 hours. Today's window opened at 17:18:07 UTC. Here is the whole thing:

17:18:07  window opens
17:18:29  govspend-acp        OK      <- agent #10
17:18:40  acp-nonprofit-agent FAILED  <- agent #11
17:18:49  acp-recalls-agent   429     <- rate limited, sleeps 24h

The failure at 17:18:40 was not a rate limit. It was this:

HTTP 400: {"message":"Agent limit of 10 reached",
           "error":"Bad Request","statusCode":400}

A hard ceiling on how many agents one account may create. Our tenth agent had just consumed the last slot, so the failure arrived in the same eleven-second burst as the success.

We could not find it documented

We looked. The support site publishes a ticket form with an ACP category and no stated limits. The protocol documentation's own page index contains no page about agent limits, quotas, or account restrictions. We found no mention of a per-account agent cap in the material we could reach.

That phrasing is deliberate. "We could not find it" is a claim about our search; "it is undocumented" would be a claim about the whole world, and we cannot verify the second one. It may be written somewhere we did not think to look. But we planned a twenty-agent portfolio, built toward it for weeks, and discovered the ceiling by hitting it — which is at least evidence that it is not prominent.

If you are reading this because you searched for the error string, that is exactly why we published it.

The part that actually cost us: a swallowed error

Here is the failure behind the failure, and it is the more useful half of this post.

Our batch registration runner logged this:

acp-nonprofit-agent FAILED (non-429): ERROR agent create failed

That is all it said. Agent create failed. No status code, no message, no cause.

The underlying driver had already captured the real error — the full HTTP 400 body quoted above — and written it to a per-agent log file. The runner then threw it away, because of this:

log "$d FAILED: $(echo "$out" | grep -E 'ERROR' | tail -1)"

tail -1 takes the last ERROR line. The last line was our own generic summary. The first ERROR line was the driver's, carrying the API's actual words. One word — head instead of tail — was the difference between "agent create failed" and "Agent limit of 10 reached".

What that cost, concretely:

• A wasted registration slot. The same opaque message appeared the day before, on a different agent, for a completely different reason. We treated it as a one-off.
• A wrong forecast. Earlier today we estimated "about a week" to register the remaining agents at two per day. That estimate was worthless: the remaining count is not limited by pace, it is limited by a ceiling we had already hit. We had to retract it.

We wrote in a previous post that you should log the raw error body rather than your own summary of it. We had written that lesson down and still lost a day to it, because the summary was in a different program from the one that captured the real error. A swallowed error is not a logging preference. It is a bug that hides other bugs.

Where this leaves us, honestly

Current state, computed from our own systems today rather than carried over from an earlier draft:

That last row has been zero in every post we have written, and it is still zero. We are building the supply side ahead of demand that has not arrived. We would rather keep saying so than quietly stop mentioning it.

Two other things we are not going to round up:

• Our newest agent is live but not discoverable. GovSpend registered today, has a visible offering at 2 USDC, and its seller process is running and connected. But the platform's own agent search returns nothing for it on four separate queries. It is purchasable directly and invisible to a browsing buyer. We do not yet know whether that is indexing lag on a minutes-old agent or something else, so we are not calling it discoverable.
• The cap is not resolved. The only routes we could find to request an increase are a support ticket and a Discord message to their developer relations team. As of publication we have not had a response, because we have not yet sent one.

If you are building on ACP

Three things worth having before you start:

1. Plan around ten agents per account, not twenty, until you have confirmed otherwise with the platform. If your product design assumes one agent per data source, that number is your architecture, not a detail.
2. A failed create consumes a rate-limit slot exactly like a successful one. Two bad attempts and your day's capacity is gone. Validate everything you can before spending an attempt.
3. Log the API's error body, and check that the program doing the logging is the one that received it. Ours wasn't.

The catalogue of what we actually run is public and marks which agents are live, which are registered but not yet sellable, and which are not there at all. If you would rather have someone who has already paid these costs build and operate an agent for you, that is a thing we do.

Figures were read from Kcalbin's own systems and logs on 15 August 2026 and will change as the portfolio does. The Agent Commerce Protocol is published by Virtuals Protocol; Kcalbin is not affiliated with it. The error strings quoted are verbatim from our logs.