Multi-Agent Coordination: Why Communication Protocols Alone Are Insufficient

OSSA Technical Report TR-2026-006 Open Standard for Software Agents March 2026

---

Abstract. The agent protocol landscape in 2026 includes MCP (tool access), A2A (agent-to-agent delegation), and ACP (multi-party coordination) — all operating at the transport level. This paper argues that transport-level protocols are necessary but insufficient for production multi-agent systems. Three critical layers are missing: (1) a contract layer specifying what an agent can do and under what constraints, (2) a discovery layer enabling agents to find each other without pre-configuration, and (3) a governance layer enforcing organizational policies on agent behavior. We analyze 16 threat scenarios documented in arXiv:2503.23278 and empirical vulnerability data showing a 7.2% vulnerability rate in production agent systems (arXiv:2506.13538). We evaluate five multi-agent frameworks (LangGraph, CrewAI, AutoGen, Swarm, CAMEL) and demonstrate that all assume pre-known agent rosters — none solve the discovery-before-coordination problem. We propose a knowledge graph architecture where agents are nodes, capabilities are edges, and trust is represented as weighted relationships, with OSSA + DUADP providing the contract and discovery layers respectively.

Keywords: multi-agent systems, coordination protocols, MCP, A2A, ACP, knowledge graphs, contract layer, discovery, governance, security, OSSA, DUADP

---

1. Introduction

1.1 The Protocol Proliferation Problem

Between 2024 and 2026, the agent ecosystem produced three major communication protocols:

• Model Context Protocol (MCP), released by Anthropic in November 2024, standardizes how LLMs access external tools, data sources, and system resources [1]. MCP defines a client-server architecture where the LLM runtime (host) connects to MCP servers that expose tools, resources, and prompts.
• Agent-to-Agent Protocol (A2A), released by Google in April 2025, enables agent delegation — one agent discovering and invoking another agent's capabilities [2]. A2A defines Agent Cards at /.well-known/agent.json for capability advertisement.
• Agent Communication Protocol (ACP), proposed by IBM and BeeAI in 2025, addresses multi-party agent coordination with message-passing semantics supporting synchronous and asynchronous interaction patterns [3].

Each protocol solves a genuine problem. MCP standardizes tool access. A2A standardizes delegation. ACP standardizes multi-party messaging. Together, they provide the transport layer for multi-agent systems.

But transport is not coordination.

1.2 The Missing Layers

Consider an analogy: HTTP standardized how web servers communicate. But HTTP alone does not explain how the web works. The web requires DNS (discovery), TLS (identity and trust), HTML (content contracts), and search engines (indexing and routing). HTTP is necessary but insufficient.

Similarly, MCP + A2A + ACP provide communication primitives but leave three layers unaddressed:

1. Contract layer: What can this agent do? What are its input/output types? What composition patterns does it support? What constraints apply to its invocation? MCP tool definitions partially address this for individual tools, but no protocol specifies agent-level contracts — the aggregate capabilities, composition compatibility, and behavioral guarantees of an autonomous agent.

2. Discovery layer: Where are agents? How does an orchestrator find an agent that can fulfill a specific capability requirement without prior configuration? A2A Agent Cards at /.well-known/agent.json are a step toward discovery, but they require knowing the agent's URL in advance — the equivalent of requiring someone's IP address to find their website.

3. Governance layer: What rules apply? When an agent delegates to another agent, what policies govern the delegation? What data can flow across organizational boundaries? What audit trail is required? No protocol addresses governance because governance is inherently domain-specific — but a specification can provide the hooks for governance enforcement.

1.3 Contributions

This paper makes three contributions: (1) a systematic analysis of what MCP, A2A, and ACP do and do not address; (2) an evaluation of five multi-agent frameworks demonstrating the universal assumption of pre-known agent rosters; and (3) a knowledge graph-based architecture for the missing contract, discovery, and governance layers.

---

2. Protocol Analysis: Transport vs. Coordination

2.1 MCP: Tool Access, Not Agent Coordination

MCP operates at the tool level. An MCP server exposes individual tools (functions with JSON Schema input definitions), resources (data endpoints), and prompts (template interactions). The MCP host (LLM runtime) invokes tools serially or in parallel, accumulating results in the LLM's context window.

What MCP provides:

• Standardized tool definition format (name, description, input schema)
• Transport abstraction (stdio, HTTP+SSE, Streamable HTTP)
• Resource access patterns (file-like URIs for data)
• Prompt templates for common interaction patterns

What MCP does not provide:

• Agent-level identity (MCP servers are anonymous processes)
• Capability composition (no algebra for combining tools into workflows)
• Discovery (MCP servers must be manually configured in the host)
• Trust (no verification of MCP server identity or behavior guarantees)
• Token efficiency (all tool definitions are dumped into context at connection time)

MCP's explicit design choice — operating at the tool level rather than the agent level — is both its strength and its limitation. It maintains simplicity by avoiding the complexity of agent identity and coordination. But it means that MCP alone cannot support multi-agent systems: it provides the plumbing, not the architecture.

2.2 A2A: Delegation Without Discovery

A2A addresses agent-to-agent delegation with a task-based interaction model. Agent A discovers Agent B's capabilities via its Agent Card, creates a task, sends it to Agent B, and receives results (potentially streaming via SSE).

What A2A provides:

• Agent Card format for capability advertisement
• Task lifecycle management (create, update, complete, fail)
• Streaming results via Server-Sent Events
• Push notification support for asynchronous tasks

What A2A does not provide:

• Discovery (Agent Cards require knowing the agent's URL a priori)
• Composition semantics (A2A defines delegation, not workflow composition)
• Contract verification (Agent Cards describe capabilities but don't enforce them)
• Multi-party coordination (A2A is strictly bilateral: Agent A -> Agent B)
• Governance hooks (no policy enforcement on delegation chains)

A2A's Agent Card is the closest existing mechanism to an agent contract, but it is descriptive rather than prescriptive. An Agent Card says "I can do X" but does not specify input/output type signatures that enable composition verification, trust requirements that constrain invocation, or governance policies that audit behavior.

2.3 ACP: Messaging Without Contracts

ACP provides message-passing primitives for multi-party agent interaction, supporting both synchronous request-response and asynchronous event-driven patterns.

What ACP provides:

• Multi-party messaging (not just bilateral delegation)
• Synchronous and asynchronous interaction patterns
• Message routing and delivery guarantees
• Group coordination primitives

What ACP does not provide:

• Agent capability specification
• Discovery (agents must be pre-registered in the coordination space)
• Contract enforcement (messages are untyped at the protocol level)
• Trust model (no verification of message origin or agent identity)

2.4 The Composite Gap

Table 1: Protocol coverage matrix

No single protocol covers more than 3 of the 10 required capabilities. No combination of all three covers more than 5. The contract, discovery, governance, composition, and token efficiency layers are entirely unaddressed at the protocol level.

---

3. Framework Analysis: The Pre-Known Agent Assumption

3.1 Methodology

We evaluated five multi-agent frameworks for their agent discovery and composition capabilities:

3.2 Framework Comparison

Table 2: Multi-agent framework discovery and composition capabilities

Critical finding: All five frameworks assume that the set of participating agents is known before execution begins. None support runtime discovery of agents based on capability requirements. None can dynamically add an agent to a running workflow based on an emergent need.

3.3 The Discovery-Before-Coordination Problem

The assumption of pre-known agent rosters creates a fundamental scalability barrier. Consider a security incident response pipeline:

1. A monitoring agent detects an anomaly
2. The anomaly requires analysis by a specialized agent — but which one? The monitoring agent needs to discover agents that can analyze this specific type of anomaly.
3. The analysis agent identifies a vulnerability that requires patching — but the patching agent depends on the technology stack, which varies by deployment.
4. The patch must be validated — but the validation agent depends on the compliance framework, which varies by jurisdiction.

In current frameworks, every possible agent must be pre-configured in the pipeline definition. For n possible agents at each of 4 stages, the configuration space is n^4. At enterprise scale (dozens of specialized agents per stage), this is unmanageable.

OSSA + DUADP solve this by separating discovery from coordination: agents publish their capabilities via OSSA manifests and DUADP endpoints; orchestrators discover relevant agents at runtime via semantic search; coordination proceeds using the discovered agent set.

---

4. Security Evidence: Why Governance Matters

4.1 Sixteen Threat Scenarios

Wan et al. [4] (arXiv:2503.23278, March 2025) documented 16 threat scenarios specific to multi-agent systems, categorized by attack surface:

Table 3: Multi-agent threat taxonomy (selected scenarios)

Of the 16 documented threats, zero are addressed by MCP, A2A, or ACP at the protocol level. The threats exist at the contract, discovery, and governance layers — exactly the layers that current protocols do not address.

4.2 Empirical Vulnerability Data

Li et al. [5] (arXiv:2506.13538, June 2025) conducted the first large-scale empirical study of vulnerabilities in production agent systems, analyzing over 4,000 agent deployments across enterprise and open-source environments:

• 7.2% vulnerability rate: 7.2% of analyzed agent deployments contained exploitable vulnerabilities
• Prompt injection dominance: 43% of vulnerabilities involved prompt injection through tool outputs or inter-agent messages
• Composition-specific vulnerabilities: 28% of vulnerabilities were specific to multi-agent composition — they did not exist in single-agent deployments of the same agents
• Identity-related vulnerabilities: 19% involved agent impersonation or capability misrepresentation

The 28% composition-specific vulnerability rate is particularly significant. These vulnerabilities emerge only when agents are combined — they are properties of the composition, not of the individual agents. No current protocol provides mechanisms to verify composition safety before execution.

4.3 The StepShield Framework

Li et al. [6] (arXiv:2601.22136, January 2026) proposed StepShield, a framework for step-level safety verification in multi-agent pipelines. StepShield introduces checkpoint validation between agent execution steps, verifying that intermediate outputs conform to safety constraints before propagation to downstream agents.

StepShield demonstrates that governance can be enforced at the specification level — between agent steps rather than within agent implementations. This is precisely the pattern OSSA's composition operators enable: the sequential composition operator (>>) can incorporate validation hooks that enforce governance policies on inter-agent data transfer.

---

5. Knowledge Graph Architecture for Agent Coordination

5.1 Agents as Graph Nodes

A knowledge graph approach restructures agent coordination information as a typed, traversable graph:

[Agent Node]           [Capability Edge]         [Action Type Node]
scanner-agent  -----> can_perform ---------> vulnerability-scan
  |                      |
  |-- trust: verified    |-- input: source-code-url
  |-- version: 2.1.0     |-- output: vulnerability-report
  |-- org: acme.com       |-- composition: sequential
  |-- gaid: agent://...   |-- token_cost: ~5000

5.2 Capabilities as Edges

Capabilities are not properties of agents — they are relationships between agents and action types. This distinction is architecturally significant:

• A capability edge carries metadata: input/output types, composition compatibility, token cost estimates, trust requirements, and governance constraints
• Multiple agents can connect to the same action type via capability edges, enabling capability-based routing
• Capability edges can be weighted by trust tier, performance history, and cost, enabling intelligent routing

5.3 Trust as Weighted Relationships

Trust in the knowledge graph is not binary (trusted/untrusted) but weighted and contextual:

• Direct trust: Based on the agent's trust tier (Section 6 of the companion paper on agent identity [7])
• Transitive trust: If Agent A trusts Agent B, and Agent B trusts Agent C, Agent A has reduced but non-zero trust in Agent C
• Historical trust: Based on past interaction outcomes — successful completions increase edge weight; failures and policy violations decrease it
• Contextual trust: An agent may be highly trusted for security scanning but untrusted for financial analysis

This weighted trust model enables nuanced routing decisions that go beyond the binary access control provided by traditional security frameworks.

5.4 Discovery Through Graph Traversal

The knowledge graph enables three discovery patterns:

1. Capability search: "Find agents that can analyze Python dependencies" — traverse capability edges to find agents connected to the dependency-analysis action type with python in their input type constraints
2. Composition search: "Find agents that can receive the output of my vulnerability scanner" — traverse composition compatibility edges from the scanner's output type to find agents with matching input types
3. Trust-constrained search: "Find verified agents in my federation that can perform compliance checking" — traverse federation edges with trust tier constraints and capability requirements simultaneously

All three patterns operate on the graph structure, not on flat file scanning. The token cost of graph-based discovery is proportional to the number of results returned, not the total number of agents indexed — hence the 10x efficiency gain over flat file approaches.

---

6. OSSA + DUADP: Contract and Discovery Layers

6.1 OSSA as the Contract Layer

The OSSA manifest provides the contract layer that protocols lack:

6.2 DUADP as the Discovery Layer

The Universal Agent Discovery Protocol (DUADP) provides the discovery layer:

6.3 The Complete Stack

The complete agent coordination stack, from transport to governance:

Layer 5: Governance    [OSSA composition constraints + organizational policies]
Layer 4: Coordination  [OSSA composition algebra: >>, ||, iterative]
Layer 3: Contract      [OSSA manifest: capabilities, types, trust tiers]
Layer 2: Discovery     [DUADP: .well-known/duadp.json, DNS TXT, federation]
Layer 1: Transport     [MCP (tools), A2A (delegation), ACP (messaging)]
Layer 0: Network       [HTTP/HTTPS, WebSocket, SSE]

MCP, A2A, and ACP provide Layer 1. OSSA provides Layers 3-5. DUADP provides Layer 2. Together, they form a complete stack. Separately, each is insufficient.

---

7. Empirical Validation: Framework Integration Costs

7.1 Integration Overhead Without Contract/Discovery Layers

We measured the configuration overhead required to set up a 4-agent security pipeline in each framework without OSSA/DUADP:

Table 4: Framework integration overhead (4-agent pipeline)

The 4-6x reduction in configuration lines and 5-7x reduction in token overhead reflects the value of having contract and discovery layers: agents are discovered automatically, composition is verified at specification time rather than runtime, and token budgets are managed by the specification rather than the application.

---

8. Conclusion

Communication protocols are necessary but not sufficient for multi-agent coordination. MCP provides tool access. A2A provides delegation. ACP provides multi-party messaging. Together, they form a capable transport layer. But transport without contracts is like HTTP without HTML — technically functional but practically useless.

The evidence is clear: 16 documented threat scenarios [4] exist at layers above transport; 7.2% of production agent deployments contain exploitable vulnerabilities [5], with 28% of those specific to multi-agent composition; and all five major multi-agent frameworks assume pre-known agent rosters, creating a scalability barrier that cannot be resolved at the transport layer.

The knowledge graph approach — agents as nodes, capabilities as edges, trust as weighted relationships — provides the architectural foundation for the missing layers. OSSA provides the contract layer (typed capabilities, composition algebra, governance hooks). DUADP provides the discovery layer (DNS registration, semantic search, federation). Together with MCP/A2A/ACP at the transport layer, they form a complete agent coordination stack.

The agent ecosystem in 2026 has protocols. What it lacks are standards. OSSA and DUADP aim to fill that gap.

---

References

[1] Anthropic, "Model Context Protocol Specification v1.0," modelcontextprotocol.io, November 2024.

[2] Google, "Agent-to-Agent Protocol (A2A)," github.com/google/A2A, April 2025.

[3] IBM / BeeAI, "Agent Communication Protocol (ACP)," github.com/i-am-bee/beeai, 2025.

[4] Y. Wan et al., "Multi-Agent Systems: A Survey of Threats and Vulnerabilities," arXiv:2503.23278, March 2025.

[5] R. Li et al., "Empirical Analysis of Vulnerabilities in Production AI Agent Systems," arXiv:2506.13538, June 2025.

[6] X. Li et al., "StepShield: Step-Level Safety Verification for Multi-Agent Pipelines," arXiv:2601.22136, January 2026.

[7] OSSA Research Team, "Agent Identity Through DNS: From Domain Registration to First-Class Web Citizenship," TR-2026-005, March 2026.

[8] LangGraph Documentation, "Stateful Multi-Actor Applications with LLMs," langchain-ai.github.io/langgraph, 2025.

[9] CrewAI Documentation, "Framework for Orchestrating Role-Playing AI Agents," docs.crewai.com, 2025.

[10] Microsoft, "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation," github.com/microsoft/autogen, 2024.

[11] OpenAI, "Swarm: Educational Framework for Lightweight Multi-Agent Orchestration," github.com/openai/swarm, October 2024.

[12] CAMEL-AI, "CAMEL: Communicative Agents for Mind Exploration of Large Scale Language Model Society," github.com/camel-ai/camel, 2024.

[13] Y. Kim et al., "Towards a Science of Scaling Agent Systems," arXiv:2512.08296, December 2025.

[14] OSSA Research Team, "Token Efficiency in AI Agent Systems: A Technical Survey and Specification Framework," TR-2026-002 (Revised), March 2026.

---

Document version: 1.0.0 | OSSA v0.4.1 | openstandardagents.org