Over the last decade, enterprises invested heavily in API infrastructure. They purchased API management platforms, deployed gateways across business units and regions, built developer portals, introduced security and observability tools, and encouraged teams to adopt API-first development.

The business case was compelling. APIs would make enterprise capabilities easier to reuse, shorten integration timelines, improve partner onboarding, reduce duplicated development, and create the foundation for new digital products and revenue models.

Yet the operating conditions needed to capture that value remain uneven. Postman’s 2025 State of the API Report found that 93% of API teams face collaboration blockers. 55% struggle with inconsistent documentation, and 34% cannot find existing APIs. Those gaps make reuse harder and contribute to duplicated work and slower delivery.

The issue is not that APIs failed to deliver value. APIs now power almost every meaningful digital interaction, from mobile banking and ecommerce to partner ecosystems and internal automation. The problem is that the infrastructure built around them often became more fragmented as the organization scaled.

Enterprises therefore ended up paying twice: once to build and operate the API infrastructure, and again for the inefficiency created by managing it as a collection of disconnected systems. And just as many organizations are beginning to address that fragmentation, the infrastructure conversation is changing again.

The Next Generation of Gateways Has Arrived

Enterprise technology teams are now being introduced to a new category of infrastructure: AI gateways, MCP gateways, and related tooling alongside the API gateways they already operate.

At a runtime level, these gateway categories address different types of traffic:

• API gateways govern requests between applications and services through capabilities such as authentication, routing, rate limiting, and protocol transformation.
• AI gateways add controls for model interactions, including model routing, prompt inspection, token metering, provider failover, and semantic caching.
• MCP gateways focus on how agents discover and invoke tools, introducing requirements around machine identity, tool-level authorization, and the auditing of agent actions.

The differences are technically meaningful. But for enterprise leaders, the more immediate question is what the organization actually needs to build and operate.

Do enterprises need an AI gateway? Do they also need an MCP gateway? Which capabilities are genuinely new, which can be supported by their existing infrastructure, and what will this emerging stack require in terms of investment, architecture, and governance?

These are not merely product-selection decisions. They determine whether AI becomes an extension of the enterprise’s existing digital foundation or develops into a parallel infrastructure estate with its own operating model. After investing for years in API management, are enterprises ready to make another large, separate investment in AI infrastructure?

CFO scrutiny is arriving early. A 2025 BCG survey of more than 280 finance executives found that only 45% could quantify the ROI of AI and genAI initiatives. The median reported ROI was merely 10%, and nearly a third reported limited or no gains.

The real risk is not the cost of one additional gateway. It is repeating the fragmentation the API era produced, only faster and denominated in tokens instead of API calls. If every new interaction model results in another isolated infrastructure stack, enterprises will not solve the original fragmentation problem. They will extend it.

The answer, therefore, cannot simply be another parallel stack. Enterprises need to make the API infrastructure they already operate ready for what comes next.

Enterprise AI Is Built on the API Estate That Already Exists

An AI assistant answering a customer’s account question needs access to customer information. An agent processing an insurance claim must retrieve policy data, validate documents, update a case management system, and potentially initiate a payment.

Those capabilities already exist inside enterprise applications. In most modern architectures, they are exposed through APIs.

Even when an agent discovers a tool through MCP, that tool will frequently act as an interface to an existing API, database, SaaS application, or internal service. MCP may standardize how the agent discovers and invokes the tool, but it does not replace the underlying enterprise capability.

The protocol used by the agent may be new. The systems of record, business processes, data, and APIs underneath it usually are not. This is why the condition of an organization’s API estate becomes even more important in the AI era.

I also came across a recent piece by Kin Lane that points out something important: an API that is not properly described cannot be indexed or discovered. For AI systems, documentation therefore determines whether an API can be found, understood, and used at all.

An API with unclear ownership remains risky regardless of whether the consumer is human or autonomous. An undocumented dependency does not become less dangerous because a model is initiating the request.

The same weaknesses that reduce API reuse today — poor discoverability, incomplete documentation, inconsistent governance, and missing ownership — will also limit how safely AI systems can interact with enterprise capabilities.

The foundation for enterprise AI is therefore not simply access to more models. It is an API estate that can be understood, trusted, governed, and safely consumed.

Enterprises may still require specialized runtime capabilities. But they should not have to recreate the entire foundation around them. The stronger strategy is to make the infrastructure they have already built ready for AI.

What Does an AI-Ready API Estate Actually Require?

1. Visibility Across the Entire Estate

Most enterprises will continue operating multiple gateway technologies. That is a practical reality created by acquisitions, cloud strategies, regional requirements, legacy systems, and organizational autonomy.

Replacing every gateway with a single runtime is rarely realistic, and it may not even be desirable. What enterprises need is a control plane that can work across those runtimes.

A federated control plane does more than collect metrics from different dashboards. It creates a normalized understanding of APIs, policies, environments, ownership, and usage across multiple platforms. It allows the organization to govern the estate as one system even when execution remains distributed.

This requires more than placing a central interface over several gateway consoles. The control plane must reconcile how different platforms represent APIs, deployments, consumers, environments, and policies so that the enterprise can reason about them consistently.

The objective is not to force every request through one gateway. It is to create a common management and governance layer across the gateways already in use.

2. Business Context and Trustworthy Documentation

Discovering an endpoint such as POST /applications is useful, but it is not enough. An AI system needs to know what kind of application the endpoint creates, which data is mandatory, what permissions are required, what business process it initiates, and which downstream systems depend on the result.

That information is rarely available from gateway configuration or runtime traffic alone. It has to be connected from specifications, documentation, ownership records, policy definitions, data classifications, application dependencies, and operational knowledge.

Without that context, an organization may have visibility into traffic without understanding what the traffic means.

A human developer can sometimes compensate for missing context by inspecting source code, searching an internal wiki, asking a colleague, or opening a support ticket. An autonomous agent cannot reliably follow the same path. It either receives explicit, structured guidance or operates with incomplete information.

For human developers, poor documentation creates friction. For AI systems, it creates execution risk.

In one exploratory 2026 industrial study of an ecosystem containing 16 production APIs and roughly 600 endpoints, researchers compared two MCP servers exposing the same 10 endpoints: one generated from the original OpenAPI documentation and one with enriched descriptions. With the original documentation, about 70% of tasks failed during planning, only 10% of expected endpoints were correctly identified, and none were completed end-to-end because of payload-construction or authentication errors.

However, with enriched documentation, agents produced correct plans for 90% of tasks, correctly identified 80% of endpoints, and successfully executed every identified endpoint.

An AI-ready API needs more than a technically valid specification. It needs clear descriptions, accurate schemas, authentication guidance, examples, error behavior, constraints, and enough business context to help a model understand how and when the API should be used.

Documentation and business context therefore become part of the execution path. They help transform a technically callable endpoint into a capability that an agent can interpret and invoke safely.

3. Consistent Governance Across Runtimes

As APIs become available to AI systems and agents, enterprises need to determine which capabilities can be accessed, by whom, under what identity, and under which conditions.

Data sensitivity, authorization, rate limits, geography, consumer type, and business risk all influence those decisions.

The policy may ultimately be enforced by an API gateway, AI gateway, MCP gateway, or the underlying service. But the enterprise should not define its governance principles independently within every runtime.

Policies need a shared lifecycle and a consistent relationship to the business capabilities they protect.

For example, a customer-data policy should remain recognizable as the same enterprise policy whether the consumer is a mobile application, an AI assistant, or an autonomous agent invoking a tool through MCP. The enforcement mechanism may differ, but the underlying intent should not.

Without a shared governance model, enterprises risk creating different rules for the same capability depending on which runtime happens to expose it.

4. Operational and Economic Visibility

Enterprises need to understand which teams, applications, and agents are consuming tokens; where requests are being retried; whether a lower-cost model could perform the same task; and which business processes are generating AI expenditure.

But AI cost cannot always be understood in isolation.

A model request may trigger several API calls, invoke multiple tools, and affect a broader business workflow. A failed tool invocation may cause an agent to retry a model call, select a different tool, or repeat an entire sequence of requests.

Looking only at model-level token consumption would show the expense, but not necessarily the architectural or business reason behind it.

Connecting model consumption with API usage, tool invocation, and business context is what turns technical telemetry into useful operational intelligence.

It allows platform teams to move beyond questions such as “Which model consumed the most tokens?” and ask more useful ones: “Which workflow generated the cost?”, “Which dependency caused the retries?”, and “Which business capability produced the outcome?”

A Control Plane for the Infrastructure Enterprises Already Own

The opportunity is to make the foundation enterprises already own usable for what comes next: discovering and governing APIs across gateways, connecting endpoints to ownership and business capabilities, improving documentation, understanding dependencies, and applying consistent controls as those capabilities are consumed by applications, models, and agents.

It means giving platform teams one place to understand how humans, applications, models, and agents interact with the enterprise.

A federated control plane can provide that common layer without requiring every workload to use the same runtime. It can help enterprises retain specialized execution where it is technically necessary while maintaining shared visibility, governance, context, and operational control across the estate.

The broader architectural lesson is that a new gateway category should not automatically require the enterprise to recreate every surrounding capability. AI initiatives can build on the APIs, policies, documentation, business systems, and operational knowledge that organizations have already invested in.

The AI era may introduce new runtime capabilities. But it does not have to introduce another decade of fragmented infrastructure.

Before investing in a separate AI estate, enterprises should ask a more fundamental question: Is the API estate we already paid for ready to power AI?