API gateways are useless. Well, not yet, but if they don’t adapt to API capability consumption, they will for sure. What do I mean by that? API gateways were designed for predictable traffic driven by developer-made integrations. In this reality, anything that looks suspicious is treated like an outlier. A burst of requests to the same operation with small changes in parameters. An unanticipated combination of requests to different operations. Or simply paginating through a very large result set. Yes, an API gateway can work perfectly when its only job is to check authentication tokens, apply rate limits, and route HTTP requests to specific microservices. The challenge is that today’s reality has more to do with dynamic, ephemeral workflows and less with fixed static API integrations. The API gateway can’t understand the intent behind certain combinations of requests. And that’s a real issue because those combinations are what agents see as the business capabilities they need. How can you address this problem now and make your APIs agent-friendly? Keep reading to explore solutions.
This article is brought to you with the help of our supporter, Naftiko.
Naftiko is a platform that helps organizations manage their technical assets as business capabilities. It provides a central space where teams can define and discover what their services can actually do. By moving the focus away from raw API operations, Naftiko helps engineering and product teams work better together.
Before analyzing solutions, let’s understand the problem in more detail. Let’s look at how an LLM can interact with an API. Even though an LLM could use a custom point-to-point connection with an API, the tool of choice these days is the MCP. It gives AI agents a standardized way of identifying and interacting with available tools. The MCP server would then convert a request to one tool into one or several requests to API operations. I can already see a few challenges with this approach. But what happens when there’s no API to connect with? You can also have MCP servers that interact directly with a database, even though you can’t say that’s a good practice. What’s important is that MCP gives AI the agency to access API operations and backend systems and convert them into capabilities on the fly. Ephemerally. Think for a moment about the technical complexity of managing a fleet of this kind of capabilities. API gateways follow strict routing rules, often managed by a complex control plane. When an AI agent makes a request to one tool, the MCP server might need to call several API operations. To the API gateway, this looks like three unrelated requests. Because of that, there’s no way for it to enforce a unified semantic policy. In other words, API gateways lack the awareness that a sequence of distinct requests belongs to a single, high-level business capability.
Now you can fully understand the problem we’re dealing with. Fixing it requires a fundamental shift away from forcing every request through an API gateway. Instead, you need to move to a control plane that uses declarative capability definitions. Why? Because it decouples the policy enforcement from the network topology. It places the capability orchestration above your infrastructure to automatically translate high-level business definitions into workflows composed of API operations. One way to achieve this is to add the functionality to the API gateway itself. That’s not the approach I would take, however. Instead, I’d implement a spec-driven integration fabric. I’d make it so that it would understand OpenAPI, AsyncAPI, MCP, and Arazzo, and instantly expose groups of operations and workflows as tools. Each tool would then map to a business capability. It sounds interesting, but how can you make it happen?
One way to implement this solution involves combining an open-source multi-protocol gateway with a control plane that can understand workflows. Open-source solutions like the agentgateway, ContextForge, and Apache APISIX are good examples of gateways that can handle more than one protocol. The trick here is being able to execute full workflows that combine operations from several APIs. Look at this mockup example declarative configuration that defines a checkout capability. It defines two sources of operations and exposes the checkout capability as an MCP tool.
metadata:
name: checkout-capability
spec:
tool:
name: "execute_checkout"
description: "Handles the complete customer checkout workflow."
definition:
openapi: "https://example.com/apis/orders.yaml"
execution:
arazzo: "https://example.com/workflows/checkout.yaml"
workflowId: "checkoutWorkflow"
policies:
- type: "token-budget"
limitPerMinute: 50000
- type: "rate-limit"
requestsPerMinute: 100A configuration document like this would help a multi-protocol gateway interpret incoming requests and perform execution and protocol translation. Following the example, whenever an AI agent calls the checkout tool, the gateway catches the request, looks at the Arazzo definition to see the correct sequence of API calls, and executes it. It also enforces rate and token limits at the logical capability level instead of checking isolated API operations. Looks simple, right? However, implementing it isn’t as easy as it looks.
Transitioning to a capability-driven orchestration model doesn’t happen without effort. There are real engineering and organizational costs you need to take into account. And the most important one isn’t even related to technology. No, the biggest effort to drive capability orchestration has to do with change management. If you’re not following an API design-first approach yet, you’ll have to. Every capability needs to be backed by properly documented API operations. Inputs and outputs have to be properly modeled, documented, and tested so they work independently of how they’re consumed. If your team isn’t doing this yet, they have to. But there’s more. Your platform engineering team, or whoever takes care of your infrastructure and traffic, will face a technical learning curve to integrate the distributed control plane into existing deployment pipelines. They’ll have to do things like configure sidecars for traffic enforcement and change monitoring tools from tracking simple HTTP status codes to tracking semantic tokens, policy violations, and actual business capability usage.
As things continue to evolve in the agentic workflow space, the pressure to make a decision will increase. Should you continue adding plugins and patches to your existing API gateway? Or, should you make the move to a capability orchestration solution? If I were you, I’d spend some time understanding how many standalone MCP instances there are, and how many hidden API operations they’re exposing. I’d seriously consider moving to a declarative approach similar to the one I described before. But I’m not you, and I can’t decide for you. At the end of the day, the decision comes down to whether you want to spend your days managing MCP and workflow sprawl or orchestrating a set of well-documented business capabilities. The choice is now yours.
