Agent Communication Protocol (ACP): The HTTP of AI Agents

Yet another protocol promising to change everything

When IBM Research announced the Agent Communication Protocol (ACP) as part of the BeeAI project, my first reaction was the usual one: “Oh, just another universal protocol”. With nearly 30 years in this field, I’ve seen too many “definitive standards” that ended up forgotten.

But there’s something different about ACP that made me pay attention: it doesn’t promise to solve all the world’s problems. It simply focuses on one very specific thing: making AI agents from different frameworks talk to each other. And it does it in a way that really makes sense.

The real problem ACP tries to solve

Imagine you have an agent built with LangChain that needs to cooperate with another made in CrewAI, and both need to coordinate with a third one developed internally. Now multiply that by N frameworks and M teams.

The result is what we see today: islands of agents that cannot communicate. Each framework invents its own way of doing things, its own message format, its own way of handling state.

// The current reality: each framework with its own hassle
const langchainAgent = new LangChainAgent(config);
const crewAIAgent = new CrewAIAgent(setup);
const customAgent = new CustomFrameworkAgent(params);

// How do you connect them? With unique glue code for each pair
// langchain -> crewai: custom integration #1
// langchain -> custom: custom integration #2
// crewai -> custom: custom integration #3
// And so on...

ACP proposes something different: a standard RESTful protocol that any agent can implement. It doesn’t matter if it’s made in Python, TypeScript, Go, or whatever.

Why ACP can succeed where others failed

1. It’s based on known standards

They didn’t reinvent the wheel. ACP is REST over HTTP, using standard MIME types to identify content. Nothing revolutionary, but it works:

# Example ACP message
POST /agents/translator/run
Content-Type: application/json

{
  "messages": [
    {
      "role": "user",
      "content": "Translate this to Spanish",
      "mimeType": "text/plain"
    }
  ]
}

2. Async-first design, but with sync support

Agents can take minutes or hours to complete tasks. ACP is designed for this:

# Example with Python SDK
from acp_sdk.server import Server

server = Server()

@server.agent()
async def research_agent(input: list[Message], context: Context):
    # Can take hours to complete
    yield {"status": "started", "message": "Starting research..."}
    result = await deep_research(input)
    yield {"status": "completed", "result": result}

3. Multimodal from the ground up

It’s not limited to text. Images, audio, video, documents… any MIME type works:

{
  "content": "data:image/png;base64,iVBORw0KGgo...",
  "mimeType": "image/png"
}

4. Decentralized architecture

There’s no central server. Each agent exposes its own ACP API. Agents discover each other using embedded metadata:

# Agent manifest
name: "translator-agent"
description: "Translates text between languages"
capabilities:
  - translation
  - text-processing
endpoints:
  - url: "http://localhost:8080/acp"

What I really like about ACP

Operational simplicity

Each agent is an independent process. No complex orchestration systems. If an agent goes down, it doesn’t affect the others.

Docker and Kubernetes compatibility

# Dockerfile for ACP agent
FROM python:3.11-slim
COPY . /app
WORKDIR /app
RUN pip install acp-sdk
EXPOSE 8080
CMD ["python", "agent.py"]

Deploy like any other service. Nothing special to learn.

Built-in observability

ACP includes hooks for OpenTelemetry. Traces, metrics, logs… everything integrated from minute one.

Interactivity

Agents can pause to request additional information from the client:

# The agent can ask things during execution
yield RequestInput({
    "prompt": "What format do you prefer for the report?",
    "options": ["PDF", "HTML", "Markdown"]
})

# Wait for user response
user_choice = yield WaitForInput()

BeeAI: The reference implementation

IBM didn’t just publish a spec. BeeAI is a complete platform that implements ACP:

# Installation on macOS
brew install i-am-bee/beeai/beeai

# Quick setup
beeai env setup  # configure providers (Ollama, OpenAI, etc.)

# List available agents
beeai list

# Run an agent
beeai run chat "How's the weather?"

And importantly: web interface included at localhost:8333 for debugging, logs, traces.

Real use cases I’ve seen

1. Financial analysis pipeline

• Scraper agent: Extracts financial data from multiple sources
• Analysis agent: Processes data and generates insights
• Reports agent: Creates automatic presentations

Each in its own framework, but communicating via ACP.

2. Security system

• Logs agent: Processes CrowdStrike logs
• Threat intel agent: Enriches suspicious indicators
• Mitigation agent: Creates Jira tickets or triggers Terraform

All orchestrated without a central orchestrator.

3. Academic research

• Crawler agent: Extracts papers from arXiv
• Indexer agent: Builds vector indices
• Research agent: Generates summaries and analysis

Each researcher can develop their agent using their preferred stack.

What worries me (because there’s always a catch)

1. Is it really necessary?

With REST APIs working well, do we need another protocol? IBM’s argument is that ACP adds:

• Standard metadata for discovery
• Stateful sessions
• Built-in interactivity
• Multimodal communication

Valid, but is it enough to justify the additional complexity?

2. Ecosystem fragmentation

We already have Anthropic’s MCP, Google’s A2A, and now IBM’s ACP. Aren’t we creating more fragmentation?

IBM’s answer is interesting: ACP can encapsulate MCP. An ACP agent can use MCP tools internally.

3. Security

Agents talking to each other, accessing enterprise data, executing code… what could go wrong?

ACP includes “capability tokens” - cryptographic tokens that limit what each agent can do. But security in multi-agent systems is complex.

4. Performance

HTTP + JSON for everything. What happens when you need to transfer GBs of data between agents?

ACP allows streaming, but still… REST isn’t the most efficient protocol for everything.

Why ACP can succeed

Linux Foundation + Open governance

It’s not a corporate project. It’s under the Linux Foundation with transparent governance. That reduces vendor lock-in risk.

Growing ecosystem

There are already reference agents for common cases:

• RAG with LlamaIndex
• Code analysis
• Document processing
• Database integration

Focus on developers

It’s not a platform for end-users. It’s a tool for developers building multi-agent systems.

Timing

2025 is the year when multi-agent systems start becoming mainstream. ACP arrives at the right moment.

My practical experience

I’ve set up a test setup with three agents:

1. Monitor agent (Python + FastAPI)
2. Analyzer agent (Node.js + Express)
3. Reporter agent (Go + Gin)

The configuration was surprisingly simple:

# Agent 1: Monitor
@server.agent()
async def monitor_system():
    metrics = collect_metrics()
    # Send data to analyzer
    response = await acp_client.run_agent(
        "analyzer",
        messages=[{"content": json.dumps(metrics)}]
    )
    return response

// Agent 2: Analyzer
app.post('/agents/analyzer/run', async (req, res) => {
  const { messages } = req.body;
  const analysis = await analyzeMetrics(messages[0].content);

  // Send to reporter
  await acpClient.runAgent('reporter', [{
    content: JSON.stringify(analysis)
  }]);

  res.json({ status: 'completed' });
});

It worked on the first try. Each agent in its preferred technology, communicating seamlessly.

Key differences with MCP

They don’t directly compete. MCP connects models with tools. ACP connects agents with each other. They can be used together.

My recommendation (spoiler: experiment)

If you’re building multi-agent systems:

For small projects:

Maybe ACP is overkill. Direct HTTP might be enough.

For enterprise systems:

ACP brings real value. Automatic discovery, observability, interactivity… worth the additional overhead.

For distributed teams:

ACP will shine when different teams develop agents using their preferred stacks.

How to get started

1. Install BeeAI

# macOS
brew install i-am-bee/beeai/beeai

# Linux
curl -sSL https://install.beeai.dev | bash

# Windows (WSL)
curl -sSL https://install.beeai.dev | bash

2. Configure a provider

beeai env setup
# Choose Ollama for local, OpenAI for cloud

3. Try an existing agent

beeai run chat "Explain ACP in one sentence"

4. Create your first agent

# agent.py
from acp_sdk.server import Server
from acp_sdk.models import Message

server = Server()

@server.agent()
async def hello_agent(input: list[Message], context):
    name = input[0].content if input else "world"
    return f"Hello {name}!"

if __name__ == "__main__":
    server.run()

python agent.py &
beeai run hello "Antonio"

The bigger picture

ACP is not just a technical protocol. It’s a bet on interoperability at a time when AI is fragmenting.

If we look back, the protocols that succeeded were those that:

1. Solved real problems (HTTP, TCP/IP)
2. Were adopted by multiple vendors (not proprietary)
3. Arrived at the right time (neither too early nor too late)

ACP meets all three requirements. But time will tell if that’s enough.

Conclusion: Cautious optimism

As someone who has seen many “universal standards” fail, I maintain healthy skepticism. But ACP has elements that give me confidence:

• Open governance under Linux Foundation
• Working reference implementation (BeeAI)
• Clear and specific use cases
• Solid technical design based on proven standards

It won’t solve all AI problems. But it can solve the specific problem of agent-to-agent communication. And sometimes, that’s enough.

My advice: experiment with ACP in small projects. See if it fits your stack. If you’re building multi-agent systems, it might be exactly what you need.

What do you think? Do you believe ACP has a future, or is it just another protocol destined to be forgotten? Have you already experimented with multi-agent systems?

My intuition says that 2025 will be the year where we see if ACP takes off or stays in limbo. Meanwhile, it’s worth being prepared.

PS: If you decide to try it, start with BeeAI. Installation is surprisingly simple, and the examples really work.