Your Internal Platform's New Primary Customer Is an Agent

Your platform team measures success by developer adoption. Monthly active engineers on the internal API. Time-to-first-call for a new service. Net promoter score from the quarterly DX survey. Every one of those metrics assumes a human is on the other end of the request — someone who reads a getting-started guide, copies a curl example, and grumbles in Slack when the error message is unhelpful.

That assumption is quietly becoming false. The fastest-growing consumer of your internal APIs is not a person. It's an agent: a coding assistant resolving a ticket, a workflow that reconciles invoices overnight, a support bot that calls six services to answer one question. These callers don't skim your docs — they ingest your tool schemas into a context window. They don't file a bug when an error is cryptic — they silently retry, burn tokens, and give up. And they are about to outnumber the humans.

The data already shows the gap. In the 2025 State of the API survey, only 24% of developers said they actively design APIs with AI agents in mind, while 51% flagged unauthorized agent access as a top security concern. We are anxious about agents hitting our APIs but largely not designing for them. That mismatch is the whole story of the next two years of platform engineering: the dominant consumer is arriving faster than the interfaces are being adapted to serve it.

Agents Fail Differently Than Humans Do

The instinct is to say "an API is an API — if it works for a human script, it works for an agent." That instinct is wrong, and the failure modes are specific.

A human developer reads your endpoint once, builds a mental model, and writes code that encodes that understanding permanently. The cost of comprehension is paid once. An agent re-derives its understanding on every invocation from whatever you put in front of it — the tool name, the parameter descriptions, the shape of the response. There is no persistent mental model. The interface is the documentation, and it gets re-read on every call.

This changes what "good" means. Consider three concrete divergences:

• A human tolerates a UUID in a response; an agent pays for it. When your endpoint returns {"owner_id": "a3f9...", "project_id": "b7c2..."}, a human script threads those IDs through follow-up calls without thinking. An agent has to either make another round-trip to resolve each ID into something meaningful or hallucinate what they refer to. Returning owner_name and project_name alongside — or instead of — the raw IDs eliminates an entire class of wasted calls.

• A human reads a 404 and infers the fix; an agent needs the fix spelled out. HTTP 400: invalid_argument tells a person to go check the docs. It tells an agent nothing actionable, so it retries the same broken call or abandons the task. An error that says "start_date must be ISO-8601; you sent 06/20/2026, try 2026-06-20" turns a dead end into a successful second attempt.

• A human ignores fields they don't need; an agent pays attention tax on all of them. Every field you return lands in the context window and competes for the model's attention. A response with 40 fields when the task needs 4 isn't just wasteful — it actively degrades the agent's reasoning by diluting the signal.

The pattern underneath all three: humans have free, persistent, out-of-band comprehension. Agents have expensive, ephemeral, in-band comprehension. Design that ignores this ships interfaces that technically work and operationally fail.

The Context Window Is Your New Rate Limit

Here is the constraint that almost no internal platform team has internalized yet: an agent has to know your tool exists before it can call it, and "knowing it exists" costs tokens.

The numbers are sobering. Seven typical MCP servers loaded into an agent consume around 67,300 tokens of tool definitions — roughly a third of a 200k context window — before the user has typed a single word. A large enterprise MCP server exposing 400 tools can consume over 400,000 tokens just to describe itself, which doesn't even fit in the window. Your beautifully comprehensive internal toolkit, exposed naively, can be too large for an agent to load at all.

This is a brand-new failure mode for platform teams. Historically, adding a 401st endpoint to your API was free — nobody loads all your endpoints at once. A human reads the one page they need. But the default way agents discover tools is to load every definition upfront, so each tool you add taxes every agent session, whether or not that tool is ever called.

The industry responses that shipped through late 2025 and into 2026 all attack this same wall:

• Progressive disclosure / tool search. Instead of dumping every schema into the prompt, the agent searches for and loads only the tools it needs for the current task. Anthropic's Tool Search Tool reported an 85% reduction in token usage from this pattern alone.
• Code execution over MCP. Rather than exposing each operation as a separate tool call, present your services as a code API the agent writes against. It imports only what it needs and processes intermediate data in the execution environment instead of round-tripping every result through the context window. Anthropic measured one workflow dropping from 150,000 tokens to 2,000 — a 98.7% saving — by moving from tool-call orchestration to code execution.
• Token-based metering and gateways. API gateways from Kong, AWS, and Zuplo added token metering and identity primitives that distinguish humans from services from agents, because billing and quota now have to be reasoned about in tokens, not just requests.

Loading…