Software developmentEnterprise Service Bus

From ESB to APIs, events and MCP: how integration works when AI agents are the new clients

Updated 11 min readBy Davinder Kumar Meen

Thick orange lines bending and running in parallel across a navy tiled background

An enterprise service bus (ESB) is middleware that sits between applications and routes, transforms and mediates the messages they exchange. Its jobs still have to be done; what changed is where they live. In 2026 most organisations do them with APIs described in OpenAPI, events on a managed bus such as Amazon EventBridge, and, for AI agents, the Model Context Protocol (MCP), a standard way for an agent to discover and call your systems. If you are putting an agent in front of your order, CRM or ticketing systems, you need all three layers and an authorization model, not a new bus.

Key takeaways

  • The ESB's core functions (routing, transformation, protocol conversion, orchestration, mediation, security, transaction coordination, decoupling) are still required; the microservices movement moved most of them out of the middle. Lewis and Fowler (2014): "The microservice community favours an alternative approach: smart endpoints and dumb pipes."
  • The standards that replaced the bus are mature: OpenAPI 3.2.0 (19 September 2025) describes HTTP APIs; AsyncAPI 3.0.0 (5 December 2023) describes event-driven ones; EventBridge is "a serverless service that uses events to connect application components together".
  • MCP is "an open-source standard for connecting AI applications to external systems", described by its authors as "like a USB-C port for AI applications". Servers expose three things: resources (data), prompts (templates) and tools (functions the model can call). The current specification is dated 2026-07-28.
  • MCP's authorization for HTTP transports is based on OAuth 2.1, and its security guidance forbids "token passthrough" and requires per-client consent. Anthropic donated MCP to the Agentic AI Foundation under the Linux Foundation on 9 December 2025, citing "more than 10,000 active public MCP servers".

What an ESB is, and what it got right

The 2023 version of this article defined an ESB as "a middleware architecture that facilitates the integration of different applications and services within an enterprise" by "offering services such as message transformation, routing, protocol conversion, and mediation". Still accurate. Its list of core functions is worth keeping, because every integration, including one that serves an AI agent, answers the same eight questions:

  1. Transformation: how a message in one system's format becomes another's.
  2. Routing: which system a request goes to, and on what criteria.
  3. Orchestration: how a multi-step business process is sequenced across systems.
  4. Mediation: how one component can offer several interfaces (a legacy flat-file one and a modern one) at the same time.
  5. Security: who may send what, and how messages are protected in transit.
  6. Transaction management: what happens when step three of five fails.
  7. Decoupling: how one system changes without breaking the others.
  8. Protocol conversion: SOAP to REST, file to message, and so on.

The ESB answered all eight in one product in the middle of the network. For a company running a dozen packaged applications with incompatible interfaces, that was and sometimes still is sensible, and the integration platforms sold today (iPaaS) are its descendants.

Why the bus went out of fashion

Three things happened. Applications moved to SaaS with their own HTTP APIs, so the protocol-conversion problem shrank. Teams adopted microservices and found that a smart bus became a bottleneck owned by a separate team. And event streaming made asynchronous integration cheap.

Lewis and Fowler wrote the canonical criticism in 2014: products such as the ESB "often include sophisticated facilities for message routing, choreography, transformation" in the communication layer, whereas microservice teams connect services with "simple RESTish protocols". Routing and transformation moved into the endpoints and thin managed infrastructure (an API gateway, an event bus); orchestration moved into workflow services and the applications.

The three layers today

Need ESB era 2026 answer Standard or service
Expose a system's capabilities so others can call them Bus adapters and WSDL contracts HTTP APIs with a machine-readable description OpenAPI 3.2.0 (published 19 Sep 2025)
React to things that happen without coupling the systems Message queues behind the bus Events published to a managed bus, filtered and delivered to subscribers AsyncAPI 3.0.0 for the contract; Amazon EventBridge (event buses, pipes, scheduler) or an equivalent
Let an AI agent discover and use systems on a person's behalf Not a requirement An MCP server in front of the APIs, exposing a small set of tools with scoped permissions MCP specification 2026-07-28; OAuth 2.1-based authorization
Transform between formats Bus mapping tools In the endpoint, or in the pipe (EventBridge Pipes supports transformation and enrichment before delivery)
Orchestrate a multi-step process Bus orchestration engine A workflow service or the application; agents add a supervised variant
Security Bus policies Gateway authentication, OAuth scopes, per-tool consent for agents OAuth 2.1 draft, RFC 9728 for MCP

An AI agent does not replace the first two layers; it is a new client that needs them to be clean.

Where MCP fits

The protocol's own description: "MCP (Model Context Protocol) is an open-source standard for connecting AI applications to external systems", using JSON-RPC 2.0 messages between hosts (the AI application), clients (connectors inside it) and servers ("services that provide context and capabilities"). A server can offer three things:

  • Resources: "context and data, for the user or the AI model to use".
  • Prompts: "templated messages and workflows for users".
  • Tools: "functions for the AI model to execute".

Transports are standard input/output for local servers and HTTP for remote ones. Authorization for HTTP transports is based on OAuth 2.1: a protected MCP server "acts as an OAuth 2.1 resource server" and must validate that tokens were issued for it specifically; local servers instead "retrieve credentials from the environment".

Adoption is broad enough to plan around. Anthropic's December 2025 announcement of the donation to the Agentic AI Foundation (co-founded with Block and OpenAI; supported by Google, Microsoft, AWS, Cloudflare and Bloomberg) cited "more than 10,000 active public MCP servers" and "97M+ monthly SDK downloads", with ChatGPT, Cursor, Gemini, Microsoft Copilot and Visual Studio Code among the clients. Platform vendors are building to it: WooCommerce said in October 2025 that version 10.3 would "introduce the first version of the WooCommerce MCP", and Amazon Bedrock's managed knowledge bases can be discovered by "any MCP-compatible agent framework" through AgentCore Gateway.

A worked example: order status through an agent

A store runs Magento (Adobe Commerce) with a REST API, a shipping carrier with its own API, and a helpdesk. The business wants an assistant that answers "where is my order?" for authenticated customers and drafts a reply for staff when something is wrong.

  • The API layer already exists: the Magento order endpoint and the carrier's tracking endpoint, both described in OpenAPI.
  • The event layer carries shipment.delayed events from the carrier integration to an event bus, where a rule routes them to the helpdesk and to a queue.
  • The MCP server is a small service that exposes exactly three tools to the agent: get_order(order_id) (read-only, scoped to the authenticated customer), get_tracking(shipment_id) (read-only) and draft_reply(order_id, text) (creates a draft in the helpdesk; a person sends it). It holds its own credentials for Magento and the carrier; the agent never sees them. Refunds are not a tool.

This is the ESB's eight questions answered again, with the answers in different places: transformation in the MCP server, routing on the event bus, orchestration split between the agent (which tool next) and the workflow (what happens on delay), security in OAuth scopes and the tool list itself.

Security: what an agent must not be allowed to do

The MCP specification lists three principles up front: "User Consent and Control", "Data Privacy" ("Hosts must obtain explicit user consent before exposing user data to servers") and "Tool Safety" ("Tools represent arbitrary code execution and must be treated with appropriate caution"; tool descriptions "should be considered untrusted, unless obtained from a trusted server"). Its security best-practices document names the concrete failures: the "confused deputy" problem in proxy servers, "token passthrough" (an anti-pattern "explicitly forbidden in the authorization specification"), server-side request forgery during OAuth discovery, and scope inflation, against which it recommends "a progressive, least-privilege scope model".

Translate that into rules for any agent integration:

  • Expose tools, not databases. Each tool does one thing with validated inputs.
  • Read-only by default; every write tool has an approval step or a reversible effect.
  • Tokens are issued to the MCP server for the MCP server; nothing forwards a client's token downstream.
  • Log every tool call with who, what and why; keep the log where the agent cannot edit it.
  • Treat anything the agent reads (e-mails, documents, web pages, tool results) as untrusted input; the OWASP LLM Top 10's "prompt injection" arrives through those channels.

Making your systems agent-ready: the procedure

  1. Inventory the systems and their interfaces. For each: an HTTP API, an OpenAPI description, event output, or only a database and a UI? The last category is where the cost sits.
  2. Describe what exists. Write or generate OpenAPI 3.x documents for the APIs you own; ask vendors for theirs.
  3. Pick the first workflow using the test in the AI readiness audit: bounded, measurable, with a clear human approval point.
  4. Define the tool list for that workflow, as small as possible, with input validation and a read/write label on each.
  5. Put events where they belong. Anything that "happens" (order placed, shipment delayed, ticket closed) goes to a bus with an AsyncAPI schema, so workflows and the agent subscribe instead of polling.
  6. Build the MCP server in front of the APIs, holding its own credentials, implementing OAuth 2.1-based authorization for HTTP transport, and validating token audience.
  7. Add the approval step for every write tool, and a kill switch and spend limit for the agent as a whole.
  8. Evaluate before connecting a model: call each tool with good and bad inputs; then run the agent on 30 recorded cases and compare its actions with what a person did.
  9. Pilot for two weeks with logs reviewed daily, then widen.

When you still want a bus

If you run many packaged applications with SOAP, file or proprietary interfaces, need guaranteed delivery and compensating transactions across them, and have no engineering team to own endpoints, an integration platform remains the pragmatic choice. The advice above still applies: put the agent behind a narrow MCP server that calls the platform, rather than giving the agent the platform.

FAQ

Is an ESB the same as an API gateway?

No. An API gateway sits in front of HTTP APIs to handle authentication, rate limiting and routing; it does not transform messages between arbitrary formats or orchestrate processes. An ESB did those things in the middle. Most modern stacks use a gateway for APIs and a managed event bus for asynchronous integration.

What is MCP in one sentence?

The Model Context Protocol is an open standard, described by its maintainers as "a USB-C port for AI applications", that lets an AI application discover and call external systems through servers that expose resources, prompts and tools over JSON-RPC.

Does MCP replace my APIs?

No. An MCP server is a thin layer in front of your APIs that presents a small, safe set of tools to an agent and holds the credentials. The APIs, their OpenAPI descriptions and your event bus remain the integration layer; the agent is a new client of them.

How do I stop an AI agent doing damage in my systems?

Give it a short list of tools rather than system access; make tools read-only by default; require a person to approve writes; issue tokens to the MCP server only and never pass client tokens downstream; log every call; and treat everything the agent reads as untrusted input. These rules come from the MCP specification's security principles and the OWASP LLM Top 10.

Who controls the MCP standard?

Since 9 December 2025, the Agentic AI Foundation, a directed fund under the Linux Foundation co-founded by Anthropic, Block and OpenAI. The specification is versioned by date; the current version at the time of writing is 2026-07-28.

Impinge Solutions has built MCP servers and connects AI agents to Shopify, Magento, Laravel, Node and AWS systems through APIs, events and MCP servers, with a human in the loop. Pick one workflow for a pilot.

Sources

Share this article

Are you ready to partner with us?

Our good-natured team is waiting to hear your business requirements.

Book a free project call