Post

Agent Communication Protocol (ACP)

IBM's open protocol for agent-to-agent communication -- a REST-native, developer-friendly standard for discovering, invoking, and orchestrating AI agents across frameworks.

Posted
By
9 min read
Agent Communication Protocol (ACP)

IBM’s open protocol for agent-to-agent communication – a REST-native, developer-friendly standard for discovering, invoking, and orchestrating AI agents across frameworks. Originally the protocol behind IBM’s BeeAI platform, ACP merged into A2A under the Linux Foundation in August 2025.

What is ACP?

ACP is a RESTful, HTTP-based protocol that standardizes how AI agents discover each other, exchange messages, and manage task lifecycles. IBM Research launched it in March 2025 alongside the open-source BeeAI platform (the i-am-bee project on GitHub). Within weeks, IBM donated both ACP and BeeAI to the Linux Foundation’s LF AI & Data umbrella, signaling that this was meant as a community standard rather than an IBM proprietary play.

The protocol defined itself through an OpenAPI specification – meaning you could interact with any ACP-compliant agent using cURL, Postman, or any HTTP client. No specialized SDKs required, no custom wire format to learn. This was the core design bet: agent communication should be as straightforward as calling a REST API.

The Problem ACP Solved

By early 2025, the agent interoperability space had a familiar pattern: every framework built its own communication layer. LangGraph agents couldn’t talk to CrewAI agents, which couldn’t talk to Amazon Bedrock agents. MCP solved the agent-to-tool problem, but agent-to-agent remained fragmented.

ACP’s thesis was that agent-to-agent communication shouldn’t require learning a new RPC protocol or buying into a specific vendor’s ecosystem. If your team already knows REST – and every backend team does – you should be able to wire agents together using the same patterns you use for microservices.

Specific pain points ACP addressed:

  • No standard discovery mechanism – how does Agent A find Agent B and learn what it can do?
  • No standard invocation pattern – synchronous? async? streaming? Every framework had different answers
  • No standard message format – each framework had its own schema for passing text, images, structured data between agents
  • No lifecycle management – no agreed-upon way to track whether a task was running, waiting, completed, or failed

Architecture

ACP’s architecture is built around three core resources: Agents, Threads, and Runs.

Agents – Discovery and Metadata

Every ACP-compliant agent publishes metadata at a well-known URI using YAML files. This works even when the agent is offline – a registry or orchestrator can read the metadata, understand the agent’s capabilities, and decide whether to wake it up. This is conceptually similar to A2A’s Agent Cards but uses standard YAML/OpenAPI conventions rather than a custom JSON schema.

Threads – Stateful Conversations

Threads provide optional statefulness. A thread represents an ongoing conversation between a client and an agent, accumulating context across multiple interactions. This is critical for agents that need multi-turn reasoning – a compliance agent that asks clarifying questions, or a research agent that refines its approach based on feedback.

Runs – Task Execution

A Run represents a single execution of an agent within a thread (or statelessly). Runs have a defined lifecycle:

1
2
3
4

CREATED --> RUNNING --> COMPLETED
                   --> FAILED
                   --> AWAITING (input needed)
                   --> CANCELLED

The AWAITING state is where ACP gets interesting – an agent can pause execution, request additional input from the client, and resume once it receives it. This enables genuine back-and-forth collaboration rather than fire-and-forget.

Communication Modes

ACP supports three communication patterns through standard HTTP:

Mode Mechanism Use Case
Synchronous HTTP POST, block until response Simple, fast tasks (classification, lookup)
Asynchronous POST returns run ID, poll for status Long-running tasks (research, analysis)
Streaming Server-Sent Events (SSE) Progressive output (RAG chains, report generation)

How It Works

Discovering and Running an Agent

Using the ACP Python SDK:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

import asyncio
from acp_sdk.client import Client
from acp_sdk.models import Message, MessagePart

async def main():
    async with Client(base_url="http://localhost:8000") as client:
        # Discover available agents
        agents = await client.agents()
        for agent in agents:
            print(f"{agent.name}: {agent.description}")

        # Run an agent synchronously
        run = await client.run_sync(
            agent="compliance-checker",
            input=[Message(parts=[
                MessagePart(content="Check this data pipeline for GDPR compliance"),
                MessagePart(
                    content_type="application/json",
                    content='{"pipeline": "user-analytics-v2", "data_sources": ["clickstream", "purchase_history"]}'
                )
            ])]
        )
        print(run.output)

if __name__ == "__main__":
    asyncio.run(main())

Or with plain cURL – no SDK needed:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# List available agents
curl http://localhost:8000/agents

# Run an agent synchronously
curl -X POST http://localhost:8000/runs/stateless \
  -H "Content-Type: application/json" \
  -d '{
    "agent_name": "compliance-checker",
    "input": [{
      "parts": [{
        "content_type": "text/plain",
        "content": "Check this pipeline for GDPR compliance"
      }]
    }]
  }'

Message Structure

ACP messages use a multimodal part-based structure. Each message is an ordered list of parts with explicit MIME type annotations:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
  "role": "agent/research-analyst",
  "parts": [
    {
      "content_type": "text/plain",
      "content": "Analysis complete. Key findings attached."
    },
    {
      "content_type": "application/pdf",
      "content_url": "https://storage.example.com/reports/analysis-2025-q2.pdf"
    },
    {
      "content_type": "application/json",
      "content": "{\"risk_score\": 0.73, \"category\": \"medium\"}"
    }
  ]
}

Each part can carry either inline content or a content_url reference (never both). This keeps small payloads efficient while allowing large artifacts (images, PDFs, datasets) to be passed by reference.

Async Execution with Await

The await pattern enables interactive agent collaboration:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

async def run_with_interaction():
    async with Client(base_url="http://localhost:8000") as client:
        # Start an async run
        run = await client.run_async(
            agent="procurement-agent",
            input=[Message(parts=[MessagePart(content="Find best vendor for GPU cluster")])]
        )

        # Agent may pause and ask for input
        while run.status == "awaiting":
            print(f"Agent asks: {run.output}")
            user_input = input("> ")
            run = await client.resume(
                run_id=run.id,
                input=[Message(parts=[MessagePart(content=user_input)])]
            )

        print(f"Final result: {run.output}")

Key Concepts

REST-Native Design

ACP’s defining characteristic was that it treated agent communication as a REST resource problem. Agents, threads, and runs are resources with standard CRUD operations. No custom wire protocol, no JSON-RPC, no gRPC. This made ACP immediately accessible to any team that has built a REST API – which is essentially every backend team.

OpenAPI-First Specification

The entire protocol is defined as an OpenAPI specification (openapi.yaml). This means automatic client generation in any language, automatic documentation, and compatibility with API gateways, rate limiters, and observability tools that already understand OpenAPI.

Observability via OpenTelemetry

ACP implementations incorporate OpenTelemetry (OTLP) instrumentation out of the box. Agent interactions produce traces and metrics that flow into existing observability stacks (Datadog, Grafana, Jaeger). For enterprise deployments, this is table stakes – you need to see what your agents are doing.

Multimodal by Default

Unlike protocols that bolt on multimodality as an afterthought, ACP’s message structure was multimodal from day one. Every message part carries an explicit MIME type, making it natural to pass images, audio, structured data, and text in the same conversation.

Aspect ACP (IBM) A2A (Google) MCP (Anthropic)
Wire format REST / HTTP JSON-RPC 2.0 JSON-RPC 2.0
Primary scope Agent-to-agent Agent-to-agent Agent-to-tool
Discovery YAML at well-known URI Agent Card at /.well-known/agent.json Server capabilities handshake
Task lifecycle Runs with CREATED/RUNNING/AWAITING/COMPLETED Tasks with submitted/working/input-required/completed Stateless tool calls
Streaming SSE SSE SSE
Spec format OpenAPI Custom JSON-RPC spec Custom JSON-RPC spec
Developer onramp Low (cURL/Postman work) Medium (need JSON-RPC client) Medium (need MCP SDK)
Enterprise features Basic (auth, observability) Rich (Agent Cards, push notifications, auth schemes) Focused on tool integration

ACP vs A2A – The Core Tension

ACP and A2A attacked the same problem from different angles:

  • ACP was developer-first: REST conventions, OpenAPI spec, works with cURL. Optimized for teams that want to wire agents together quickly without learning a new protocol.
  • A2A was enterprise-first: JSON-RPC, rich Agent Cards with skills/tags/auth declarations, push notifications for fire-and-forget workflows. Optimized for large organizations with complex discovery and governance needs.

Neither was wrong. ACP traded some enterprise sophistication for developer velocity. A2A traded some developer simplicity for enterprise completeness. The merger attempted to combine both strengths.

The Merger into A2A (August 2025)

In August 2025, IBM announced that ACP would officially merge into the A2A protocol under the Linux Foundation’s LF AI & Data umbrella. The announcement came from Kate Blair, Director of Incubation for IBM Research: “By bringing the assets and expertise behind ACP into A2A, we can build a single, more powerful standard for how AI agents communicate and collaborate.”

Why It Happened

The pragmatic reality: two competing open standards for agent-to-agent communication would fragment the ecosystem. Both were under the Linux Foundation. Both had overlapping goals. The industry needed one standard, not two.

What ACP Contributed to A2A

The merger was not a capitulation – ACP’s DNA shaped the combined protocol:

  • REST patterns and developer ergonomics – A2A absorbed ACP’s emphasis on making the protocol accessible to teams that think in REST. The combined spec improved its HTTP-native patterns.
  • Multimodal message structure – ACP’s MIME-typed part-based messages influenced A2A’s content handling.
  • Stateful conversation model – ACP’s thread concept (persistent multi-turn context) complemented A2A’s task lifecycle.
  • OpenTelemetry observability – ACP’s built-in OTLP instrumentation became a recommended practice in the merged standard.
  • BeeAI reference implementation – The BeeAI platform transitioned to A2A, providing a working reference for the merged protocol. BeeAI agents use A2AServer adapters, and external A2A agents integrate via A2AAgent wrappers.

What This Means for Developers

  • If you built on ACP, IBM provided migration paths and documentation for moving to A2A
  • The ACP GitHub repository (i-am-bee/acp) is no longer actively maintained
  • ACP’s OpenAPI-style developer experience influenced but did not fully replace A2A’s JSON-RPC foundation
  • BeeAI continues as a platform but now speaks A2A natively

Current Adoption and Maturity

Status: Merged / No longer independently maintained.

ACP had a short but meaningful life (March-August 2025). Its contributions:

  • Validated that REST-native agent communication is viable and developer-friendly
  • Provided the BeeAI reference implementation that demonstrated real multi-agent orchestration
  • Forced A2A to improve its developer experience and accessibility
  • Contributed IBM’s expertise in enterprise agent architectures to the combined standard

The DeepLearning.AI short course on ACP (still available as of early 2026) remains useful for understanding agent communication concepts, even though the protocol itself has merged.

For anyone evaluating agent protocols today: ACP is historical context. The relevant standard is A2A, which carries ACP’s best ideas forward.

References

AI & Agents, Protocols
agent-patterns
This post is licensed under CC BY 4.0 by the author.