For decades, APIs have been built for developers. Developers read documentation. Developers authenticate. Developers write code that calls endpoints, parses responses, and handles errors. The entire stack of developer tooling — from Swagger UI to Postman to README.com — was built on a single, often unstated assumption: a human being is sitting at the other end.

But what happens when the primary consumer of an API is no longer human?

In 2025, this question moved from speculative to operational. AI agents — autonomous software systems that can reason, plan, and act across digital services — began appearing inside production systems at scale. They are scheduling meetings, processing invoices, querying CRMs, filing support tickets, and executing multi-step workflows without a human hand in the loop. And to do all of that, they are calling APIs — constantly, at speed, and in ways that API designers never anticipated.

The architectures built to serve developers are starting to show their age. REST endpoints designed for request-response cycles feel clumsy when an agent needs to understand the consequence of an action before taking it. OpenAPI specifications that describe what an API does fall short when a machine needs to know why it exists, who it belongs to, and what permissions it holds. Authentication models built for human login flows are poorly suited to non-human entities that must act autonomously across dozens of services simultaneously. This is not simply AI becoming another type of API consumer — a new category alongside mobile apps and microservices. It is a more fundamental disruption. The implicit contract at the heart of API design — that developers are the readers, the interpreters, and the ultimate governors of API behaviour — is being rewritten.

The API economy may be evolving into an agent economy.

APIs Were Built for Humans. AI Wants Something Different.

The history of the public API is, in large part, a history of developer experience. When Roy Fielding formalised REST in his 2000 doctoral dissertation, the goal was architectural clarity for web developers. REST’s constraints — statelessness, uniform interfaces, resource-based addressing — mapped naturally to how human engineers thought about web systems. You read the documentation, you understood the resource model, and you wrote the code.

The decade that followed saw REST displace SOAP across the industry, with companies like Twitter, Facebook, and Amazon opening programmatic access to their platforms. By the mid-2000s, APIs were not just technical plumbing — they were business models. The ‘programmable web’ became a genuine economic category, and developer experience became a competitive differentiator. Better documentation, faster SDK generation, cleaner error messages: these were the things that drove API adoption.

GraphQL, introduced by Facebook in 2015 and publicly released in 2016, refined the model further. Rather than returning fixed data shapes, it let clients specify precisely what they needed. OpenAPI (formerly Swagger) gave the ecosystem a lingua franca: a YAML or JSON contract describing endpoints, parameters, authentication, and responses. From this contract, you could generate SDKs, interactive documentation, and test suites automatically. It was a major step forward — for human developers. AI agents have different requirements, and the gap is not trivial.

A developer reading API documentation can infer meaning from context, navigate ambiguity, and make judgement calls about which endpoint to use in a given situation. An AI agent working autonomously cannot rely on that kind of interpretation in the same way. It needs machine-readable descriptions of capability, intention, and consequence. It needs to know not just what an endpoint accepts, but what happens downstream when it is called. It needs explicit permission boundaries, because it may be operating with delegated authority on behalf of a user who is not present. And it needs these things in a form that is reliably parseable, not buried in prose documentation.

This is the gap that the Model Context Protocol (MCP) — introduced by Anthropic in November 2024 and open-sourced immediately — was designed to address. MCP provides a standardised, JSON-RPC-based interface through which AI models can communicate with external tools and data sources in a uniform, portable way. The analogy that has stuck in the industry is USB-C: before it, every device shipped with proprietary connectors and incompatible cables. MCP replaces hundreds of point-to-point integrations with a single connector standard.

The adoption curve has been striking. Within months of its release, OpenAI announced MCP support across its Agents SDK and ChatGPT desktop application. Google DeepMind followed. Microsoft, AWS, and a constellation of developer tooling companies joined the ecosystem. By early 2026, MCP had passed 97 million SDK downloads and was being governed under the Linux Foundation’s newly formed Agentic AI Foundation — a sign that the industry was treating it as infrastructure, not a product.

As Thoughtworks noted in their November 2025 Technology Radar, MCP is not a silver bullet. Security challenges and anti-patterns have emerged, as they do with any rapidly adopted technology. But its trajectory — from Anthropic’s internal experiment to a Linux Foundation standard in roughly fourteen months — mirrors the path taken by Docker and Kubernetes.

The more difficult question is what this means for the existing API landscape. Will companies maintain two separate layers — one REST/OpenAPI surface for human developers, and a separate MCP-compatible surface for AI agents? For large platforms with dedicated API teams, this dual-layer architecture may be viable. For smaller organisations, the overhead is significant. There is a reasonable case that MCP and OpenAPI will coexist for years, with MCP handling the agent-to-tool connectivity layer and OpenAPI remaining the standard for the SDK generation, documentation, and developer portal use cases it serves well.

Not supporting MCP increasingly means being cut off from a rapidly growing ecosystem — one where the fastest-growing category of consumers is non-human.

Integration Is Becoming the New Battleground

Choosing a large language model is, at this point, a relatively tractable decision. The real models are broadly capable, the APIs are well-documented, and the pricing is transparent. What teams consistently underestimate — and what separates proofs of concept from production systems — is integration.

AI agents are useful precisely because they can take action: create a ticket in Jira, update a customer record in Salesforce, send an email via Exchange, query a legacy database, or trigger a workflow in an ERP system. Each of these actions requires the agent to authenticate with an external service, understand its data model, handle its rate limits, and interpret its responses — often across multiple services in a single workflow. The complexity compounds non-linearly as the number of connected systems grows.

The authentication problem alone is substantial. Most enterprise SaaS systems were designed around OAuth flows that assume a human user is present to grant consent. An AI agent acting autonomously cannot click through an OAuth screen. It must either operate with pre-provisioned credentials — which introduces credential management challenges — or use delegated authority mechanisms that most enterprise software does not yet support cleanly.

Rate limits present a different class of problem. A human developer interacting with a CRM sends a handful of API calls per session. An AI agent processing a queue of tasks might make hundreds of calls in seconds. The rate limit architectures that work for human-driven integrations often fail for agentic workloads, and the error-handling behaviour of agents — retry logic, backoff strategies, fallback paths — needs to be explicitly designed rather than assumed.

Latency and context management add further complexity. Agentic workflows are inherently sequential: the output of one API call becomes the input to the next decision point. Long-running workflows must maintain state across multiple interactions, which requires careful design of the context window — the working memory that the AI model operates within. Context management is not a model problem; it is a systems integration problem, and it requires engineering discipline.

The consequence of all this is captured in a phrase that has become something of a watchword in enterprise AI teams: the cost of integrating AI often exceeds the cost of the AI itself. The model is a commodity. The integration is the moat — or the obstacle, depending on which side of the problem you are on.

This matters disproportionately for smaller organisations. A Fortune 500 company with a dedicated platform engineering team can build and maintain the integration infrastructure that agentic AI requires. A mid-sized manufacturer or professional services firm operating with limited IT resources cannot. The vendors who solve the integration problem for these organisations — through pre-built connectors, managed MCP infrastructure, or low-code orchestration platforms — will capture significant market share in the next several years.

The hardest AI problem is not choosing the model. It is integration. And for most organisations, the cost of connecting AI to existing systems exceeds the cost of the AI itself.

Is OpenAPI Enough?

OpenAPI has been an unambiguous success. The specification, now on version 3.1, has given the industry a common contract language for REST APIs. From a well-maintained OpenAPI spec, teams can generate client SDKs in dozens of languages, produce interactive documentation, build mock servers, and run automated test suites. Schema-first development — writing the contract before the implementation — has improved API quality and team coordination across thousands of organisations.

None of that is in question. What is in question is whether OpenAPI is sufficient for the next generation of API consumers.

Consider what an AI agent needs to know to interact confidently with an API. It needs to understand not just the structure of a request — what fields are required, what types they accept — but the semantic meaning of an operation. What does it mean to call this endpoint? What state change does it produce? Is the action reversible? What are the downstream consequences in the business system that the API represents? OpenAPI answers the structural questions precisely. It answers the semantic ones poorly, or not at all. Permissions are another gap. OpenAPI can describe authentication schemes at a high level, but it cannot express fine-grained capability boundaries in a form that an agent can reason about. An agent that is delegated authority to read customer data should know, unambiguously, that it does not hold authority to update it. Current OpenAPI specifications do not encode this kind of constraint in a way that an autonomous system can reliably enforce.

Business rules present a similar challenge. Many API operations have preconditions, side effects, and workflow dependencies that exist in human documentation — or in the heads of the developers who built them — but are not expressed in the machine-readable contract. An agent navigating these APIs autonomously is operating with incomplete information.

It is worth being precise about what this means. OpenAPI is not broken. It was designed for a world where human developers read the specification, interpret it, and write code accordingly. In that world, the gaps can be filled by human judgement. In a world where agents consume APIs autonomously, those gaps become failure modes.

The industry is experimenting with several responses. MCP’s tool description format includes natural language descriptions of tool capabilities, which models can use to reason about which tool to invoke and when. Stainless, a company focused on SDK generation, has argued publicly that a complete, well-maintained OpenAPI spec remains the most important investment an API provider can make — because it is the foundation on which every downstream artefact (SDKs, MCP servers, agent skill files) is built. The implication is not that OpenAPI is sufficient for agents, but that it remains a necessary starting point.

Other efforts are more experimental. The AGENTS.md specification, proposed by OpenAI in 2025, attempts to provide a standard way for AI agents to discover and understand the capabilities of a service. The Agentic AI Foundation — formed under the Linux Foundation in late 2025 with MCP as one of its founding projects — represents an attempt to establish vendor-neutral governance for these emerging standards.

The honest answer is that no existing standard fully addresses the requirements of autonomous AI consumers. REST and OpenAPI will not disappear — the installed base is too large and the tooling ecosystem too mature. But they are likely to be complemented by a layer of agent-native protocols that encode capability, permission, and consequence in forms that machines can reason about without human interpretation.

Was OpenAPI designed for the previous generation of API consumers? Yes. And that is not a criticism — it was exactly what that generation needed. The question is what the next generation requires.

AI Agents Are Breaking Traditional Security Models

API security has always rested on a set of assumptions so foundational that they rarely get made explicit. Humans authenticate. Humans approve consequential actions. Humans are accountable when something goes wrong. The entire governance architecture of enterprise software — access controls, audit trails, approval workflows, compliance reporting — was designed around the premise of human actors operating within human-scale time frames.

AI agents violate every one of these assumptions.

Consider the credential problem first. According to CyberArk’s 2025 Identity Security Landscape survey of 2,600 cybersecurity decision-makers, machine identities already outnumber human identities by a ratio of roughly 82 to 1 in enterprise environments. AI agents are a new, harder-to-govern subset within that population. Unlike a traditional service account that calls the same APIs on the same schedule, an agent makes autonomous decisions, chains multiple API calls in dynamic sequences, and may acquire new capabilities at runtime through tool use and OAuth flows. The standing credential of an agent understates its effective access at any given moment.

The OWASP Non-Human Identity Top 10, published in 2025, reflects this reality. Improper offboarding, secret leakage, and overprivileged non-human identities are the top risk categories — and these are based on actual breaches, not theoretical scenarios. GitGuardian’s State of Secrets Sprawl 2026 report found 28.65 million hardcoded secrets added to public GitHub repositories in 2025 alone, a 34% year-over-year increase. A significant fraction of these are credentials provisioned for AI integrations, created quickly during development and never rotated.

Fig. 1: OWASP Top 10 NHIs Risks 2025 (source: GiGuardian)

The governance gap runs deeper than credentials. Most Identity and Access Management systems treat AI agents like anonymous scripts or service accounts. But agents do not just call APIs — they interpret instructions, chain decisions, and operate across system boundaries in ways that are difficult to predict in advance. A customer service agent might legitimately hold read access to an entire CRM during initial testing and retain that access indefinitely because nobody thought to scope it down. A code review agent might accumulate pull request approval rights that compound over months.

Accountability is the hardest problem. When a human employee approves an expense, there is a clear line of responsibility. When an AI agent approves an expense autonomously — or, more concerningly, when it is manipulated into doing so through a prompt injection attack — the accountability chain is unclear. Who is responsible: the agent’s developer? The operator who deployed it? The user who authorised it? The regulatory frameworks being built around AI — the EU AI Act, NIST’s AI Risk Management Framework — are beginning to grapple with these questions, but the governance infrastructure for agentic systems is years behind the technology.

Several approaches are emerging. Zero-trust architectures applied to agent identities — where no agent-to-agent or agent-to-service trust is assumed by default — are gaining traction. Just-in-time credential provisioning, where agents are issued short-lived tokens for specific tasks rather than long-lived API keys, reduces the blast radius of a compromised credential. Immutable audit trails, cryptographically signed and append-only, provide the forensic foundation for post-incident investigation.

The more fundamental question — whether AI agents should have their own digital identities, distinct from the human users or services that deploy them — remains open. Proposals exist for decentralised identifier schemes that would give agents persistent, portable identities across systems. Whether these approaches achieve the adoption necessary to become infrastructure is unclear. What is clear is that treating AI agents as a subcategory of existing service accounts is insufficient for the risk profile they carry.

Should AI agents have their own digital identities? The question is no longer theoretical. The blast radius of a compromised agent is not ‘one API call failed’ — it is ‘hundreds of unauthorised changes landed before anyone noticed.’

The API Economy Is Becoming the Agent Economy

For the past fifteen years, the API economy has operated on a fairly stable set of business models. Developers discover an API through documentation or a marketplace. They sign up, authenticate, and begin building. Revenue follows usage: subscriptions, per-call pricing, tiered access. Developer relations teams cultivate communities. Partner integrations extend the ecosystem. The developer is both the technical consumer and the economic customer.

AI agents complicate every step of this model.

Consider discovery. Developers find APIs through search, word of mouth, conferences, and developer advocates. AI agents find tools through machine-readable registries, capability descriptions, and protocol-level discovery mechanisms. The emerging MCP registry ecosystem — where MCP-compatible tools self-describe their capabilities in standardised formats — represents a fundamentally different discovery surface than a developer portal.

Pricing is similarly disrupted. Per-seat SaaS pricing assumes human users. An AI agent is not a user in the seat-based sense. It may invoke a service thousands of times per hour on behalf of one human principal, or it may execute a single high-value transaction that took no human time at all. Gartner projects that 40% of enterprise applications will include task-specific AI agents by the end of 2026, up from less than 5% in 2025. At that scale, the mismatch between seat-based pricing and agentic usage becomes economically significant for both vendors and buyers.

McKinsey’s 2025 State of AI survey found that 88% of organisations were using AI in at least one business function, with 23% actively scaling agentic systems. That scaling creates a new class of procurement decision that human buyers are not always making. An AI agent configured to optimise cloud infrastructure costs might autonomously evaluate competing API providers, compare pricing tiers, test latency, and recommend a switch — all without a human being involved until the recommendation surfaces in a dashboard. Forrester has predicted that one in five sellers will face AI-powered buyer agents capable of issuing dynamically composed counteroffers.

The implications extend to SLA design, pricing transparency, and API contract structure. If AI agents are comparing your API against competitors’ offerings on latency, reliability, pricing, and capability completeness, then the machine-readability of those attributes matters. An SLA buried in a PDF is not useful to an agent. A machine-readable SLA expressed in a structured format that an agent can query and reason about is. The companies that instrument their APIs for agent-legibility — not just developer-legibility — gain an advantage in a procurement environment where the buyer may increasingly be a machine.

Google’s announcement of the Agent Payments Protocol (AP2) in September 2025, backed by more than 60 organisations including major payment networks, signals that the financial infrastructure for autonomous commerce is being built in parallel with the technical infrastructure. The protocol creates a payment-agnostic framework using cryptographically-signed mandates — a mechanism for agents to authorise transactions within defined boundaries without requiring real-time human approval.

The business model implications are not uniform. For high-volume, low-touch API services — data enrichment, geocoding, currency conversion — agent consumers are straightforwardly valuable: they drive usage without requiring developer relations investment. For complex enterprise software where the sales motion involves multiple human stakeholders, custom configuration, and ongoing support, the agent-as-buyer model is more disruptive. The question of whether AI agents will eventually select and onboard enterprise SaaS products without human involvement is not answerable today, but the direction of travel is clear.

A subtler shift concerns where competitive advantage lives. In the era of developer-first APIs, competitive advantage accrued to the provider with the best developer experience: the cleanest documentation, the most mature SDKs, the most active developer community. In an agent economy, those advantages do not disappear, but they are joined by a new set: the most complete machine-readable capability descriptions, the most robust agent authentication mechanisms, the most transparent and queryable pricing and SLA structures. Developer Experience and Agent Experience are not the same discipline, and the organisations that treat them as identical will fall behind those that distinguish between them.

Will businesses compete for human customers — or AI customers? The answer is almost certainly both. But the tools, metrics, and strategies required for each are different in ways that most organisations have not yet confronted.

The Next Architectural Shift

The rise of REST in the early 2000s was not primarily a technical event. It was a reorganisation of how software systems were composed, how businesses exposed their capabilities, and how developers understood their work. The shift from SOAP to REST took years and was incomplete even at its peak — SOAP never fully disappeared, and REST itself was never uniformly implemented. But the direction was decisive, and the consequences — the programmable web, the API economy, the platform model — were transformative.

The rise of AI agents looks like a comparable inflection point, and the parallels are instructive. REST succeeded not because it was technically superior to SOAP in every dimension, but because it aligned with how the web actually worked — it was simpler, more familiar, and more composable for the developers who needed to use it. MCP has succeeded with similar speed not because it is technically the only possible solution, but because it solved a real problem — the proliferation of bespoke integration code for every model-tool combination — in a way that the major AI platforms were willing to standardise around.

What does this mean for architects, developers, and technology leaders making decisions today?

First, the investment in OpenAPI and REST is not wasted. A well-maintained OpenAPI specification is the foundation on which agent-compatible surfaces will be built. The teams that have disciplined API design practices — schema-first development, semantic versioning, clear documentation — are better positioned to extend into agent-compatible interfaces than those who have treated API design as an afterthought.

Second, security and identity governance for non-human identities is no longer optional. The gap between how organisations govern human access and how they govern machine access — service accounts, API keys, and now AI agents — is a material risk. The 82:1 ratio of machine to human identities in enterprise environments will grow, not shrink, as agentic AI deployment accelerates. Organisations that treat agent credential management as a future problem are already behind.

Third, the concept of Developer Experience needs to be extended. Agent Experience — the ease with which an autonomous system can discover, authenticate to, reason about, and safely interact with an API — is a distinct set of design requirements. It overlaps with DX but is not identical to it. API providers who invest in machine-readable capability descriptions, explicit permission models, and agent-legible SLAs will have a structural advantage as AI procurement and integration mature.

Fourth, the integration problem is underestimated. The limiting factor in agentic AI deployment is not model capability — it is the complexity of connecting AI systems to the heterogeneous enterprise software environments where the valuable work actually happens. The organisations and vendors that solve this problem, particularly for smaller companies without dedicated platform engineering teams, will define the next wave of enterprise software value.

For twenty years, we optimised APIs for developers. We wrote documentation for them, built tooling for them, designed authentication flows for them, and calibrated pricing around their adoption patterns. The ecosystem we built is genuinely impressive, and it is not going away.

The next twenty years may be about optimising for machines. Not instead of developers — the two are not in opposition. But alongside them, and with equal seriousness.

If AI agents become the primary consumers of APIs, should we still design APIs for developers first — or for machines? The honest answer may be that the question assumes a choice we do not actually have to make. The challenge is designing for both — and understanding, precisely and carefully, where their requirements diverge.

Conclusion

Pulling these threads together, three conclusions stand out — not as predictions, but as the implications that follow directly from what is already observable in the market today.

The first is that this shift is additive, not substitutive. AI agents are not replacing developers as API consumers; they are joining them as a second, structurally different consumer class with its own discovery mechanisms, its own authentication requirements, and its own expectations of machine-readable meaning. REST, OpenAPI, and traditional developer experience remain necessary. They are simply no longer sufficient on their own. Organisations that frame this as ‘old APIs versus new APIs’ will misallocate investment; the more accurate frame is ‘one contract, two audiences, increasingly different needs.’

The second is that governance, not capability, is the binding constraint. The technology to let agents call APIs autonomously already exists and works reasonably well. What lags badly behind is the governance layer: identity for non-human actors, scoped and short-lived credentials, audit trails that hold up to scrutiny, and clear accountability when something goes wrong. This is not a model-capability problem that better AI will solve on its own. It is an engineering and organisational discipline problem, and it is currently the single largest source of risk in agentic deployments.

The third is that the competitive battleground is moving earlier in the funnel. For twenty years, companies competed for developer attention through documentation quality and community. Increasingly, they will also need to compete for agent legibility — whether an autonomous system can discover, evaluate, and safely transact with their API without a human ever reading a page of documentation. That is a new design discipline, and very few organisations have a team explicitly responsible for it yet.

None of this requires abandoning what already works. It requires recognising that the audience for APIs has quietly expanded, and that the next several years of API architecture will be defined by how deliberately — or how reluctantly — organisations adapt to that fact.