ACP: The Web Protocol for AI Agents

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 latest 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 speak across different frameworks and technology stacks. It’s a part of a growing ecosystem, including BeeAI (where I’m a part of the team), which has been donated to the Linux Foundation. Below are some key features; you possibly can read more in regards to the core concepts and details within 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 should you want it): ACP doesn’t require any specialized libraries. You’ll be able to interact with agents using tools like curl, Postman, and even your browser. For added convenience, there’s an SDK available.
Offline Discovery: ACP agents can embed metadata directly into their distribution packages, which enables discovery even after 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 because the default. This is right for long-running or complex tasks. Synchronous requests are also supported.

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

Why Do We Need ACP?

As the quantity of AI Agents “within the wild” increases, so does the quantity of complexity in navigating easy methods to get the very best final result from each independent technology to your use case (without having to be constrained to a selected vendor). Each framework, platform, and toolkit on the market offers unique benefits, but integrating all of them together into one agent system is difficult.

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 which might be expensive to construct.

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

Current Challenges:
Despite rapid growth in agent capabilities, real-world integration stays a significant bottleneck. With no shared communication protocol, organizations face several recurring challenges:

• Framework Diversity: Organizations typically run tons of or 1000’s of agents built using different frameworks like LangChain, CrewAI, AutoGen, or custom stacks.
• Custom Integration: Without a typical protocol, developers must write custom connectors for each 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 take care of).
• Cross-Organization Considerations: Different security models, authentication systems, and data formats complicate integration across firms.

A Real-World Example

For instance the real-world need for agent-to-agent communication, consider two organizations:

A producing company that uses an AI agent to administer production schedules and order achievement based on internal inventory and customer demand.

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

Now imagine the manufacturer’s system must estimate delivery timelines for a big, custom equipment order to tell a customer quote.

Without ACP: This could require constructing a bespoke integration between the manufacturer’s planning software and the logistics provider’s APIs. This implies handling authentication, data format mismatches, and repair 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. Each systems collaborate without exposing internals or writing custom integrations. Latest logistics partners can plug in just 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 might be done in only a number of lines of code. Using the Python SDK, you possibly 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]

#Arrange 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]:
    "An easy 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 completely ACP-compliant agent that may:

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

How ACP Compares to MCP & A2A

To raised understand ACP’s role within the evolving AI ecosystem, it helps to match it to other emerging protocols. As an alternative, they address different layers of the AI system integration stack and sometimes complement each other.

At a Glance:

• mcp (Anthropic’s Model Context Protocol): Designed for enriching a single model’s context with tools, memory, and resources.
• ACP (Linux Foundation’s Agent Communication Protocol): Designed for communication between independent agents across systems and organizations.
• A2A (Google’s Agent-to-Agent): Designed for communication between independent agents across systems and organizations.

ACP and MCP

The ACP team initially explored adapting the Model Context Protocol (MCP) since it offers a robust foundation for model-context interactions. Nonetheless, 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 however it doesn’t handle (e.g., tokens, trajectory updates). This limitation stems from the proven 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, however it’s an energetic 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 constructing 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’ll be able to read more about how ACP and MCP compare here.

Consider MCP as giving an individual higher tools, like a calculator or a reference book, to boost their performance. In contrast, ACP is about enabling people to form , where everyone (or agent) contributes their capabilities and and collaborates.

ACP and A2A

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

ACP was deliberately designed to be:

• Easy to integrate using common HTTP tools and REST conventions
• Flexible across a wide selection of agent types and workloads
• Vendor-neutral, with open governance and broad ecosystem alignment

Each protocols can coexist—each serving different needs depending on the environment. ACP’s lightweight, open, and extensible design makes it well-suited for decentralized systems and real-world interoperability across organizational boundaries. A2A’s natural integration may make it a more suitable option for those using the Google ecosystem.

Roadmap and Community

As ACP evolves, they’re exploring latest possibilities to boost agent communication. Listed below are some key areas of focus:

• Identity Federation: How can ACP work with authentication systems to enhance trust across networks?
• Access Delegation: How can we enable agents to delegate tasks securely (while maintaining user control)?
• Multi-Registry Support: Can ACP support decentralized agent discovery across different networks?
• Agent Sharing: How can we make it easier to share and reuse agents across organizations or inside a company?
• Deployments: What tools and templates can simplify agent deployment?

ACP is being developed within the open because standards work best after they’re developed directly with users. Contributions from developers, researchers, and organizations involved in the long run of agent interoperability are welcome. Take part helping to shape this evolving standard.

For more information, visit agentcommunicationprotocol.dev and join the conversation on the github and discord channels.