Protocol Landscape
Protocol Landscape
Multi-agent systems without protocols are point-to-point integrations at scale. Every agent talks to every other agent in a custom, undocumented, unauditable way. That is not an architecture. That is technical debt accumulating at the speed of your development team.
Protocols give multi-agent systems the same thing HTTP gave the web: a shared language that lets independently built components compose without requiring prior coordination. Enterprises that adopt protocol standards early will have infrastructure that is vendor-portable, auditable, and interoperable. Those that build proprietary integration layers will rebuild everything when they change vendors.
The Emerging Protocol Stack
Three protocols have emerged as the foundation of enterprise multi-agent infrastructure. They are complementary, not competing.
MCP: Model Context Protocol
Developed by Anthropic and now broadly adopted, MCP defines how agents access tools and share context. It is the interface layer between an agent and the resources it needs: databases, APIs, file systems, code execution environments.
What MCP handles:
- Tool discovery and invocation
- Context window management across tool calls
- Structured resource access with defined permissions
- Consistent interface regardless of underlying tool implementation
Why it matters for enterprises: Without a standard like MCP, every agent-to-tool integration is a custom implementation. MCP makes tools pluggable. You build a tool once with an MCP interface, and any MCP-compatible agent can use it. That is infrastructure leverage.
A2A: Agent-to-Agent Protocol
Developed by Google and supported by a growing ecosystem, A2A defines how agents communicate with each other, delegate tasks, and coordinate on multi-step workflows.
What A2A handles:
- Task delegation between agents
- Capability discovery (what can this agent do?)
- Status reporting and handoff
- Structured communication between heterogeneous agent systems
Why it matters for enterprises: Complex workflows involve multiple agents with specialized capabilities. A2A means your orchestration agent does not need to be built by the same team as your execution agents. It enables composition across independently developed systems, which is how large organizations actually build software.
LDP: Lightweight Delegation Protocol
LDP addresses the governance layer that MCP and A2A leave open: identity, authorization, and provenance in multi-agent systems. When Agent A delegates a task to Agent B, and Agent B calls a tool, the audit trail needs to answer: who authorized this action, under what conditions, and what is the chain of delegation that led here?
What LDP handles:
- Cryptographically verifiable delegation chains
- Agent identity and authorization scope
- Provenance tracking for actions taken by autonomous systems
- Governance-compatible audit trails
Why it matters for enterprises: Regulators do not accept "the agent did it" as an explanation. LDP makes the delegation chain auditable and verifiable. For regulated industries, this is not optional infrastructure. It is a compliance requirement dressed in technical clothing.
LDP Research Background
LDP originated from academic research on the provenance paradox in multi-agent systems: the challenge of maintaining meaningful human accountability when chains of agent delegation obscure who authorized what. See: arXiv:2603.08852 (protocol) and arXiv:2603.18043 (provenance paradox).
How the Protocols Compose
These protocols operate at different layers of the stack. They are designed to work together.
graph TD
subgraph "Governance Layer"
LDP["LDP
Identity · Authorization · Provenance"]
end
subgraph "Coordination Layer"
A2A["A2A
Agent Communication · Task Delegation · Capability Discovery"]
end
subgraph "Resource Layer"
MCP["MCP
Tool Access · Context Sharing · Resource Management"]
end
subgraph "Infrastructure Layer"
Tools["Tools, APIs, Databases, Services"]
end
Human["Human / Orchestrator"] --> LDP
LDP --> A2A
A2A --> Agent1["Specialized Agent"]
A2A --> Agent2["Specialized Agent"]
Agent1 --> MCP
Agent2 --> MCP
MCP --> Tools
style LDP fill:#4a4a6a,color:#fff
style A2A fill:#3a5a4a,color:#fff
style MCP fill:#5a3a3a,color:#fff
style Tools fill:#3a3a5a,color:#fff
Reading the diagram:
- A human or orchestrating system initiates a workflow. LDP attaches identity and authorization scope to that initiation.
- A2A handles the coordination between agents: who does what, in what sequence, with what handoff conditions.
- MCP handles each agent's access to the tools and data it needs to execute.
- Every layer is observable, auditable, and standards-compliant.
This composition gives you a multi-agent system where every action is attributable, every delegation is authorized, and every tool call is mediated through a defined interface.
Why Protocol Choice Has Strategic Consequences
Interoperability
Proprietary agent-to-agent communication locks you into a single vendor's ecosystem. When you need to swap a model provider, integrate an acquired company's agent infrastructure, or adopt a new specialized tool, proprietary protocols make every integration a bespoke project.
Standard protocols make your infrastructure composable by default.
Vendor Independence
The AI vendor landscape is moving fast. The model that is best for your use case today may not be best in eighteen months. Organizations that build on standard protocols can swap components without rebuilding orchestration layers.
This is not theoretical. Organizations that built deeply proprietary RAG pipelines in 2023 are now rebuilding them to be model-agnostic.
Audit Trails
In regulated environments, audit trails are non-negotiable. Standard protocols, especially LDP, are designed with auditability as a first-class concern. Proprietary systems require custom audit infrastructure built on top of an opaque foundation.
The Proprietary Lock-In Risk
Several major platform vendors are offering "managed agent orchestration" with proprietary communication protocols. The switching cost of these platforms is the entire multi-agent infrastructure you build on them. Evaluate carefully before committing.
The Integration Question
The practical question for most enterprises is not which protocol to adopt in isolation. It is how to introduce protocol-aware infrastructure into an existing technology estate.
Most organizations will start with MCP because tool access is the immediate need. A2A becomes relevant when you have multiple agents coordinating on complex tasks. LDP becomes non-negotiable when you need to answer regulators, auditors, or executives about who authorized an action taken by an autonomous system.
The sequencing typically looks like this:
- MCP first: Standardize tool access for your first agent deployments. Build your tool library against MCP interfaces from day one.
- A2A when coordinating: As you build workflows that span multiple specialized agents, adopt A2A for coordination rather than building custom orchestration.
- LDP from the start for regulated workloads: Do not wait until you have a compliance problem to introduce provenance tracking. Retrofit is expensive.
What Enterprises Should Do Now
Adopt standards early. The protocols described here are not speculative. They have production implementations, active development communities, and growing enterprise adoption. Early adoption means your infrastructure is forward-compatible.
Audit your current agent builds for protocol alignment. If you have agents in production or pilots underway, map what protocols they use for tool access, coordination, and governance. Identify where proprietary dependencies exist and assess the switching cost.
Build protocol-aware infrastructure. Your developer platforms, CI/CD pipelines, and monitoring infrastructure should be designed to work with these protocols natively, not as afterthoughts.
Require protocol compliance in vendor evaluations. When evaluating agent platforms, orchestration tools, or managed agent services, require MCP compatibility, A2A support, and LDP-compatible audit trails as evaluation criteria. Vendors who resist this are selling proprietary lock-in.
The protocol layer is boring infrastructure work. It is also the foundation that determines whether your multi-agent architecture is maintainable, auditable, and vendor-portable five years from now.