What I think matters right now
API management has been reshaped before by a change in who, or what, consumes the API. When mobile apps became the primary front end, the pressure was a surge of new clients and traffic. When partner and third-party ecosystems opened up, the pressure was exposing internal capability safely to outsiders. Each time, the winning move was not to rebuild the platform for the new consumer. It was to bring that consumer under the governance the estate already had: consistent identity, access, policy, and visibility, extended to a new kind of caller.
Agents are the next consumer in that line, and the most demanding one yet. The enterprises moving fastest on AI are not the ones rebuilding their platforms. They are the ones whose API estate was already governed, discoverable, and portable, so that when agents arrived there was somewhere for them to plug in. AI does not remove the need for solid API management. It raises the price of not having it.
That is the lens I bring to the Gartner® Critical Capabilities for API Management. Rather than offering a single-axis ranking, I feel the research evaluates products against defined use cases and weights capabilities according to their importance within each use case. I read it closely because this structure helps buyers compare products against the outcomes they are trying to achieve, while distinguishing use-case depth from breadth for its own sake.
Read together, this year’s use cases build on each other rather than standing apart. Governing the APIs you already have, wherever they live, is the foundation. On top of that foundation, the work is to make those governed APIs genuinely consumable, packaged as products that the people and the systems calling them can discover and use. That second part now has two audiences at once: human developers, who have always been the consumer, and AI agents, the newest and most demanding one. They are not sequential phases where you finish serving people before you turn to agents. They are two consumers of the same governed estate, and a platform has to be strong for both. The sections that follow take the foundation first, then each consumer in turn, alongside what I believe the results indicate.
Step one: APIs live everywhere now, so governance has to follow them
Enterprises rarely get to design their API landscape from a blank page. Local teams innovate at speed, platforms stay siloed, and APIs end up spread across multiple gateways, clouds, and teams. Consolidating all of it onto one platform means the kind of rip-and-replace project most organizations rightly want to avoid.
Axway ranked 1st in the Distributed API Management Use Case for the fourth consecutive year, with a score of 4.4 out of 5.0. To us, the result is particularly relevant because gateway federation carries the highest weighting in this use case. Axway’s approach is based on an out-of-path, multi-runtime model: Amplify supports discovery and governance across its own data planes, AWS, Azure, other cloud environments, and a broad range of third-party gateways through lightweight agents rather than proxies or facades. Amplify API Gateway applies enterprise policy across cloud, on-premises, and hybrid environments through a consistent runtime.
The practical result is less integration sprawl. Developers find the right API without traversing the whole organization, and platform teams apply consistent policy without asking every team to migrate first. The idea underneath it is simple, and we have held it for a long time: keep what works, and govern it where it already runs.
See also: Agentic AI Governance: How to Keep AI Deployments Compliant
Step two: turn governed APIs into products consumers can use
Governing APIs is the foundation, not the payoff. Value shows when whoever needs an API can find it, understand what it does, and start using it without a support ticket. That is the gap that we believe the Productizing APIs Use Case measures, and it is the use case where Axway received the highest score of any vendor (3.85 out of 5.0).
Amplify helps organizations organize, expose, and scale their APIs through developer portals, reusable business-centric packaging, and analytics. It sits between the people who build APIs and the parties who consume them, whether those consumers are internal teams, external partners, or both. Packaging APIs as products also opens the door to new revenue: organizations can package, expose, and monetize APIs securely, turning integration assets into reusable products. That same logic now extends to Model Context Protocol (MCP) servers, which enterprises can productize and monetize like any other API asset as AI adoption grows.
For most of the history of API management, the consumer being served this way was a human developer. That has not gone away, and it still matters. What has changed is that a second consumer has arrived for the very same products, and it behaves differently enough to deserve its own treatment.
Step three: serve the newest consumer, the AI agent
That second consumer is the AI agent, and serving it well is where the conversation is moving fastest. It is worth being precise about why. Enterprise AI stalls when it cannot safely reach the data and systems spread across silos, clouds, and partner ecosystems. Models need consistent, governed, real-time data to be useful, which is why a high level of API maturity increasingly shapes whether an AI initiative succeeds. The governed, productized estate from the first two steps is not a prerequisite you can skip on the way to AI. It is the reason AI works at all.
But maturity alone is not enough, and this is where I think the industry can be more deliberate. An agent is not a human developer with a faster keyboard. It discovers capability by reading machine-legible descriptions, not documentation pages; it needs interfaces exposed in the protocols it speaks, such as MCP, and semantics it can reason over rather than guess at; and it calls at a volume and cadence no human would. An API that is merely reachable by an agent is not the same as an API that is designed for one to use well. Getting real value from AI means thoughtfully reshaping the estate for this consumer, exposing APIs and enterprise capability as agent-ready tools, rather than pointing agents at interfaces built for people and expecting them to adapt.
And there is a scale effect that is easy to underestimate. Every AI initiative tends to create more of everything: more APIs to feed models, more MCP servers to expose capability, more agents acting as consumers, spread across more teams, clouds, and runtimes. AI does not consolidate the estate; it enlarges and further distributes it. That is precisely the environment federated governance is built for, and it is why our strength in distributed API management matters more in the AI era, not less. The ability to discover, govern, and secure APIs and AI assets wherever they run, without forcing them onto a single platform, is what keeps an expanding estate coherent instead of fragmenting under its own growth. Federated API and AI management is not a separate capability we bolt on for agents; it is the same foundation that earned the top score in distributed API management, now carrying a wider range of digital assets.
That more demanding consumer also raises the stakes on control. Agents introduce real security considerations, so they need robust identity management and granular access control. Without a well-defined security model, an agent could reach sensitive data, take unauthorized action, or become a path into the broader system. The encouraging part is that you do not need to invent a new control model to handle this. Amplify AI Gateway extends the governance enterprises already trust for their APIs to AI models, MCP servers, and agents, while treating those agents and MCP servers as first-class assets to be exposed and managed, not just traffic to be policed. It enforces policy, secures access, and makes AI interactions with enterprise data and services observable.
The temptation, of course, is to stand up a separate control model for all of this: a dedicated gateway here, an agent registry there, bespoke policies alongside the ones you already run. That is how the sprawl starts again. The more durable path is to treat these new consumers as first-class citizens of the same lifecycle you already apply to APIs, subject to the same access controls, rate limits, and traceability, rather than a parallel system sitting nearby. The disciplines that made APIs manageable at scale are the same ones that make AI safe at scale. This is why I read maturity, not novelty, as the real predictor of AI success: how far an organization can safely take AI is largely a function of how mature its API governance already is.
Axway tied for second-highest score for the AI and Agent Management Use Case (3.65 out of 5.0), and I read that as a strong starting position rather than a finish line. Making enterprise capability genuinely consumable by agents and governing those agents with the discipline we already apply to human developers, is exactly the direction Amplify is heading.
See also: Secure and Scalable Agentic AI: A Guide for Enterprise Leaders
Where I think this goes next
If step three is happening now, the honest question is what comes after it. My view, and it is a deliberately non-consensus one, is that today’s agents are a first generation. They are a genuine breakthrough for reasoning and discovery, but in their current shape they are often not suited to enterprise-critical workloads: non-deterministic where determinism is required, high-latency where responsiveness matters, costly per token at production volume, and hard to audit where audit is not optional. This generation is valuable today, and we are fully committed to it: agent proxying, registries, and governance are exactly the capabilities enterprises need to put agents to use safely, and we are building them.
At the same time, we keep our eyes on what comes next. Right now, many organizations use agentic reasoning as a hammer and consider every workload a nail, applied indiscriminately, including problems that never needed reasoning in the first place. The direction we are taking is not to replace agentic execution but to make it fit for purpose, and I expect the two modes to coexist for a long time. Where variability, real uncertainty, or human-in-the-loop judgment call for reasoning on every call, workloads should stay agentic, governed, and observable. Where a pattern is proven and repeatable, running a probabilistic reasoning loop over it every time is all cost and no benefit. A probabilistic agent is a powerful way to work out how a task should be done; it is a poor way to do that same task the ten-thousandth time in a regulated production system.
That is where a newer generation of agents comes in, one that still uses agentic reasoning for what it is best at, which is discovery and design, but graduates the proven pattern into a deterministic implementation rather than re-reasoning it on every run. The judgment stays agentic; the execution becomes deterministic. And once a pattern runs as a deterministic, protocol-native API flow, its properties change on every axis a regulated enterprise cares about:
- Compliance and auditability. A deterministic flow does the same thing every time, which is the precondition for an audit trail an examiner will accept. You can show exactly what ran, on what data, under which policy, rather than reconstructing the reasoning of a model after the fact.
- Behavior is repeatable and testable. The output does not drift between runs, so change control, approvals, and sign-off mean what they are supposed to mean.
- Cost and latency. A graduated flow is zero-token and executes at API speed, removing the per-call inference cost and the latency of a reasoning loop from the paths that run at volume. AI reasoning is spent where it adds value, not on repetition.
- Deterministic execution scales the way API traffic already does, on infrastructure that teams know how to operate, instead of scaling an expensive, non-deterministic reasoning tier under production load.
Around that core, the same enterprise disciplines hold. Governance stays federated, so control does not fragment as AI consumers multiply. And deployment stays sovereign across public SaaS, private SaaS, and self-hosted, so data residency and jurisdictional obligations are met by where the workload actually runs, not by policy asserted from a control plane elsewhere. This is not a departure from API management. It is API management extended to the assets the market is now adding, with the compliance, predictability, cost, and scale properties that regulated enterprises already expect from their APIs.
I want to be candid about the nature of that claim. It is a point of view, not a scoreboard, and reasonable people will weigh the near term and the long term differently. What the Critical Capabilities results give me confidence about is the foundation: an offering that scores at the top of the field where the depth is hardest to fake, in distributed governance and in turning APIs into products. That is the ground the next step is built on.
Why this adds up to Axway
If you are building a shortlist, here is how I would connect the dots. In our view, the two use cases where Axway scored highest of any vendor, distributed API management and productizing APIs, are the two that determine whether an enterprise can govern the estate it actually has and get value out of it. Those are not the flashy categories, but they are the ones that decide whether AI has a solid foundation to stand on. We feel And the direction, federated governance across a growing, distributed set of APIs and AI assets, with a path toward deterministic execution, is built on that strength rather than beside it. The short version: strong where it is hardest to be strong, and heading somewhere deliberate from there. That combination is what I would weigh. The right tool for the right job, on a foundation strong enough to tell the difference, is the platform I would want underneath an AI strategy, and it is the one these results describe.
Take the next step
In our view, the Critical Capabilities research shows how products perform across the use cases that shape a shortlist, including Distributed API Management, Productizing APIs, and AI and Agent Management. If you are evaluating API management with AI on your roadmap, it is worth reading in full.
Read the Gartner® Critical Capabilities for API Management report
Gartner, Critical Capabilities for API Management, Shameen Pillai, Nicholas Carter, John Santoro, 28 September 2026.
Gartner does not endorse any company, vendor, product or service depicted in its publications, and does not advise technology users to select only those vendors with the highest ratings or other designation. Gartner publications consist of the opinions of Gartner’s business and technology insights organization and should not be construed as statements of fact. Gartner disclaims all warranties, expressed or implied, with respect to this publication, including any warranties of merchantability or fitness for a particular purpose.GARTNER is a trademark of Gartner, Inc. and/or its affiliates..