The Agent Service Bus: The Most Important Infrastructure Nobody Is Building

This is the second article in Arion Research's "Future Enterprise" series, exploring how AI agents are restructuring enterprise technology. The series examines the architectural layers, competitive dynamics, and strategic decisions that will define the next era of enterprise software.

In the first article in this series, I introduced the Future Enterprise framework; a layered architecture for understanding how AI agents are unbundling traditional enterprise applications. The framework has three horizontal layers (Enterprise Platform, Agentic Platform, Collaboration), cross-cutting vertical services, and one piece of connective infrastructure that I called the Agent Service Bus.

Of everything in that framework, the Agent Service Bus may be the most strategically important component, and the one getting the least attention. Everyone is talking about AI models, agent platforms, and the death of per-seat pricing. Almost nobody is talking about the infrastructure that makes agents work together.

That is a problem. Because without a robust Agent Service Bus, the future enterprise does not work. You just get a collection of smart but isolated agents, each capable within its own domain but unable to collaborate, coordinate, or resolve conflicts when their goals intersect.

What the Agent Service Bus Actually Is

The Agent Service Bus sits between the Agentic Platform (where agents live and execute) and the Collaboration layer (where agents and humans interact). It is the connective tissue that enables agents to discover each other, communicate, delegate tasks, and resolve conflicts.

If you worked in enterprise IT during the 2000s, you remember the Enterprise Service Bus (ESB), the middleware layer that connected applications in a service-oriented architecture (SOA). The Agent Service Bus is the next-generation version of that concept, but the requirements are significantly more complex.

An ESB routed messages between applications with known interfaces. The applications were deterministic: given the same input, they produced the same output. The interfaces were defined in advance using standards like WSDL and SOAP. The ESB was a sophisticated message broker, but the things it was connecting were predictable.

AI agents are not predictable. They reason. They make judgment calls. They can produce different outputs from the same input depending on context. They may disagree with each other about the right course of action. They need to negotiate, not just communicate.

That difference in the nature of the endpoints changes everything about what the connective infrastructure needs to do.

Five Functions the Agent Service Bus Must Perform

Based on my analysis of the emerging enterprise agent landscape, the Agent Service Bus needs to handle five distinct functions. Current protocols and frameworks address some of these. None address all of them.

1. Capability Discovery

Before agents can work together, they need to know what other agents exist and what they can do. This sounds simple, but in a large enterprise with hundreds of agents from multiple vendors, it becomes a real infrastructure problem.

Capability discovery requires a registry; a machine-readable catalog of available agents, their skills, input/output specifications, access requirements, and performance characteristics. Think of it as a DNS for agents: instead of resolving domain names to IP addresses, it resolves task descriptions to agent capabilities.

The A2A protocol has made progress here with "Agent Cards", JSON-formatted capability descriptions that agents can publish and query. This is a solid foundation, but it is still early. Current Agent Card specifications do not yet require machine-readable definitions of skill inputs and outputs with typed fields and validation rules, which means automated orchestration can discover what agents exist but cannot always determine the exact structured data required to invoke them without additional documentation.

2. Intent Resolution

When a human or an orchestrating agent says "process this invoice," the Agent Service Bus needs to figure out which agent (or combination of agents) should handle the request. This goes beyond simple routing. It requires understanding the intent behind the request, matching it to available capabilities, and selecting the best agent or workflow based on context.

Intent resolution gets hard when multiple agents could handle the same request. Should the invoice go to the Oracle-native AP agent (which understands the full validation and approval workflow) or to a Frontier agent (which can orchestrate across Oracle, the vendor's portal, and the banking system in a single workflow)? The answer depends on context: the invoice amount, the vendor relationship, the compliance requirements, and the organizational policies that govern the process.

No current protocol handles intent resolution well. Both A2A and MCP assume that the caller knows which agent or tool to invoke. The intelligence required to match intent to capability; especially when multiple agents compete for the same task; lives in the orchestration layer, and there is no standard for how that orchestration should work.

3. Contract Negotiation

When one agent delegates a task to another, they need to agree on terms. What are the expected inputs and outputs? What is the acceptable response time? What happens if the task fails? Who bears responsibility for the outcome?

In the SOA era, service-level agreements (SLAs) were defined in advance between known systems. In an agentic world, contract negotiation needs to happen dynamically; at runtime, between agents that may not have interacted before. This is especially true in cross-vendor scenarios: when an Oracle agent delegates a sub-task to a Salesforce agent, the two need to establish a shared understanding of the task, the quality expectations, and the fallback behavior, all in real time.

This is entirely missing from current protocols. A2A defines task lifecycle states (submitted, working, completed, failed) but does not specify how agents negotiate the terms of a task before accepting it. MCP does not address agent-to-agent negotiation at all; it is designed for agent-to-tool connections, not peer-to-peer collaboration between autonomous agents.

4. Conflict Arbitration

What happens when two agents want to modify the same record? When Agent A (managing inventory) wants to release stock for a rush order and Agent B (managing procurement) wants to hold that stock for an incoming bulk purchase? In a deterministic system, you solve this with database locks and transaction isolation. In an agentic system, you need something more sophisticated; a mechanism for agents to surface conflicts, escalate when necessary, and reach resolution either autonomously or by involving a human decision-maker.

Conflict arbitration becomes even more complex in multi-vendor environments. If the conflicting agents are from different platforms; one native to Oracle, one operating through Frontier; there is no shared governance framework to adjudicate the dispute. Each platform has its own rules, its own priority system, and its own escalation logic.

This is an area where the enterprise software industry has almost no infrastructure. Current agent frameworks handle conflicts by giving the orchestrating agent final authority, which works in simple hierarchical setups but breaks down in the distributed, multi-vendor environments that large enterprises run.

5. Message Routing and Orchestration

The most basic function; and the one where current protocols are strongest; is simply getting messages from one agent to another reliably, securely, and with the right context attached.

A2A handles this reasonably well for agent-to-agent communication, with support for both synchronous and asynchronous (streaming) interactions, structured message formats, and task lifecycle management. MCP handles it well for agent-to-tool connections, with a growing ecosystem of over 10,000 active public servers covering everything from developer tools to enterprise deployments.

But routing alone is not enough. In complex enterprise workflows, the Agent Service Bus needs to orchestrate sequences of agent interactions; managing dependencies, handling partial failures, maintaining state across long-running processes, and ensuring that the overall workflow progresses even when individual agents encounter problems. This orchestration logic is where current protocols leave the most work to the implementer.

What We Learned from the ESB Era (and What Does Not Apply)

The enterprise software industry went through a version of this problem twenty years ago. The ESB era offers some useful lessons, and some cautionary tales.

Lesson 1: Standards matter, but they take too long

The SOA era produced a blizzard of standards: WSDL, SOAP, UDDI, WS-Security, WS-ReliableMessaging, WS-Transaction, and dozens more. The standards were technically rigorous but took years to mature, and by the time they were complete, the industry had largely moved on to REST APIs and pragmatic integration patterns. The lesson: do not wait for perfect standards. Build practical infrastructure now and let standards codify what works.

The agent interoperability space is at risk of repeating this pattern. A2A and MCP are good starting points, but the gap between what they provide and what the Agent Service Bus needs is wide. If the industry waits for protocol committees to close that gap, enterprises will build proprietary solutions that become the next generation of integration silos.

Lesson 2: The middleware layer becomes a control point

In the SOA era, the ESB vendors (TIBCO, IBM WebSphere, Oracle Fusion Middleware) controlled a strategically important layer. They were not the most glamorous companies in enterprise software, but they were among the most difficult to displace once embedded. The same will likely be true for whoever builds the Agent Service Bus. It is a high-switching-cost position because every agent interaction flows through it.

This is why the question of who builds the Agent Service Bus matters so much. If a single cloud provider or AI platform controls it, they gain leverage over the entire agentic ecosystem. If it is built on open standards, the control point shifts to implementation quality rather than protocol lock-in.

Lesson 3: Point-to-point integration does not scale

Before the ESB, enterprises connected applications directly, point-to-point integrations that created a tangled web of dependencies. The ESB solved this by centralizing integration logic. The same pattern is emerging with agents: early adopters are connecting agents directly, building custom integrations between specific agent pairs. This works for small deployments but will not scale to hundreds of agents from dozens of vendors.

The Agent Service Bus exists precisely to prevent this point-to-point mess from recurring. It is the abstraction layer that lets agents interact through a common infrastructure rather than requiring bespoke connections between every pair.

What does not apply: determinism

The biggest difference between the ESB era and the Agent Service Bus era is the nature of the endpoints. ESB-connected applications were deterministic. Agent Service Bus-connected agents are probabilistic. They reason, they have context, they make judgment calls. This means the infrastructure cannot just route messages; it needs to mediate between intelligent entities that may disagree, produce unexpected outputs, or require negotiation to resolve ambiguity. There is no precedent for this in enterprise middleware.

Who Should Build the Agent Service Bus?

This is the strategic question that should concern every enterprise technology leader and vendor. There are several candidates, each with a different angle:

The Cloud Providers

AWS, Azure, Google Cloud, and Oracle Cloud all have the infrastructure expertise and the customer relationships to build Agent Service Bus capabilities into their platforms. Google has already moved aggressively with A2A. The risk is fragmentation: if each cloud provider builds its own Agent Service Bus, you get cloud-specific agent ecosystems that do not interoperate well, exactly the lock-in problem that enterprises are trying to avoid.

The AI Platform Companies

OpenAI (with Frontier), Anthropic, and others could embed Agent Service Bus capabilities into their agent platforms. OpenAI is already building elements of this into Frontier; the Business Context layer and the agent orchestration capabilities are early Agent Service Bus functions. The risk is that the Agent Service Bus becomes captive to a single AI platform, which conflicts with the multi-model, multi-vendor reality of most enterprises.

The Traditional Middleware Companies

Companies with deep integration heritage, including Oracle (which acquired TIBCO-adjacent capabilities), IBM, and MuleSoft (Salesforce), have relevant expertise. They understand enterprise integration patterns, message routing, and the operational requirements of mission-critical middleware. The risk is that they bring ESB-era thinking to an agentic problem that requires new architectural patterns.

Open Standards Bodies

The Linux Foundation, through the Agentic AI Foundation, is already hosting both A2A and MCP. An open-standards approach to the Agent Service Bus would prevent vendor lock-in and encourage ecosystem-wide interoperability. The risk is the pace problem from the SOA era: standards bodies move slowly, and the enterprise cannot wait.

My assessment: the Agent Service Bus will likely emerge as a combination of open protocols (A2A and MCP as the foundation) and proprietary implementations that add the missing functions (intent resolution, contract negotiation, conflict arbitration). The winners will be the companies that build the best implementations on top of open standards; the same pattern that played out with HTTP, REST, and cloud computing.

What This Means for Enterprise Leaders

If you are making technology decisions today, here is what the Agent Service Bus gap means for you:

Recognize that agents without orchestration are just expensive chatbots. The value of AI agents comes from their ability to collaborate, with each other and with humans, across complex workflows. If your agents cannot discover, communicate with, and negotiate with other agents, you have automated individual tasks but you have not transformed how work gets done.

Push your vendors on interoperability. Ask every AI platform vendor and enterprise software vendor the same question: how do your agents participate in multi-vendor workflows? If the answer is "they work great within our ecosystem" and nothing more, that is a warning sign. The future enterprise will not be single-vendor.

Do not build point-to-point agent integrations. It is tempting to connect agents directly -- Agent A talks to Agent B through a custom integration. This is the same mistake enterprises made before the ESB, and it will create the same tangled web of dependencies. Invest in an orchestration layer from the start, even if the first version is simple.

Watch the standards space closely. A2A and MCP are the two protocols that matter right now. Both are under the Linux Foundation. Both are evolving rapidly. The decisions being made in these working groups over the next 12-18 months will shape the agent infrastructure landscape for a decade. If your organization has the resources, participate directly.

Plan for the missing functions. Capability discovery and message routing are largely solved by current protocols. Intent resolution, contract negotiation, and conflict arbitration are not. If you are deploying agents at scale, you will need to build or buy solutions for these functions. Do not assume the protocols will catch up before you need them.

The Agent Service Bus is not glamorous. It is middleware; the plumbing that makes the system work. But in every previous era of enterprise technology, the company or standard that controlled the integration layer ended up controlling the ecosystem. The same will be true for agents.

The infrastructure is not ready yet. The companies and standards bodies that close the gap fastest will shape the future enterprise architecture for the next decade. And the enterprises that recognize this early, that invest in orchestration alongside intelligence, will be the ones that capture the full value of the agentic shift.

Next in the series: "Native vs. External Agents: The Depth-Breadth Trade-off in Enterprise AI", examining the structural advantages and limitations of agents embedded in applications versus agents operating from horizontal platforms.