ACP: AI Agents Need a Common Language

From isolated AI assistants to interoperable agent systems, with practical examples in software development, banking, and distributed systems.

What happens when your AI agents are good at their jobs but terrible at working together?

Your backend agent is written in Python. Your frontend agent runs on TypeScript. Your testing agent uses a different framework, and your incident analysis agent lives in another service.

Individually, everything works. But the moment you try to connect them, you start writing adapters, translating payloads, handling different execution models, and maintaining a growing collection of custom integrations.

I've been thinking about this problem while exploring multi-agent development workflows. The interesting challenge isn't just getting an agent to complete a task. It's making independently developed agents collaborate without coupling the entire system to one framework or runtime.

That's where Agent Communication Protocol (ACP) becomes interesting.

In this article, we'll explore the original IBM/BeeAI ACP approach, walk through practical examples, compare ACP with MCP and A2A, and discuss what these protocols mean when you're building a real multi-agent system.

One important note before we begin: ACP can refer to different projects. This article focuses on the original IBM/BeeAI Agent Communication Protocol, whose development has since converged with the A2A ecosystem.

TL;DR

• ACP was designed to standardize communication between independently implemented AI agents.
• MCP focuses on how AI applications connect to tools, resources, and external capabilities.
• A2A provides a standardized approach to communication and task delegation between agents.
• These protocols address different integration boundaries and can complement one another.
• A protocol doesn't replace orchestration, security, observability, or reliable error handling.
• For new implementations, check the current A2A specification and official ACP migration guidance before choosing a protocol or SDK.

1. The problem isn't building agents. It's connecting them.

Building a single AI agent is becoming relatively straightforward. Frameworks provide model integrations, tool calling, memory, planning, and workflow execution.

The harder problem appears when you want multiple agents to collaborate.

Consider three independently developed agents:

• A research agent that uses Python.
• A reporting agent that runs on Node.js.
• A visualization agent that uses a separate service.

Each agent might work perfectly on its own. However, they may expose completely different interfaces.

One expects:

{
  "query": "Analyze monthly revenue"
}

Another expects:

{
  "task_type": "report",
  "parameters": {
    "metric": "revenue",
    "period": "monthly"
  }
}

And the third might require a CSV file uploaded to a particular endpoint.

Now the orchestrator needs to understand all three interfaces, translate requests, handle errors, and interpret the results.

Add five more agents, and the integration layer becomes another software product you have to maintain.

This is the actual problem: agents can be intelligent individually but still be incompatible as a system.

A communication protocol aims to standardize the interaction layer without requiring every agent to use the same internal implementation.

2. What exactly is ACP?

The Agent Communication Protocol developed by IBM Research and the BeeAI ecosystem is an open protocol intended to make AI agents interoperable.

The core idea is simple:

An agent should be able to communicate through a predictable interface without requiring the caller to understand its internal implementation.

For example, the caller shouldn't need to know whether the receiving agent uses Python or TypeScript, LangGraph or a custom execution engine, a cloud-hosted LLM or a locally deployed model.

The caller needs to understand the agent's capabilities, how to send a request, and how to interpret the response.

Illustration: An orchestrator coordinates specialized agents through a communication layer. Source: CogitX — Multi-Agent AI Systems Architecture Guide.

Conceptually, the architecture looks like this:

                  User Request
                       |
                       v
                Orchestrator Agent
                       |
              Standardized Interface
                       |
           +-----------+-----------+
           |           |           |
           v           v           v
      Research      Coding      Testing
       Agent        Agent        Agent
       Python      TypeScript    Python
           |           |           |
           v           v           v
       Research      Code        Test
        Result      Changes      Report
           |           |           |
           +-----------+-----------+
                       |
                       v
                 Final Response

The agents remain independent. The communication layer provides a common way for them to exchange requests and results.

This distinction matters. ACP is a communication protocol, not a magic system that automatically makes agents intelligent, coordinates every decision, or guarantees correct results.

You still need application logic to decide which agent should do what, when to invoke it, and what to do if something goes wrong.

3. A practical example: building a feature with multiple agents

Let's use a realistic software development scenario.

A developer enters this request:

Add a virtual card creation screen, implement the corresponding backend endpoint, and write tests for the new flow.

The orchestrator breaks the request into tasks.

Step 1: The planner identifies the work

{
  "task": "Implement virtual card creation",
  "subtasks": [
    "Inspect the existing card creation flow",
    "Implement the backend endpoint",
    "Build the mobile screen",
    "Write integration tests",
    "Review security and validation"
  ]
}

This is an illustrative application-level task description, not a prescribed ACP wire format.

Step 2: The orchestrator delegates to specialized agents

The backend agent receives the API task. The frontend agent receives the screen requirements. The testing agent receives the expected behavior and acceptance criteria.

Each agent can use its own framework and tools.

Step 3: Agents return structured results

For example, the backend agent might produce:

{
  "status": "completed",
  "summary": "Implemented virtual card creation endpoint",
  "artifacts": [
    "VirtualCardController.cs",
    "CreateVirtualCardRequest.cs",
    "VirtualCardService.cs"
  ],
  "tests": {
    "passed": 12,
    "failed": 0
  }
}

The frontend agent could return a similar result containing its changed files, UI behavior, and test status.

Step 4: The orchestrator combines the results

It checks dependencies, determines whether the frontend can integrate with the endpoint, and sends any failures back to the relevant agent.

The testing agent might discover that the backend accepts a missing cardholder identifier. The orchestrator can route that finding back to the backend agent for correction.

The important point is that the agents don't have to share the same runtime or implementation framework to participate in the same workflow.

4. What happens when an agent needs another agent?

Suppose a customer support agent receives this request:

My virtual card was created successfully, but I can't see it in the mobile application.

The support agent doesn't necessarily have the expertise or permissions to diagnose the entire issue.

It may need help from several specialized agents:

1. A card-service agent checks whether the virtual card exists.
2. An API diagnostics agent investigates the backend response.
3. A mobile diagnostics agent checks the card-list rendering flow.
4. A reporting agent combines the findings.

An illustrative interaction might look like this:

Support Agent
     |
     | Diagnose missing virtual card
     v
Orchestrator
     |
     +----> Card Agent
     |          |
     |          +----> Card exists
     |
     +----> API Agent
     |          |
     |          +----> Response is successful
     |
     +----> Mobile Agent
                |
                +----> Card list uses stale cached data

     |
     v
Orchestrator combines evidence
     |
     v
Support Agent returns diagnosis

Notice that the agents don't need access to one another's private prompts, internal reasoning, or entire memory stores.

They need a well-defined way to exchange the information required for the task.

Collaboration doesn't have to mean sharing everything.

In a real implementation, the orchestrator would also need to validate permissions, ensure that sensitive customer information is handled appropriately, and distinguish confirmed findings from hypotheses.

5. ACP's design: why HTTP matters

One of the notable characteristics of the IBM/BeeAI ACP design is its HTTP-native, REST-oriented approach.

That is useful because most production systems already understand HTTP.

You can inspect requests, test endpoints, apply standard networking infrastructure, and integrate with existing authentication and observability systems.

The original protocol supports synchronous and asynchronous interactions, streaming through Server-Sent Events (SSE), and messages containing different kinds of content.

Let's look at what these concepts mean for developers.

Synchronous communication

A caller sends a request and waits for the result.

Client
  |
  | Request
  v
Classification Agent
  |
  | Result
  v
Client

An illustrative request might be:

{
  "task": "classify_support_ticket",
  "input": {
    "message": "My card payment was declined"
  }
}

The corresponding application-level response could be:

{
  "category": "card_payment",
  "confidence": 0.94
}

These JSON objects illustrate the task and result; they are not intended to define ACP's exact wire schema.

Asynchronous communication

Now imagine asking an agent to analyze a repository containing hundreds of projects.

That job might take several minutes. Keeping an HTTP request open for the entire execution may be inconvenient or unreliable.

Instead, the caller can initiate a task, receive an identifier, and check its progress later.

Orchestrator
     |
     | Start repository analysis
     v
Analysis Agent
     |
     | Return task identifier
     v
Orchestrator
     |
     | Continue other work
     |
     | Check status later
     v
Analysis Agent
     |
     | Completed result
     v
Orchestrator

An illustrative task record could be:

{
  "task_id": "repo-analysis-42",
  "status": "running",
  "progress": {
    "completed": 3,
    "total": 8
  }
}

Later, the agent might return:

{
  "task_id": "repo-analysis-42",
  "status": "completed",
  "result": {
    "services_analyzed": 128,
    "dependencies_found": 46,
    "issues_identified": 7
  }
}

These are conceptual application-level examples rather than canonical ACP payloads.

The architectural benefit is that the caller doesn't need to block while the agent performs a long-running task.

Streaming communication

Sometimes waiting for the complete response isn't ideal either.

Imagine a code review agent analyzing a large merge request. The user wants to see findings as they become available.

A streaming interaction can expose progress and incremental output:

Review started
    |
    +--> Inspecting changed files
    |
    +--> Checking dependency changes
    |
    +--> Found a possible authorization issue
    |
    +--> Reviewing test coverage
    |
    +--> Final report available

This is useful for developer tools, interactive assistants, monitoring dashboards, and long-running research workflows.

The exact streaming events and payloads depend on the protocol implementation and the application's contract.

6. Agent discovery: how do you know which agent to call?

Suppose your organization has 50 agents.

Some analyze logs, some review code, others investigate payment failures, and a few generate reports.

Hardcoding every agent into the orchestrator creates a maintenance problem. Every time a new agent is added, the orchestrator may need another integration.

Discovery addresses a related problem: identifying available agents and understanding their declared capabilities.

Imagine an agent description like this:

{
  "name": "log-analysis-agent",
  "description": "Analyzes application logs and identifies likely causes of failures",
  "capabilities": [
    "error_correlation",
    "request_trace_analysis",
    "failure_summary"
  ],
  "input_types": [
    "text/plain",
    "application/json"
  ],
  "output_types": [
    "application/json"
  ]
}

This is an illustrative agent manifest, not an exact ACP specification.

The orchestrator can use this metadata to determine that the log analysis agent is a candidate for a request involving an HTTP 500 error.

For example:

Find the likely reason why virtual card creation failed for a specific request.

The orchestrator identifies the task as log analysis, selects an agent that advertises the relevant capability, and delegates the work.

A different request, such as generating a chart from the findings, could be routed to a visualization agent.

Discovery becomes particularly valuable when agents are developed by different teams or deployed independently.

One important limitation: declared capabilities are not proof that an agent can solve a task correctly. A production system still needs validation, access control, health monitoring, and fallback behavior.

7. A real-world example: investigating a failed payment

Let's move from the development team to a banking environment.

A payment request failed. The user wants to know why.

Several systems may be involved:

• The mobile application.
• A backend-for-frontend (BFF).
• The payment service.
• An authorization service.
• An external payment provider.
• Centralized logs and tracing.

A traditional diagnostic script might follow a fixed sequence of API calls. An agent-based system can instead delegate specialized investigations and combine their evidence.

                    Incident Request
                           |
                           v
                    Triage Agent
                           |
             +-------------+-------------+
             |             |             |
             v             v             v
         Log Agent      API Agent     Payment Agent
             |             |             |
             v             v             v
        HTTP 500       Request DTO    Provider timeout
             |             |             |
             +-------------+-------------+
                           |
                           v
                     Evidence Review
                           |
                           v
                     Final Diagnosis

The log agent might find a correlated error. The API agent could confirm that the request reached the correct endpoint. The payment agent might identify a timeout from the external provider.

An example of a structured finding:

{
  "finding": "Payment provider timeout",
  "evidence": [
    {
      "source": "payment-service",
      "observation": "Provider request exceeded the configured timeout"
    },
    {
      "source": "application-logs",
      "observation": "The payment request returned HTTP 500"
    }
  ],
  "confidence": "medium",
  "recommended_next_step": "Check provider availability and retry policy"
}

This example deliberately separates evidence from the recommendation.

The agent should not claim that the provider caused the failure merely because it found an HTTP 500. The evidence must support that conclusion.

This is where a robust agent architecture goes beyond connecting endpoints: it needs traceability, structured results, and a way to distinguish observed facts from inferred explanations.

ACP can help standardize agent communication. It does not, by itself, guarantee accurate diagnoses or provide the entire incident orchestration system.

8. ACP vs. MCP vs. A2A: what is the difference?

These names are easy to confuse because they all appear in discussions about agentic AI.

The easiest way to understand them is to ask what kind of interaction you're trying to standardize.

MCP: connecting an AI application to tools and data

The Model Context Protocol (MCP) provides a standard way for AI applications to access tools, resources, and prompts exposed by MCP servers.

For example, a coding assistant might use MCP to access GitLab merge requests, an Elasticsearch query tool, a database schema, a filesystem, or an internal API.

AI Assistant
     |
     | Call search_logs tool
     v
MCP Server
     |
     v
Elasticsearch
     |
     v
Search Results

The main question is: How does the AI application access an external capability through a standard interface?

ACP: standardizing communication between agents

The IBM/BeeAI ACP design focuses on enabling agents implemented in different environments to exchange messages through a common interface.

For example, a support agent can request a diagnosis from a specialized incident agent without needing to know how that agent performs its internal analysis.

The main question is: How can independently developed agents communicate with one another?

A2A: interoperable agent-to-agent communication

Google introduced the Agent2Agent (A2A) protocol to enable agents to discover and collaborate with one another across different platforms.

It provides a standardized way to describe agent capabilities and interact with remote agents, including task-oriented workflows.

The main question is: How can agents built by different teams and organizations work together through a common protocol?

Illustration: MCP and A2A address different communication boundaries. Source: Jimmy Song — Agentic Design Patterns, Inter-Agent Communication.

Here's a simplified comparison:

This is a conceptual comparison, not a complete feature-by-feature specification.

The important distinction is that MCP and agent-to-agent protocols address different interaction boundaries. They are not necessarily competing alternatives.

How they can work together

Consider an incident investigation assistant.

The orchestrator delegates a task to a remote diagnostic agent through an agent-to-agent interface. The diagnostic agent then uses MCP to query internal logs and access approved tools.

User
 |
 v
Incident Orchestrator
 |
 | Agent-to-agent request
 v
Diagnostic Agent
 |
 | MCP tool call
 v
Log Search Server
 |
 v
Elasticsearch
 |
 v
Diagnostic Agent
 |
 | Structured result
 v
Incident Orchestrator
 |
 v
User

This is a useful architectural pattern because each protocol serves a different purpose.

The agent-to-agent layer handles collaboration. The tool-access layer handles access to external capabilities.

You don't need to expose the diagnostic agent's internal tool implementation to every agent that requests its help.

9. What does agent-to-agent communication look like?

A useful way to understand A2A is to look at how one agent can discover and delegate work to another.

For example, a research agent might need a separate data analysis agent to process a spreadsheet.

The client first discovers the remote agent's declared capabilities, then sends a task using the protocol's defined interaction model.

Illustration: An A2A interaction using JSON-RPC over HTTP, with optional SSE streaming and task states. Source: Peter Rosemann — A Developer's Deep-Dive into Google's A2A Protocol.

Conceptually, the workflow looks like this:

Research Agent
      |
      | Discover available capabilities
      v
Remote Agent Description
      |
      | Select suitable agent
      v
Data Analysis Agent
      |
      | Execute task
      v
Structured Result
      |
      v
Research Agent

The key idea is that the calling agent does not need to know the internal implementation of the remote agent.

A2A defines the communication contract; the remote agent remains responsible for executing its task.

For exact message fields, task states, and discovery behavior, consult the official A2A documentation.

10. An important update: ACP and A2A are converging

There is a detail worth understanding before choosing a protocol for a new project.

The original IBM/BeeAI Agent Communication Protocol should not be treated as an entirely separate, equally active standard alongside A2A without qualification.

IBM Research's ACP project page states that ACP is now part of A2A under the Linux Foundation and directs developers toward migration guidance.

That changes how I would approach a new implementation.

If you're building a new multi-agent system today, I would:

1. Understand the original ACP design because it provides useful architectural lessons about interoperability and lightweight agent communication.
2. Review the current A2A specification and official migration documentation before selecting an implementation.
3. Avoid committing to an older ACP-specific SDK or endpoint contract without checking its current maintenance status.
4. Keep the application-level task model independent of the transport protocol where practical, making future migrations easier.

Why does this matter?

Protocols evolve. A system that tightly couples business logic to a particular communication SDK can become difficult to migrate when standards and ecosystems change.

A clean separation between business logic, agent capabilities, and transport adapters can reduce that risk.

This is not an argument against learning ACP. Understanding why it was designed helps explain the problems that agent interoperability standards are trying to solve.

11. What ACP does not solve

It's tempting to think that adopting a common protocol makes a multi-agent system interoperable, secure, and reliable automatically.

It doesn't.

A protocol can standardize communication, but several engineering problems remain.

Authentication and authorization

An agent that can investigate a payment incident should not automatically be able to initiate a payment or access every customer's data.

You still need identity, permissions, scoped credentials, and policy enforcement.

Reliable execution

What happens when an agent times out after starting a task? Can the caller retry safely? Could the operation run twice?

These questions require deliberate handling of timeouts, retries, idempotency, and task state.

Semantic compatibility

Two agents may both accept JSON and still disagree about what a field means.

For example, one agent might interpret amount as a value in major currency units while another expects minor units.

A common transport format doesn't eliminate the need for clear schemas and domain contracts.

Observability

When a workflow spans six agents, you need to know which agent ran, what task it received, how long it took, and where a failure occurred.

Correlation IDs, distributed tracing, structured logs, and audit events are still essential.

Trust and untrusted output

An agent's response is not automatically correct or safe. It could contain a mistaken diagnosis, malformed data, or instructions that should not be trusted.

Validate results before using them in sensitive operations.

For enterprise systems, these concerns are not optional details. They're part of the architecture.

12. How I would design a multi-agent system today

If I were building an agent platform from scratch, I would separate it into four layers.

+------------------------------------------------+
|                  User Interface                |
|              Chat / Dashboard / API             |
+------------------------------------------------+
                        |
                        v
+------------------------------------------------+
|              Orchestration Layer               |
| Planning | Routing | Dependencies | Policies    |
+------------------------------------------------+
                        |
                        v
+------------------------------------------------+
|                Agent Layer                     |
|                                                |
| Research | Backend | Frontend | Test | Review  |
+------------------------------------------------+
                        |
                        v
+------------------------------------------------+
|             Integration Layer                  |
| Agent Protocol | MCP | Internal REST APIs       |
+------------------------------------------------+
                        |
                        v
+------------------------------------------------+
|           Enterprise Infrastructure            |
| GitLab | Logs | Databases | Services | CI/CD    |
+------------------------------------------------+

Each layer has a different responsibility.

• The UI shows the task, execution progress, results, and approvals.
• The orchestrator plans the workflow, selects agents, manages dependencies, and decides when human input is required.
• The agents perform specialized work and return structured results.
• The integration layer connects agents to one another and to external capabilities.
• The infrastructure contains the actual business systems and data.

For example, a testing agent might discover that a backend task has completed and begin integration testing. If the tests fail, the orchestrator can send the failure report back to the backend agent.

The protocol helps the agents exchange information. The orchestrator determines what happens next.

That distinction is worth keeping clear when designing a system with multiple autonomous components.

13. The bigger idea: agents should be replaceable components

One of the strongest arguments for agent interoperability is that you shouldn't have to rebuild your entire system every time you replace one agent.

Suppose your original code review agent uses one framework and model provider.

Six months later, you find a better implementation that is faster, cheaper, or more accurate.

If the rest of the system depends on the agent's private APIs, memory format, and internal execution model, replacing it can be expensive.

If the agent exposes a stable, well-defined interface, the replacement becomes much more manageable.

The same principle applies to organizations.

A logistics provider could expose an agent that estimates delivery times. A retailer could use that capability without needing to understand the provider's internal algorithms or infrastructure.

The integration still needs appropriate authentication, contracts, and compatibility checks. But the architectural goal is clear: make the interaction contract stable while allowing implementations to evolve.

That's a familiar idea in software engineering. We already rely on interfaces, service contracts, and abstractions to decouple systems.

Agent communication protocols apply similar principles to a world in which the services being connected can reason, delegate tasks, and produce dynamic outputs.

Conclusion

The next challenge in agentic AI isn't simply creating agents that can perform increasingly complex tasks.

It's creating systems in which independently developed agents can collaborate reliably.

ACP was an important step toward that goal. Its emphasis on lightweight, HTTP-native communication, asynchronous execution, and interoperability offers useful lessons for anyone building multi-agent systems.

MCP and agent-to-agent protocols address different parts of the integration problem, and they can complement one another within the same architecture.

At the same time, the evolution of these standards matters. IBM Research now directs developers toward A2A for the continued evolution of the original ACP work.

For developers, I think the most useful takeaway is this:

Don't build a multi-agent system around the assumption that every agent will always use the same framework, model, or runtime. Build around clear capabilities and stable communication contracts instead.

The more independently your agents can evolve, the easier it becomes to experiment, replace components, and scale the system without rewriting everything around them.

And that is what makes agent interoperability an engineering problem worth paying attention to.

References and further reading

1. IBM Think — What is Agent Communication Protocol (ACP)?
2. IBM Research — Agent Communication Protocol
3. ACP to A2A Migration Guide

Note: The arXiv paper proposes a separate research approach also called ACP. It should be read as a research proposal, not as the official specification of the original IBM/BeeAI protocol. The JSON examples in this article are illustrative application-level payloads, not canonical ACP or A2A wire formats.