ACP: The Internet Protocol for AI Agents

With ACP (Agent Communication Protocol), AI agents can collaborate freely across teams, frameworks, technologies, and organizations. It’s a universal protocol that transforms the fragmented landscape of today’s AI Agents into inter-connected team mates. This unlocks new levels of interoperability, reuse, and scale.

As an open-source standard with open governance, ACP has just released its latest version, allowing AI agents to communicate across different frameworks and technology stacks. It’s part of a growing ecosystem, including BeeAI (where I’m part of the team), which has been donated to the Linux Foundation. Below are some key features; you can read more about the core concepts and details in the documentation.

Key features of ACP:
REST-based Communication: ACP uses standard HTTP patterns for communication, which makes it easy to integrate into production. Whereas JSON-RPC relies on more complex methods.
No SDK Required (but there’s one if you want it): ACP doesn’t require any specialized libraries. You can interact with agents using tools like curl, Postman, or even your browser. For added convenience, there is an SDK available.
Offline Discovery: ACP agents can embed metadata directly into their distribution packages, which enables discovery even when they’re inactive. This supports secure, air-gapped, or scale-to-zero environments where traditional service discovery isn’t possible.
Async-first, Sync Supported: ACP is designed with asynchronous communication as the default. This is ideal for long-running or complex tasks. Synchronous requests are also supported.

Note: ACP enables orchestration for any agent architecture pattern, but it doesn’t manage workflows, deployments, or coordination between agents. Instead, it enables orchestration across diverse agents by standardizing how they communicate. IBM Research built BeeAI, an open source system designed to handle agent orchestration, deployment, and sharing (using ACP as the communication layer).

Why Do We Need ACP?

As the amount of AI Agents “in the wild” increases, so does the amount of complexity in navigating how to get the best outcome from each independent technology for your use case (without having to be constrained to a particular vendor). Each framework, platform, and toolkit out there offers unique advantages, but integrating them all together into one agent system is challenging.

Today, most agent systems operate in silos. They’re built on incompatible frameworks, expose custom APIs, and lack a shared protocol for communication. Connecting them requires fragile and non repeatable integrations that are expensive to build.

ACP represents a fundamental shift: from a fragmented, ad hoc ecosystem to an interconnected network of agents—each able to discover, understand, and collaborate with others, regardless of who built them or what stack they run on. With ACP, developers can harness the collective intelligence of diverse agents to build more powerful workflows than a single system can achieve alone.

Current Challenges:
Despite rapid growth in agent capabilities, real-world integration remains a major bottleneck. Without a shared communication protocol, organizations face several recurring challenges:

• Framework Diversity: Organizations typically run hundreds or thousands of agents built using different frameworks like LangChain, CrewAI, AutoGen, or custom stacks.
• Custom Integration: Without a standard protocol, developers must write custom connectors for every agent interaction.
• Exponential Development: With n agents, you potentially need n(n-1)/2 different integration points (which makes large-scale agent ecosystems difficult to maintain).
• Cross-Organization Considerations: Different security models, authentication systems, and data formats complicate integration across companies.

A Real-World Example

To illustrate the real-world need for agent-to-agent communication, consider two organizations:

A manufacturing company that uses an AI agent to manage production schedules and order fulfillment based on internal inventory and customer demand.

A logistics provider that runs an agent to offer real-time shipping estimates, carrier availability, and route optimization.

Now imagine the manufacturer’s system needs to estimate delivery timelines for a large, custom equipment order to inform a customer quote.

Without ACP: This would require building a bespoke integration between the manufacturer’s planning software and the logistics provider’s APIs. This means handling authentication, data format mismatches, and service availability manually. These integrations are expensive, brittle, and hard to scale as more partners join.

With ACP: Each organization wraps its agent with an ACP interface. The manufacturing agent sends order and destination details to the logistics agent, which responds with real-time shipping options and ETAs. Both systems collaborate without exposing internals or writing custom integrations. New logistics partners can plug in simply by implementing ACP.

How Easy is it to Create an ACP-Compatible Agent?

Simplicity is a core design principle of ACP. Wrapping an agent with ACP can be done in just a few lines of code. Using the Python SDK, you can define an ACP-compliant agent by simply decorating a function.

This minimal implementation:

1. Creates an ACP server instance
2. Defines an agent function using the @server.agent() decorator
3. Implements an agent using the LangChain framework with an LLM backend and memory for context persistence
4. Translates between ACP’s message format and the framework’s native format to return a structured response
5. Starts the server, making the agent available via HTTP

from typing import Annotated
import os
from typing_extensions import TypedDict
from dotenv import load_dotenv
#ACP SDK
from acp_sdk.models import Message
from acp_sdk.models.models import MessagePart
from acp_sdk.server import RunYield, RunYieldResume, Server
from collections.abc import AsyncGenerator
#Langchain SDK
from langgraph.graph.message import add_messages
from langchain_anthropic import ChatAnthropic 

load_dotenv() 

class State(TypedDict):
    messages: Annotated[list, add_messages]

#Set up the llm
llm = ChatAnthropic(model="claude-3-5-sonnet-latest", api_key=os.environ.get("ANTHROPIC_API_KEY"))

#------ACP Requirement-------#
#START SERVER
server = Server()
#WRAP AGENT IN DECORACTOR
@server.agent()
async def chatbot(messages: list[Message])-> AsyncGenerator[RunYield, RunYieldResume]:
    "A simple chatbot enabled with memory"
    #formats ACP Message format to be compatible with what langchain expects
    query = " ".join(
        part.content
        for m in messages
        for part in m.parts             
    )
    #invokes llm
    llm_response = llm.invoke(query)    
    #formats langchain response to ACP compatable output
    assistant_message = Message(parts=[MessagePart(content=llm_response.content)])
    # Yield so add_messages merges it into state
    yield {"messages": [assistant_message]}  

server.run()
#---------------------------#

Now, you’ve created a fully ACP-compliant agent that can:

• Be discovered by other agents (online or offline)
• Process requests synchronously or asynchronously
• Communicate using standard message formats
• Integrate with any other ACP-compatible system

How ACP Compares to MCP & A2A

To better understand ACP’s role in the evolving AI ecosystem, it helps to compare it to other emerging protocols. These protocols aren’t necessarily competitors. Instead, they address different layers of the AI system integration stack and often complement one another.

At a Glance:

• mcp (Anthropic’s Model Context Protocol): Designed for enriching a single model’s context with tools, memory, and resources.
  Focus: one model, many tools
• ACP (Linux Foundation’s Agent Communication Protocol): Designed for communication between independent agents across systems and organizations.
  Focus: many agents, securely working as peers, no vendor lock in, open governance
• A2A (Google’s Agent-to-Agent): Designed for communication between independent agents across systems and organizations.
  Focus: many agents, working as peers, optimized for Google’s ecosystem

ACP and MCP

The ACP team initially explored adapting the Model Context Protocol (MCP) because it offers a strong foundation for model-context interactions. However, they quickly encountered architectural limitations that made it unsuitable for true agent-to-agent communication.

Why MCP Falls Short for Multi-Agent Systems:

Streaming: MCP supports streaming but it doesn’t handle delta streams (e.g., tokens, trajectory updates). This limitation stems from the fact that when MCP was originally created it wasn’t intended for agent-style interactions.

Memory Sharing: MCP doesn’t support running multiple agents across servers while maintaining shared memory. ACP doesn’t fully support this yet either, but it’s an active area of development.

Message Structure: MCP accepts any JSON schema but doesn’t define structure for the message body. This flexibility makes interoperability difficult (especially for building UIs or orchestrating agents that must interpret diverse message formats).

Protocol Complexity: MCP uses JSON-RPC and requires specific SDKs and runtimes. Where as ACP’s REST-based design with built-in async/sync support is more lightweight and integration-friendly.

You can read more about how ACP and MCP compare here.

Think of MCP as giving a person better tools, like a calculator or a reference book, to enhance their performance. In contrast, ACP is about enabling people to form teams, where each person (or agent) contributes their capabilities and and collaborates.

ACP and MCP can complement each other:

	MCP	ACP
Scope	Single model + tools	Multiple agents collaborating
Focus	Context enrichment	Agent communication and orchestration
Interactions	Model Tools	Agent Agent
Examples	Send a database query to a model	Coordinate a research agent and a coding agent

ACP and A2A

Google’s Agent-to-Agent Protocol (A2A), which was introduced shortly after ACP, also aims to standardize communication between AI agents. Both protocols share the goal of enabling multi-agent systems, but they diverge in philosophy and governance.

Key differences: