AI Agents Are Now Your Biggest API Consumer

The infrastructure sitting in front of your APIs was designed around assumptions about who would be calling.

A human, behind a browser or an app. Predictable pacing, because a person can only click so fast. Retries governed by client code somebody wrote deliberately. One user action producing a small, bounded number of requests.

Every one of those is now partially false, and the proportion is rising.

What agent traffic looks like

When a model calls your API on behalf of a user, the shape is qualitatively different — not merely larger.

It opens with a burst of exploratory calls, working out what data exists. Then a tight sequence of dependent requests. Then nothing for several minutes. Then another burst.

It retries differently. Human-written clients have backoff discipline because a developer thought about it once. An agent retrying a failure may try a slightly different request rather than the same one, which defeats idempotency-key deduplication.

It reads your documentation — schema endpoints, OpenAPI specs, discovery routes — at rates no human integration produced, because a model genuinely re-reads the schema before constructing a request.

And it fans out. One logical action — "reconcile these invoices" — becomes forty API calls. Capacity models built around requests per user session stop describing anything real.

Three assumptions that broke

Request counts stopped tracking cost.

Rate limiting has always been expressed in requests per unit time, and that worked because human traffic distributes fairly evenly across endpoints. Agents do not. An agent optimising for task completion finds whichever endpoint yields the most useful information and concentrates there — and if that route triggers an expensive aggregation, your limit of a thousand requests an hour now permits something very different from what you intended.

The fix is cost-weighted limiting: assign each route a weight reflecting downstream cost, and budget consumers against the weighted total.

GET  /v1/items            weight: 1
GET  /v1/reports/summary  weight: 40    # scans, aggregates
POST /v1/exports          weight: 100   # spawns a job

Weights do not need precision — ordinally correct and roughly proportional captures nearly all the benefit. Support varies enormously across tools, which makes it one of the few genuinely discriminating criteria in a category where most features reached parity years ago.

Error messages became a cost centre.

A human developer receiving an opaque 400 Bad Request opens the documentation, works out what was wrong, and fixes their code. Once.

An agent receiving the same response cannot diagnose it easily. It retries, possibly with variations, possibly many times. A descriptive error — what was wrong, which field, what values are valid — lets it self-correct on the next attempt.

Error message quality now has direct cost implications, which is an odd sentence and a real consideration.

Identity became a three-way question.

When a call arrives from an agent, acting for a user, orchestrated by a platform, authenticated with a service credential, "who is this" has at least three defensible answers — and you want different ones depending on the question:

permissions  → the end user
quota        → the platform or tenant
billing      → the account holder

Tooling supporting only per-key attribution collapses these into one, which is wrong in a way that stays invisible until a billing dispute or an access incident.

Delegated authorisation used to be an exotic requirement. It became ordinary in about eighteen months.

What this changes commercially

Your traffic forecast is less reliable. Volume used to track user growth. It now tracks user growth multiplied by however much agent-mediated interaction your customers adopt — a variable nobody forecasts confidently. If you are on per-request pricing, model at three times current volume rather than at trend, and ask how the pricing behaves on bursts.

Your selection criteria should have shifted. Feature parity arrived years ago, so comparison matrices are largely uninformative. What discriminates now: expressiveness of rate limiting, quality of the delegated-authority story, and whether trace context survives the gateway intact. Three questions you can put to a vendor in a trial, and they separate a shortlist faster than any datasheet.

What did not change

Most organisations still need a gateway rather than a full platform.

Traffic control, authentication and telemetry for a known consumer set is a gateway problem. Developer portals, self-service credentials and usage billing are for businesses selling APIs as a product. Agent traffic makes the first set harder; it does not make the second set necessary.

And the portability discipline holds. Keep business logic out of the edge — gateways should route, authenticate, limit and observe. Every custom plugin is portability you spent without deciding to, and plugins are what turn a few weeks of migration into a major project.

Full guide — the five capabilities that matter, deployment topology, open source versus commercial, and a selection framework: API Management Tools in 2026. If you are mid-selection and want an outside read, we are happy to talk.

Frequently Asked Questions

How is agent traffic different from normal API traffic?

Bursty rather than paced, retries harder and with variation, reads schema and documentation endpoints heavily, and fans one user action into many calls. Capacity models built around requests per session stop matching reality.

Why does request-count rate limiting fail?

Because agents do not distribute evenly across endpoints. They concentrate on whichever route is most useful, and if that route is expensive, a fixed request budget permits far more cost than intended.

What is cost-weighted rate limiting?

Assigning each route a weight reflecting its downstream cost and budgeting consumers against the weighted total rather than a raw request count. Weights need to be ordinally correct, not precise.

Do error messages really affect cost?

For machine callers, yes. An opaque error gives an agent nothing to correct with, so it retries repeatedly. A descriptive error naming the field and valid values lets it self-correct, which shows up directly in retry volume.

What is the delegated authority problem?

When a call comes from an agent, for a user, through a platform, on a service credential, permissions, quota and billing each have different correct answers. Per-key attribution collapses them, which surfaces during billing disputes or access incidents.

Does this change whether I need a platform or a gateway?

No — most organisations still need a gateway. Agent traffic makes traffic control harder without making developer portals and usage billing necessary. It changes the evaluation criteria more than the tier.