Part 3 of the series "The Agent Coordination Gap"
From Framework to Implementation: How the Five Functions Map to Real Enterprise Architectures
From Concept to Wiring Diagram
The first two articles in this series established two things. First, enterprise agent estates are fragmented: dozens of agents, multiple vendor platforms, no coordination layer between them. Second, the emerging protocols (MCP and A2A) solve connectivity but leave governance, trust, and conflict resolution to someone else.
That someone else is the enterprise. And the question enterprises are now asking is practical: what does the coordination layer look like when you try to build it?
The Agent Service Bus framework, introduced in the Arion Research Orchestration series, describes five capabilities that a coordination layer needs: Capability Discovery, Intent Resolution, Contract Negotiation, Conflict Arbitration, and Routing and Orchestration. The framework is conceptual. This article closes that gap, mapping each function to the vendor platforms, open-source frameworks, and protocol specifications that are starting to deliver them.
The picture is uneven. Some functions have credible implementations. Others remain largely theoretical. And one, Conflict Arbitration, has almost no production-grade tooling at all, despite being the function that matters most when agents disagree.
Capability Discovery: The Function That Works
Capability Discovery is the coordination layer's inventory problem: agents need to find each other and understand what each can do before they can collaborate. Of the five Agent Service Bus functions, this one has the most mature implementations.
A2A's Agent Card provides the protocol-level foundation. Each agent publishes a machine-readable document describing its capabilities, supported protocols, and communication endpoints. The v1.0 specification added signed Agent Cards using JWS with JCS for domain verification, so a consuming agent can confirm that a card was published by the domain that claims it. The mechanism is sound for point-to-point discovery. What it does not provide is a registry: a centralized, searchable, governed catalog of all agents available to an enterprise.
Microsoft's Agent 365 fills that gap within the Microsoft ecosystem. The agent registry catalogs agents built on Copilot Studio, Azure AI Foundry, and third-party platforms. It is metadata and governance only: agents run on their own hosts, and the control plane receives their telemetry. Administrators get a managed inventory plus a separate experience for detecting agents that were never formally onboarded.
The limitation is reach. Third-party agents get registry import but not the same depth of policy enforcement available for first-party agents. The governance actions (publish, install, block, identity disable, compute stop) work most reliably within the Microsoft estate. Microsoft FastTrack documentation flags external registry sync as a preview feature that imports metadata only.
ServiceNow's AI Control Tower takes a different approach, positioning itself as a cross-vendor governance layer. Launched in May 2025 as a central console for overseeing ServiceNow and third-party agents, the product expanded significantly at Knowledge 2026. Its AI Agent Fabric provides agent-to-agent coordination using MCP and A2A as the transport protocols. ServiceNow has extended AI Control Tower governance to include the Microsoft Agent 365 ecosystem, including Copilot Studio and Azure Foundry agents. This cross-vendor reach is the product's differentiator: rather than requiring agents to live on ServiceNow's platform, it aims to discover and govern agents wherever they run.
On the open-source side, CrewAI's role-based architecture provides implicit capability discovery within a crew, matching tasks to agents based on defined roles and goals. CrewAI shipped A2A support in its v1.x release, adding both a client mode (discover and delegate to remote A2A agents) and a server mode (expose CrewAI agents as A2A-compliant endpoints). LangGraph treats discovery as a graph-design problem: agents are nodes, capabilities are defined by the edges and conditions that connect them. Discovery is structural, not dynamic.
The net assessment: Capability Discovery is the most mature Agent Service Bus function. Between A2A Agent Cards, Microsoft's registry, ServiceNow's cross-vendor catalog, and the framework-level patterns in CrewAI and LangGraph, enterprises have credible tools for answering the question "what agents do I have and what can they do?" The gap is not in any single product. It is in the absence of a unified, cross-vendor, standards-based registry that works equally well across all platforms. Every current implementation either favors its own ecosystem or requires manual integration to span vendor boundaries.
Intent Resolution: Where Frameworks Diverge
Intent Resolution translates a business request into a coordinated multi-agent plan. A user says "process this customer return." The coordination layer must determine which agents are needed (customer service, inventory, finance, shipping), in what sequence, with what data flows, and under what constraints. This is not routing. Routing sends a task to an agent. Intent Resolution decides what the task is, decomposes it into subtasks, and determines the collaboration pattern.
The open-source frameworks handle this differently, and the differences reveal distinct philosophies about how multi-agent systems should work.
LangGraph takes the graph-first approach. The developer designs a directed graph where nodes are agents or functions, edges define transitions, and state flows through the graph as a shared object. The graph itself is the intent resolution logic. LangGraph's built-in checkpointing and time-travel debugging allow developers to inspect how state evolved through the graph, replay from any checkpoint, and test alternative paths. For compliance-heavy workflows where every decision must be auditable, this is a significant advantage. The tradeoff is that graph design is engineering work. The resolution logic is explicit and predictable, but it must be designed and maintained by someone who understands both the business process and the framework's state management model.
CrewAI takes the role-first approach. You define agents by role ("Senior Research Analyst," "Financial Compliance Officer"), assign them tasks, and let the framework orchestrate execution. A process parameter controls the collaboration pattern: sequential (agents execute in order), hierarchical (a manager agent delegates and reviews), or consensual (agents discuss and reach agreement). Intent resolution in CrewAI is implicit in the task-to-role mapping. The framework decides which agent handles which subtask based on role fit. This is faster to prototype and easier for non-engineers to understand, but it offers less control over the exact execution path.
AutoGen, Microsoft's conversation-based framework, took a different approach: agents resolve intent through multi-turn group chat. The conversation itself produces the plan. The approach is flexible but expensive in token consumption, and Microsoft has since archived AutoGen in favor of the Microsoft Agent Framework, which suggests the conversation-based model did not scale to enterprise requirements.
AWS Bedrock AgentCore handles intent resolution through the supervisor pattern. A supervisor agent built on the Strands SDK receives the user request and decomposes it into tasks for specialist agents. The AgentCore Runtime manages the orchestration loop: the developer specifies the model, tools, and instructions in configuration, and AgentCore assembles the loop without requiring custom orchestration code. The managed harness reached general availability in June 2026, and AWS's own sales team reported a 41 percent latency reduction after migrating to AgentCore. Those are vendor-published figures, but the architectural pattern is sound: centralize the orchestration infrastructure and let the supervisor handle decomposition.
ServiceNow's AI Control Tower adds an enterprise-specific dimension to intent resolution through its runtime monitoring capabilities. The platform can observe agent reasoning and decisions in real time, and intervene when an agent exceeds its permissions. This is intent resolution as guardrail: rather than decomposing a request into subtasks, the system monitors whether the agent's interpretation of the request stays within bounds. For enterprises where the primary concern is not "did the agent solve the problem efficiently?" but "did the agent stay within its authority?", runtime monitoring is the more relevant capability.
The gap in intent resolution is cross-vendor decomposition. Every implementation described above works within a single framework or platform. None of them can take a business request and decompose it into a plan that spans agents on Microsoft, ServiceNow, and AWS simultaneously. A2A provides the message format for delegating a task from one agent to another, but it provides no specification for how the decomposition decision is made, what information the decomposer needs, or how constraints propagate across the delegation chain. Intent resolution across vendor boundaries remains a custom integration exercise.
Contract Negotiation: The Missing Middle
Contract Negotiation establishes the terms under which agents will collaborate: data sharing rules, action boundaries, escalation paths, SLA expectations, and completion criteria. In human terms, it is the work agreement that gets settled before a project starts. In agent terms, it is the specification of what each agent is allowed to do, what data it can access, and what happens when something goes wrong.
Of the five Agent Service Bus functions, Contract Negotiation has the least standardized implementation. No protocol specifies it. No major product markets it as a named capability. And yet every production multi-agent deployment implements some version of it, even if the implementation is ad hoc.
The protocol gap is clear. A2A's task model allows one agent to send a task to another and receive results. But it provides no structured way to attach constraints: "do not issue refunds over $500 without human approval," "access purchase history but not payment information," "complete within 30 minutes or escalate." Those constraints live in the agent's own instructions or the enterprise's policy engine. They are not part of the coordination protocol.
The closest implementations are platform-level policy engines. Microsoft Agent 365's access control pillar lets administrators define what agents can do, which data they can access, and under which conditions they need approval. But these policies are defined administratively, not negotiated at runtime. Administrative policy is static: set once, applied uniformly. Contract negotiation is dynamic: the terms may differ depending on the task, the data involved, and the requesting agent's trust level.
LangGraph's state management provides a mechanism that could support contract negotiation, though it is not designed for that purpose. Because state flows through the graph as a shared object, a node can inspect the state, apply conditions, and modify the execution path. A contract could be encoded as state: a set of key-value pairs that travel with the task and are checked at each node. This is engineering, not product. No one ships a "contract negotiation" feature in LangGraph. But the primitives are there.
The IETF Internet-Draft on enterprise A2A requirements, published in November 2025, explicitly calls for conflict resolution mechanisms in enterprise A2A use. The draft proposes rules that let agents resolve conflicts in outcomes and data inconsistencies with less manual intervention. It is an individual draft, not an adopted standard, but its existence signals that the standards community recognizes the gap.
For enterprises building multi-agent systems today, contract negotiation is implemented through configuration, not coordination. Agents are configured with their boundaries before deployment. The "contract" is baked into the system design, not negotiated at runtime. This works when the collaboration patterns are predictable. It breaks when they are not, and in a dynamic enterprise environment with 12 or more agents across multiple platforms, unpredictable collaboration patterns are the norm.
Conflict Arbitration: The Gap That Matters Most
Conflict Arbitration is the Agent Service Bus function with the largest gap between need and implementation. When agents from different platforms recommend or take contradictory actions, something must resolve the disagreement. A sales agent promises a delivery date. A supply chain agent has already allocated the inventory elsewhere. A pricing agent applies a discount that violates the terms a compliance agent is enforcing. These are not edge cases. They are the predictable consequence of running autonomous agents across multiple platforms with no shared state.
Neither MCP nor A2A provides a conflict arbitration mechanism. The arXiv governance assessment that scored both protocols at 1 out of 12 on enterprise governance features specifically identified the absence of deliberation support, voting mechanisms, and conflict resolution as gaps. The IETF draft acknowledges the need but offers no specification.
The open-source frameworks handle conflicts through architecture, not arbitration. LangGraph prevents conflicts by design: the graph topology determines which agents can act and in what order, so conflicting actions should not occur if the graph is correctly designed. This is conflict prevention, not conflict resolution, and it works only within a single graph. CrewAI's hierarchical process mode assigns a manager agent that reviews subordinate agent outputs and can override decisions, which is closer to arbitration, but the manager is a single agent within a single crew, not a cross-platform arbitrator.
The vendor platforms offer monitoring, not arbitration. ServiceNow's AI Control Tower can detect when an agent exceeds its permissions and shut it down in real time. Microsoft's Defender integration provides threat detection for agent behavior. AgentCore's supervisor can review specialist outputs before they are returned. All useful. None answers the question: when two agents on different platforms take contradictory actions, which one prevails and why?
The three-tier decision authority model from the Arion Research Operating Model Gap series provides the conceptual framework. Tier 1 conflicts (both agents within their autonomous parameters) should be resolved by a rules engine applying business priority. Tier 2 conflicts (at least one action requires human review) should be escalated with full context from both agents. Tier 3 conflicts should never reach the arbitration layer because agents should not be acting autonomously in those domains.
No product implements this as a cross-platform service. An analysis of 150 enterprise agent deployments found that the largest autonomy tier in production is "bounded autonomous action." The bounded pattern is itself a form of conflict avoidance: keep autonomy low enough that conflicts are unlikely. It works, but it limits the value that autonomous agents can deliver.
An April 2026 survey found that only 7.2% of enterprises have a named person formally accountable for agent behavior. Without clear accountability, conflict arbitration defaults to incident response: someone discovers the conflict after it has caused harm. For enterprises with 12 or more agents making commitments across platforms, reactive arbitration is not a strategy.
Routing and Orchestration: The Function in Motion
Routing and Orchestration directs work to the right agent or combination of agents based on capability, cost, context, and current load. Of the five functions, this is where investment is heaviest.
LangGraph is the strongest open-source option for complex orchestration. Its graph-based architecture provides explicit control over execution flow, conditional branching, and error handling. State checkpointing means a failed workflow can resume from the last successful node. Multiple comparison sources cite LangGraph as the preferred choice for production workloads requiring compliance-grade auditability.
CrewAI offers faster time-to-orchestration through its process modes: sequential, hierarchical, and consensual. Its A2A integration adds cross-framework routing, allowing CrewAI agents to delegate to agents built on other frameworks through the A2A protocol. This is one of the few production-ready examples of cross-framework orchestration in the open-source ecosystem.
AgentCore's managed harness is the most opinionated approach: define the agent's configuration and let AgentCore handle the orchestration loop. ServiceNow's AI Agent Fabric routes at the enterprise workflow level, using its workflow engine as the orchestration backbone.
The routing gap is the same gap that runs through every function: cross-vendor coordination. Routing within any single framework is excellent. Routing a task that starts in a CrewAI crew, delegates to an AWS Bedrock agent, and escalates to a human through ServiceNow requires custom integration at every boundary.
The Implementation Map
Mapping the five Agent Service Bus functions against current implementations produces a clear picture of where the industry stands.
Capability Discovery is the most mature function: A2A Agent Cards, Microsoft's registry, ServiceNow's cross-vendor catalog, and framework-level role definitions in CrewAI and LangGraph provide usable, if fragmented, tooling. Intent Resolution is well-served within individual frameworks (LangGraph's graphs, CrewAI's task-role mapping, AgentCore's supervisor pattern) but has no cross-vendor solution. Contract Negotiation is implemented through static configuration rather than dynamic runtime negotiation, a workable pattern for predictable collaborations and an inadequate one for everything else. Conflict Arbitration has the largest gap: no protocol support, no cross-platform product, and the only implementations are single-framework workarounds (LangGraph's graph topology, CrewAI's manager agent) that do not address the multi-vendor scenario where conflicts are most likely. Routing and Orchestration is strong within frameworks and platforms but weak across them.
The pattern is consistent: every function works within a single ecosystem and breaks at the boundaries between ecosystems. This is not surprising. It mirrors what happened with enterprise application integration 20 years ago, when every vendor had a good integration story within its own platform and integration across vendors required middleware. The agent coordination gap is the middleware gap of the AI era.
The difference, as the first article in this series argued, is that agents are not passive applications waiting for API calls. They make decisions and commitments. The consequences of uncoordinated agents are not data inconsistencies. They are broken promises to customers, conflicting business commitments, and governance failures that expose the organization to regulatory and reputational risk.
What the ServiceNow Signal Means
ServiceNow's AI annual contract value reaching $1 billion is a market signal worth reading carefully. It suggests that enterprises will pay for control and orchestration, not just generative AI features. The companies driving that number are not buying AI to generate text. They are buying governance, monitoring, and coordination infrastructure for an agent estate that has grown faster than their ability to manage it.
This is the same pattern that played out in cloud computing. The first wave was adoption: get workloads to the cloud. The second wave was management: get visibility, governance, and cost control across multi-cloud deployments. The agent management wave is arriving faster because the adoption wave was compressed, but the shape is the same. The companies that moved early on cloud management platforms gained an advantage. The same is likely true for agent coordination platforms.
Strategy Playbook
1. Map Your Agent Estate Against the Five Functions. For each of the five Agent Service Bus capabilities, assess your current maturity. Most enterprises will find reasonable coverage in Capability Discovery and Routing (within individual platforms), partial coverage in Intent Resolution, configuration-only coverage in Contract Negotiation, and no systematic coverage in Conflict Arbitration. The map tells you where to invest first.
2. Choose Your Orchestration Anchor. You need one framework or platform as the orchestration backbone for cross-agent coordination. LangGraph for engineering teams that need fine-grained control and compliance-grade auditability. CrewAI for teams that prioritize speed and role-based design. ServiceNow AI Control Tower for organizations already on the ServiceNow platform that want cross-vendor governance. AWS AgentCore for teams committed to AWS infrastructure. The anchor is not exclusive, but it is the system of record for how agents coordinate.
3. Build Conflict Arbitration Before You Need It. Do not wait for a product to solve this. Define escalation rules for the most likely agent conflicts in your environment: pricing versus compliance, sales commitments versus inventory availability, customer service actions versus financial controls. Encode the rules in your orchestration layer. Assign human decision-makers for Tier 2 conflicts. Ensure every conflict resolution is logged with full context from both agents. The tooling gap in Conflict Arbitration means this is engineering and organizational design work, not product selection.
4. Treat A2A as the Cross-Boundary Wire, Not the Coordination Layer. A2A provides the message format for agent-to-agent communication across vendor boundaries. It does not provide intent resolution, contract negotiation, or conflict arbitration. Use A2A for the connectivity it was designed to deliver. Build or buy the coordination logic separately. The enterprises that mistake protocol adoption for coordination strategy will repeat the pattern described in Article 1: agents that can talk to each other but still cannot work together.
Arion Research advises enterprise leaders on AI strategy and the shift to a digital workforce
