Agent Communication Protocol (ACP) — Welcome & Introduction
IBM Research / BeeAI Team (no individual byline) April 23, 2026 product-announcement medium credibility
View source
Referenced in catalog
Agent Communication Protocol (ACP) — Welcome & Introduction
Source: agentcommunicationprotocol.dev | Author: IBM Research / BeeAI Team | Published: 2025-03-01 Category: product-announcement | Credibility: medium
Executive Summary
- ACP is a REST-based open protocol created by IBM Research in March 2025 to enable interoperability between AI agents built on different frameworks; it was quickly donated to the Linux Foundation under the BeeAI project.
- The core thesis is that the AI agent ecosystem is fragmented across frameworks (LangChain, CrewAI, BeeAI, etc.) and that a standardized HTTP/MIME-type communication layer can enable agents to discover and call each other without framework-specific coupling.
- ACP’s standalone lifecycle was short: by August 2025 the project formally merged with Google’s Agent2Agent (A2A) protocol under the Linux Foundation’s LFAI & Data, with the ACP team winding down active development and contributing technology to A2A. The website remains live but represents a protocol that is now superseded.
Critical Analysis
Claim: “AI agents are often built in isolation, across different frameworks, teams, and infrastructures”
- Evidence quality: anecdotal
- Assessment: The fragmentation problem is real and well-documented: LangChain, CrewAI, AutoGen, Google ADK, and dozens of other frameworks each have proprietary communication conventions. The claim accurately describes the 2025 ecosystem state. However, the article presents the fragmentation as a novel problem being addressed for the first time, ignoring that Google’s A2A protocol (April 2025) launched only one month after ACP with overlapping goals and broader industry backing.
- Counter-argument: Fragmentation in agent communication is partly a symptom of the field’s immaturity. Standardizing too early risks locking in design decisions before the community understands what patterns actually work at scale. Both ACP and A2A emerged in the same 30-day window, which suggests either redundant effort or that neither team had sufficient awareness of the other’s work.
- References:
Claim: “ACP uses standard HTTP and MIME types rather than specialized protocols like JSON-RPC”
- Evidence quality: vendor-sponsored
- Assessment: The architectural choice of REST + MIME types over JSON-RPC is presented as a differentiator from A2A (which uses JSON-RPC 2.0). REST is genuinely simpler for adoption (curl/Postman usable without SDKs), but this framing is partially misleading. A2A also uses HTTPS, and JSON-RPC is itself a lightweight standard — the difference is primarily in message envelope format, not fundamental complexity. Neither protocol has published independent performance or adoption benchmarks validating one approach over the other.
- Counter-argument: JSON-RPC 2.0 (used by A2A and MCP) is a 12-year-old, well-understood protocol with robust tooling. The framing of MIME types as “simpler” elides the fact that agents need to agree on content semantics regardless of envelope format — MIME type extensibility defers, rather than solves, the shared ontology problem.
- References:
Claim: “ACP operates under community-driven governance at the Linux Foundation”
- Evidence quality: vendor-sponsored
- Assessment: Factually accurate at the time of writing — the BeeAI project (including ACP) was donated to the Linux Foundation in March 2025. However, “community-driven” overstates the reality: the core contributors were IBM Research employees, and the governance structure was nascent. The claim also became partially obsolete by August 2025 when ACP merged into A2A; the Linux Foundation stewardship continues but through the A2A project, not ACP independently.
- Counter-argument: Linux Foundation governance provides neutrality on paper but does not guarantee broad community participation. At time of merger, IBM was the dominant ACP contributor. The A2A Technical Steering Committee (post-merger) includes IBM’s Kate Blair alongside Google, Microsoft, AWS, Cisco, Salesforce, ServiceNow, and SAP — genuinely broader governance than ACP achieved alone.
- References:
Claim: “ACP complements MCP rather than competing with it — MCP handles context within agents, ACP handles communication between agents”
- Evidence quality: vendor-sponsored
- Assessment: The layering argument is technically coherent and echoed by independent analysts. MCP (Anthropic) solves tool/data connection for individual agents; ACP/A2A solve agent-to-agent communication. These are genuinely different layers. However, the article’s framing that ACP is the right answer for the inter-agent layer is now outdated: A2A, with 50+ enterprise partners and Linux Foundation governance, has absorbed ACP’s role.
- Counter-argument: The “complementary layers” argument, while technically sound, may oversimplify. In practice, multi-agent systems often communicate through shared state (databases, queues, message buses) rather than direct agent-to-agent HTTP calls. The assumption that agents should communicate via a specialized protocol rather than conventional infrastructure is not yet validated by production evidence.
- References:
Claim: “ACP supports both online and offline discovery via metadata embedded in distribution packages”
- Evidence quality: vendor-sponsored
- Assessment: The offline discovery mechanism (embedding agent metadata in distribution packages at build time, enabling discovery without a running registry) is a genuine architectural differentiator from A2A’s Agent Cards. However, this feature was contributed into A2A as part of the merger, so its practical value now accrues to A2A, not standalone ACP. No independent evidence of this mechanism working at scale in production has been published.
- Counter-argument: Offline discovery solves a real problem (avoiding centralized registry single points of failure), but it introduces its own challenges: stale metadata when agent capabilities change, version skew between discovery-time and runtime capabilities, and packaging overhead for lightweight utility agents. The article presents offline discovery as unambiguously positive without discussing these tradeoffs.
- References:
Credibility Assessment
- Author background: IBM Research team behind the BeeAI project — the primary developers and advocates for ACP. No independent author byline. This is a vendor documentation page, not an independent analysis.
- Publication bias: Vendor-originated documentation site. All content is first-person advocacy for ACP. No independent validation, no benchmarks, no failure modes discussed.
- Verdict: medium — The technical claims are generally accurate but selectively presented. The governance narrative is somewhat overstated. Most critically, the site does not disclose that ACP has been deprecated in favor of A2A; the “welcome” page reads as if ACP is the active standard, which is misleading as of late 2025.
Entities Extracted
| Entity | Type | Catalog Entry |
|---|---|---|
| Agent Communication Protocol (ACP) | open-source protocol | link |
| Agent2Agent Protocol (A2A) | open-source protocol | link |
| Model Context Protocol (MCP) | open-source protocol | link |
| BeeAI | open-source framework | link |
| LangChain | vendor | link |
| CrewAI | open-source framework | link |