API Management as the gateway for AI agents into company systems

With many agents, API Management becomes essential

API Management becomes essential when a company builds many agents or a whole agent factory for the organization. For an agent to reach the company’s information sources and automate further actions, it has to talk to internal systems, and the preferred form of that communication is a standardized API.

A single agent does not need an API if the data it needs can be extracted from the systems and delivered in static form. The API becomes critical when the underlying data changes dynamically and the agent’s actions are dynamic too.

With many agents and no shared platform, each group of agent builders may do the same tedious work. In e-commerce, for example, each agent would integrate separately with the product data API. API Management delivers the same APIs to agents in a standardized way:

Marek Grabarz: “The API systematizes this, and API Management lets us reuse that API in different places.” (translated) 03:57

Azure API Management has three parts

Put very simply, Azure API Management has three main components: the Control Plane, the Developer Portal and the API endpoint itself.

The Control Plane is the management portal. The APIs already exist in the company, so you import and configure them here, and you describe the rules with policies. A policy can, for example, admit only members of an Active Directory group, define security and monitoring, or set rate limiting: the limit on calls a given system can make per minute or per second.

The Developer Portal is the visual version of what the Control Plane defines. A developer or a team member who integrates with an API does discovery here: they find APIs and see their descriptions, endpoints, business value, how to authenticate and call them, and the allowed number of calls.

The third part is the API endpoint itself, exposed to systems. Agents, mobile apps, internal line-of-business apps, portals and even desktop apps use it.

Existing APIs reach agents as MCP servers

API Management can expose the same API as REST, gRPC or as an MCP server that agents understand. For an API that already runs as REST or in another form, API Management now has, put simply, one checkbox: “Also expose as MCP.” API Management does the translation itself. To a large extent, this lets you connect old systems to agents without modifying them.

A company that already exposed its APIs well for applications can use the same APIs for agents. For example, a wholesaler’s agent lists the products in a chosen category, adds a product to the cart and places the order through APIs that are already exposed.

This works only if the operations have descriptions. Names like GetCustomer or GetProduct sound clear, but for more complex business operations the endpoint name alone does not say what the endpoint does. That is why each operation gets a description in API Management, so the agent knows which endpoint to use and how. In Protopia projects, the team tries to have an LLM write these descriptions. The model gets an instruction to describe the endpoints in a way that it understands itself, which means in a way the agent understands.

Multi-step processes need an integration platform

API Management exists to expose APIs, so processes with many steps and business logic need an extra layer underneath. Integration Platform as a Service (iPaaS) is the layer of flows, workflows and orchestration between API Management and the company’s systems. API Management does not always reach deep into SAP or a database, and it does not send emails, notifications or SMS messages itself unless the company has an API for that.

For example, an agent calls the product order API exposed in API Management. Instead of calling the system’s API right away, API Management starts a workflow that sends the customer an email about the order or about a change in its status. An integration with 5 or 10 steps, where the process can go back a step and holds state, has to store that state somewhere, restore it and behave predictably.

API Management offers simple orchestration. You can build large orchestration too, but it is hard to maintain and debug, and it is hard to find what fails in it. It is also not stateful.

Marek Grabarz: “I always advise clients not to build large orchestration in API Management.” (translated) 37:34

Simple orchestration in API Management helps when there is no other option, for example when you need to add SMS messaging to an old system without modifying it.

If an old system, SAP for example, exposes an API, that API goes straight into API Management. If the system’s only interface is a SELECT query against its database, you need an intermediate layer that exposes an API in the form of a workflow. First check whether someone has already exposed this data through an HTTP service: if a SELECT query against the database exists, someone may have had this need before.

One gateway organizes traffic and security rules

When systems connect through API Management, there is one gateway instead of point-to-point connections between every system. In large companies, it is a shared security and network facade: APIs are not exposed to the public internet piecemeal. Agents and applications get one consistent interface, even though the systems underneath use different protocols, SOAP for example, and different authentication methods. You can strengthen authentication at the gateway and leave older systems alone. A developer who wants to integrate has to identify themselves and describe the integration, so you can see who uses which system, also inside the company.

The speakers see a recurring pattern at clients: the companies they work with, often in regulated industries, have fairly tight security and network rules. If the systems are in one place and the APIs in another, it is hard to agree with the security, network and compliance teams on who can talk to whom. A shared gateway lets you set up network connectivity, approvals and security contracts in advance for two defined routes: from agents to API Management and from API Management to the individual APIs.

In a sense, this is allowlisting of internal APIs: you know who can consume which data. Compliance, usage accounting, visibility, monitoring and the security approval of how an API is exposed sit in one place.

Shared security rules at the gateway are another reason not to integrate systems directly one-to-one. The speakers see APIs as the main place where someone misuses the company’s systems, for example to rack up points or to try to get access.

The reference point is the OWASP API Security Top 10. Microsoft’s documentation makes it easy to find how API Management and other tools, for example Microsoft Defender for APIs or DDoS protection, address the individual threats on this list.

You cannot fully trust even an internal client. In a company with, say, 10 departments, different groups build APIs: employees, external contractors and vendors that built and delivered something. On top of that comes purchased SaaS that works as a black box and cannot be modified. Each of these groups has different experience and a different approach to security, so each can make a mistake. Since everyone integrates through API Management, the platform team and the security team can set shared rules for all exposed APIs and in this way patch potential holes.

Partners get a chosen subset of APIs through products

You can expose some APIs externally, and the products mechanism defines which subset a given consumer sees. The consumers are business partners, other companies or startups. They meet the agreed contracts, approvals and access conditions and consume only the data the company deliberately exposes to them. This way, the company can open new communication and sales channels, perhaps also new products.

This is part of the API Economy concept, which has been around for roughly 10 years. API Economy is the management term for the value that a company’s APIs provide. It is mainly about internal monetization: the company builds further systems and add-ons on the exposed data and creates value inside the company and outside it. It is not about selling APIs as SaaS with a pay-per-use fee.

A product in API Management groups APIs, for example as an integration with a certain type of system. The name sounds like SaaS, but you do not buy a product: you assign it to a consumer, a company or a project. One API can belong to many products. Through products, consumers authenticate and get authorized in a standardized way.

A self-hosted gateway keeps data in the private data center

A self-hosted gateway lets you serve on-premises systems without sending traffic to the cloud when the application and the API are in a private data center. In Protopia projects, roughly half of API Management deployments run in a hybrid model. In this model, the Developer Portal and the Control Plane, where you configure APIs, stay in the cloud. The gateway that exposes the APIs can run in two places.

The local gateway shortens the call path, which helps with latency and cuts the cost of data transfer to the cloud and back. The third gain is compliance: banking, medical or insurance data does not leave the private data center in any way, and the cloud holds only monitoring and possibly observability.

A gateway hosted locally on Kubernetes or on a virtual machine can also expose APIs externally, through the company’s own endpoint and firewall, under its internal rules. The APIs are then not exposed from a cloud region, such as West Europe in Amsterdam. So you can expose on-premises systems externally and at the same time bring them into the agent platform.

API Center and linting put APIs in order before exposure

The company finally knows which APIs it has, and linting in CI/CD lets only APIs described according to the standard onto the gateway. In the past, API Management deployments usually started from a pent-up need: the company had a large number of APIs built over the years and wanted to systematize them and expose them centrally. Often an integration team that wants to simplify its work is behind this, or people in a CTO role who see API Economy as central to the company’s future success.

Azure API Center is an API catalog that you can call a CMDB for APIs. Protopia often deploys it alongside API Management. APIs in the catalog do not have to be exposed through API Management: they can run directly or elsewhere. API Center holds a full description of each API, including machine-readable ones such as Swagger or OpenAPI, and replaces the outdated wiki pages that describe APIs.

API linting works like code analysis that checks security, naming, structure and vulnerabilities.

Many APIs already run today, so new standards create tension: the departments that expose APIs have to bend to them at some point. Protopia mainly deploys the platform, the processes and linting. The integration teams and the groups that expose the APIs are responsible for adapting the APIs to the standards.

APIOps moves API configuration into a repository

APIOps is an approach from the Microsoft API Management world, similar to GitOps in Kubernetes: policies, integrations and entire APIs are configured in a code repository, and the team only promotes this configuration to the next environments. Protopia has deployed it several times already.

An API and its revisions, versions or changes move from the development environment through integration, UAT and pre-production to production. There can be as many environments as the company needs. Reconfiguring an API by hand in each of them means more work and a risk of human error: someone clicks the wrong thing, moves something incorrectly or misses a setting in a policy or an orchestration. Git, on the other hand, keeps a change history: who changed what, when, where and why.

Without APIOps, an integration team of, say, 5–10 people would at some point become a bottleneck, because the whole company would come to it asking to integrate their APIs. One of the speakers once worked at companies where exposing an API required signing up for an architecture review board meeting, with a date 2 weeks out. The board returned a long list of fixes, and the whole process took 2–4 months, even though it was only a simple iteration.

With APIOps, developers create a branch themselves, code the integration and submit a pull request. Someone from the integration team reviews the changes and comments on what to fix. The pull request gives approval to deploy to the next environments and triggers automatic steps, such as linting for compliance with the standards. Developers need basic knowledge for this, so introducing APIOps comes with training in the company and awareness building. Knowledge spreads out, and the central team reviews changes instead of being a bottleneck.

The rollout starts with workshops and a list of processes

Before Protopia starts technical work, it usually runs workshops with the client. It brings together business architects and the people responsible for areas of the company and finds out from them which processes agents could improve. From such a long list, clients quickly see that they will end up with 10 or 30 agents or more, not one, two or three.

With a real platform in the organization, you pay the cost of API integration anyway. Protopia usually builds the platform so that it can be reused. At the start, this can cost a bit more: you have to build the foundations, connect the elements and pass internal certification in the security or procurement department.

Many of Protopia’s API Management deployments were built before anyone talked about LLMs, and putting the APIs in order was then a goal in itself for the organization.