We're watching thousands of APIs get designed for humans when they should be designed for agents. The result is a mess that's about to force the biggest rethink of service interfaces since REST displaced SOAP.
The problem isn't that we have too many APIs — it's that we have too many APIs that do too little. Every startup ships with dozens of endpoints that mirror their UI components rather than their actual capabilities. An e-commerce platform might have separate endpoints for product search, inventory check, price calculation, tax computation, and order placement. That made sense when humans were calling these APIs through carefully crafted applications. It makes no sense when an AI agent is trying to "buy the cheapest laptop under $800."
The Token Economics Problem
AI agents pay for every API call in two ways: the actual HTTP request and the tokens needed to understand and orchestrate multiple calls. Current API designs force agents into expensive conversation chains.
Consider a simple task: "Find and book the earliest flight to Denver under $300." With today's airline APIs, an agent needs roughly 6-8 API calls: search flights, get detailed pricing for candidates, check seat availability, calculate taxes and fees, initiate booking, add passenger details, process payment, confirm reservation. Each call requires the agent to parse responses, maintain state, and decide on the next action.
That's 6-8 round trips at ~200ms each, plus token costs for the agent to process each response. The agent burns tokens on JSON parsing, error handling, and state management instead of the actual task logic. We're optimizing for the wrong thing.
A better airline API would expose a single fulfill_travel_request endpoint that accepts natural language constraints and returns actionable options or completed bookings. The complexity moves server-side, where it belongs.
The Authentication Cascade
Current APIs assume authenticated sessions with long-lived tokens or cookie-based auth. AI agents don't have sessions — they have tasks. Every API call becomes an authentication decision.
We're seeing agents spend significant overhead managing OAuth flows, refresh tokens, and session state across dozens of services. Some agents store credentials in ways that violate service ToS. Others re-authenticate for every request, burning rate limits.
The winning API design will support task-scoped authentication: temporary credentials that live exactly as long as the agent needs to complete a specific job. Issue a token for "book a flight to Denver," not "access our flight booking system." When the task completes, the token dies.
Rate Limits Weren't Designed for Agents
API rate limits assume human usage patterns: bursts of activity followed by idle time. Agents don't take coffee breaks. They make steady, predictable calls at whatever rate maximizes their efficiency.
Most APIs implement naive rate limiting: X requests per minute per API key. This forces agents into artificial delays or complex request batching. We've seen agents that spend more code on rate limit compliance than actual business logic.
Smarter APIs will implement capability-based rate limiting. Instead of "100 requests per minute," try "complete 10 booking transactions per hour." The agent can make whatever calls needed to fulfill those transactions, but can't exceed the business-relevant limit.
The Aggregation Layer Opportunity
Someone will build the consolidation layer, and it probably won't be the current API providers. We're already seeing early attempts: services that wrap dozens of e-commerce APIs behind a single "purchase anything" interface, or travel aggregators that expose unified booking capabilities.
These consolidation services face a chicken-and-egg problem. They need enough API coverage to be useful for agents, but they need agent volume to justify the engineering cost of maintaining dozens of upstream integrations. The first service to solve this wins a significant portion of agent-driven traffic.
The technical challenge is harder than it looks. Different APIs have different data models, error conditions, and business rules. Building a unified interface means making opinionated decisions about how to resolve conflicts. Should "availability" mean in-stock, in-stock-with-fast-shipping, or in-stock-at-current-price? Different upstream APIs define these terms differently.
The New API Design Principles
APIs optimized for agents will look fundamentally different:
Stateful by default. Instead of forcing agents to maintain context across calls, the API should remember what the agent is trying to accomplish. "Continue my laptop search but exclude refurbished items" should work without resending the entire search context.
Capability-focused endpoints. Rather than data-focused endpoints like GET /products, expose capability-focused endpoints like POST /find_and_compare_products. The agent describes what it wants to accomplish, not what data it wants to retrieve.
Rich error semantics. When something goes wrong, agents need to know whether they should retry, try a different approach, or give up entirely. HTTP status codes aren't sufficient. "Payment failed" could mean bad credit card, insufficient funds, fraud detection, or temporary processor downtime — and each requires a different agent response.
Natural language schemas. JSON schemas that describe field formats are useless for agents. Better to describe field semantics: "delivery_date: when the customer will receive the item, accounting for weekends and holidays in their timezone."
Why This Matters Now
Agent capabilities are improving faster than API design. GPT-4 can handle complex multi-step reasoning, but it gets bogged down in API orchestration busywork. The agents that perform best today are working with APIs that were accidentally designed well for automation: simple, stateful, high-level operations.
Companies that redesign their APIs for agents first will capture disproportionate agent traffic. Those that don't will get disintermediated by consolidation layers.
The window for this transition is narrow. Agents are becoming capable enough to drive significant business value, but current APIs create enough friction that most agent use cases still aren't economically viable. The first wave of agent-native APIs will capture the market as that friction disappears.
We expect to see the first successful API consolidation platforms within 18 months, and the first major service providers to ship agent-native API redesigns within 12 months. The companies that wait for "industry standards" will be building for yesterday's agents while competing against tomorrow's infrastructure.