Agent Communication Protocol as peer-to-peer AI Agent nteractions

Summary (TL;DR)

We chose the Agent Communication Protocol (ACP) as our standard for peer-to-peer AI agent interactions because it provides scalable, vendor-neutral interoperability over plain HTTP, complements existing tool-access protocols (e.g., MCP), and requires no special SDKs, only standard RESTful calls. Compared with bespoke integrations or proprietary/vendor-locked APIs and even early alternatives like Google’s A2A, ACP minimizes custom glue code, avoids lock-in, and leverages broad community governance, while remaining simple to adopt and operate.

Decision Log Metadata

Field
Value

Decision ID

DL-2025-06-03-001

Date

03 June 2025

Status

Accepted

Owner

Haluan Mohammad Irsad

Reviewers

-

Scope

Peer-to-peer communication layer for AI agents across frameworks

  1. Context • Today’s AI agents are isolated silos; integrations are custom point-to-point “duct tape,” costly to build and brittle to maintain. • Anthropic’s Model Context Protocol (MCP) standardizes tool/data access but does not address inter-agent messaging. • Need: a vendor-neutral, open, web-native protocol so agents from different teams/platforms can discover and talk to each other directly. • Constraints: must work in air-gapped or zero-trust environments, use standard HTTP tooling, and coexist with MCP.

  2. Options Considered

Option
Description
Interoperability
Vendor Neutrality
Maturity
Complexity

A. Custom Integrations

One-off adapters per framework pair

❌

❌

N/A

High

B. Proprietary Vendor Protocols

Closed-source APIs from individual platforms

❌

❌

High

Medium

C. Google’s A2A Protocol

Early open alternative for agent-to-agent messaging

✔️

❌

Early

Medium

D. Agent Communication Protocol (ACP)

RESTful HTTP standard under Linux Foundation

✔️

✔️

Early

Medium

  1. Decision We will adopt ACP as our default protocol for agent-to-agent interactions. Agents will expose ACP endpoints over HTTP (synchronous and asynchronous), embedding metadata for dynamic discovery. MCP remains responsible for tool/data access; ACP governs peer messaging and orchestration.

  2. Rationale

4.1 Interoperability

  • A single open standard removes the need for N² custom adapters.

  • Any agent with an HTTP stack can join the mesh, no bespoke SDK required.

4.2 Vendor Neutrality

  • Governed by the Linux Foundation, ACP avoids lock-in and encourages community contributions.

  • Competes fairly against proprietary offerings and early alternatives like A2A.

4.3 Flexibility

  • Supports both request/response and fire-and-forget patterns over plain REST.

  • Operates in air-gapped or zero-trust networks via embedded metadata.

4.4 Complementarity

  • ACP is orthogonal to MCP: MCP handles tool invocation; ACP handles peer messaging and workflow orchestration.

  • Teams can incrementally add ACP endpoints alongside existing MCP integrations.

  1. ACP Architecture

Key components

Component
Role

ACP Transport

Standard RESTful HTTP endpoints for peer messaging

Discovery Metadata

Agent-provided info (capabilities, endpoints) for discovery

Optional Async Broker

Queue (e.g., Kafka) for decoupled, fire-and-forget messages

Model Context Protocol

Continues to govern tool/data access

  1. Consequences & Trade-offs

Aspect
Positive Impact
Negative Impact
Mitigation

Interoperability

Dramatically fewer custom integrations

Protocol evolving; breaking changes possible

Strict versioning; stable releases

Vendor Lock-in

Open standard prevents lock-in

Requires broad ecosystem adoption

Provide reference implementations

Adoption Effort

Leverages ubiquitous HTTP tooling

Agents must implement ACP endpoint wrappers

Incremental rollout & training

Runtime Overhead

Minimal; HTTP on the wire

Slight latency vs in-process calls

Benchmark & optimize HTTP clients

  1. Future Considerations

  • Adaptive Versioning: automate schema evolution and backward compatibility.

  • Hybrid Messaging: integrate WebSockets or HTTP/2 for streaming scenarios.

  • Security Profiles: mTLS, JWT claims for enhanced trust.

  • Unified Orchestration: a control plane to visualize multi-agent workflows.

  • Observability: per-message tracing and lineage tags.

Annotated References

[1]: https://research.ibm.com/blog/agent-communication-protocol-ai

[2]: https://modelcontextprotocol.io/introduction

[3]: https://agentcommunicationprotocol.dev/introduction/welcome

PreviousAI Model Quantization Preference for Customer Facing Services

Last updated