Rate limits are product decisions, and AI agents just became your biggest customers

Ask a team what their API rate limit is and you’ll often get one number, picked years ago. But a gateway like Apigee has two very different kinds of limits, and mixing them up causes most of the problems.

Protection limits vs. business limits

Protection limits keep your systems up. They smooth out bursts, whoever is sending them. In Apigee this is the SpikeArrest policy: it spreads traffic evenly over time (for example, 100 requests per second becomes roughly one request every 10 ms) and rejects requests that arrive faster. It’s a shock absorber, not a quota. Size it to what your backend can actually handle.

Business limits define what a customer is entitled to. In Apigee this is the Quota policy, usually tied to an API product: “the free tier gets 1,000 calls a day, partners get 1,000,000 a month.” These are product decisions. They belong to whoever owns pricing and partnerships, and they should be documented like any other part of the offering.

Mixing them causes familiar problems: a partner’s legitimate batch job is blocked by a burst limit meant for abuse, or one customer’s runaway script uses up capacity that was supposed to be shared.

What changed: agents as API clients

In 2026, a growing share of API traffic comes from AI agents acting for users. Agents behave differently from both humans and traditional integrations:

• They’re bursty and persistent. An agent working through a task may make dozens of calls in a few seconds, and it will retry failures tirelessly unless told not to.
• They multiply. One customer may run many agents, each with its own loop, all sharing one API key.
• They read your error messages. A good 429 response with a clear Retry-After header changes how an agent behaves. A vague 500 makes it try harder.

Design limits for agent traffic

• Identify agents explicitly. Issue separate credentials or API products for agent access, so their traffic can be measured, limited and priced separately from human-driven use.
• Limit by cost, not just by count. One call that triggers an expensive search or AI model isn’t the same as a cheap lookup. Weight quotas by what requests cost you to serve.
• Return useful refusals. 429 Too Many Requests with Retry-After and a short message about the limit. Well-built agents back off correctly when told how.
• Protect write operations separately. Reads can be generous. Actions that change data, send messages or spend money deserve tighter limits and, often, an idempotency key requirement so a retried action isn’t performed twice.

Make limits visible

Customers, human or agent, shouldn’t find limits by hitting them. Publish them, return remaining quota in response headers, and give partners a way to see their usage. Internally, alert when a customer is consistently near their limit: that’s a sales conversation or an architecture conversation, and either is better than an angry support ticket.

A rate limit is the clearest statement an API makes about who it’s for and how much they can rely on it. Write it as deliberately as a price list, because increasingly that’s what it is.