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

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

1497 words

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

AspectMCPACP
FocusModel-to-toolsAgent-to-agent
TransportJSON-RPCREST/HTTP
StateStatelessWith sessions
DiscoveryManualAutomatic
InteractivityLimitedBuilt-in

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.

Comments

Latest Posts

9 min

1747 words

If you’re using tools like Claude Code, GitHub Copilot Workspace, or similar, you’ve probably noticed there’s technical jargon that goes beyond simply “chatting with AI”. I’m talking about terms like rules, commands, skills, MCP, and hooks.

These concepts are the architecture that makes AI agents truly useful for software development. They’re not just fancy marketing words — each one serves a specific function in how the agent works.

Let’s break them down one by one in a clear way.

6 min

1097 words

Two protocols, two philosophies

In recent months, two protocols have emerged that will change how we build AI systems: Agent2Agent Protocol (A2A) from Google and Model Context Protocol (MCP) from Anthropic. But here’s the thing: they don’t compete with each other.

In fact, after analyzing both for weeks, I’ve realized that understanding the difference between A2A and MCP is crucial for anyone building AI systems beyond simple chatbots.

The key lies in one question: Are you connecting an AI with tools, or are you coordinating multiple intelligences?

7 min

1438 words

A few days ago I discovered Agent Lightning, a Microsoft project that I believe marks a before and after in how we think about AI agent orchestration. It’s not just another library; it’s a serious attempt to standardize how we build multi-agent systems.

What is Agent Lightning?

Agent Lightning is a Microsoft framework for orchestrating AI agents. It enables composition, integration, and deployment of multi-agent systems in a modular and scalable way. The premise is simple but powerful: agents should be components that can be combined, connected, and reused.

3 min

609 words

Recently, Addy Osmani published an article that gave me much to think about: “Self-Improving Coding Agents”. The idea is simple but powerful: agents that not only execute tasks, but improve their own performance over time.

This isn’t science fiction. It’s happening now, in 2026. And it has profound implications for the future of software development and, by extension, for all professions.

What is a Self-Improving Agent?

A self-improving agent is an AI system with the capacity to:

2 min

315 words

Lately I’ve been closely following everything around the MCP protocol (Model Context Protocol), and recently I found a project that makes a lot of sense: MCPHero.

The reality is that although MCP is taking off, many “traditional” AI libraries like openai or google-genai still don’t have native MCP support. They only support tool/function calls. MCPHero comes to solve exactly this: make a bridge between MCP servers and these libraries.

What is MCPHero?

MCPHero is a Python library that lets you use MCP servers as tools/functions in native AI libraries. Basically, it lets you connect to any MCP server and use its tools as if they were native OpenAI or Google Gemini tools.

4 min

810 words

A few days ago I came across a very interesting stream where someone showed their setup for agentic programming using Claude Code. After years developing “the old-fashioned way,” I have to admit that I’ve found this revealing.

What is Agentic Programming?

For those not familiar with the term, agentic programming is basically letting an AI agent (in this case Claude) write code for you. But I’m not talking about asking it to generate a snippet, but giving it full access to your system so it can read, write, execute, and debug code autonomously.