// PROTOCOL_EXPLAINER
ACP
Agent Communication Protocol
REST-native protocol for agent-to-agent communication built on OpenAPI standards.
The Agent Communication Protocol (ACP) is an open standard developed by Cisco and BeeAI that takes a REST-first approach to agent interoperability. Where MCP uses JSON-RPC and A2A extends it with Agent Cards, ACP treats each agent as a standard REST API endpoint with an OpenAPI specification. This makes ACP the most web-native of the three protocols — any agent that can serve HTTP can be ACP-compatible, and existing API tooling (gateways, load balancers, monitoring) works out of the box.
// FIGURE_01 — ACP architecture overview: Cisco / BeeAI · 2025 · HTTP REST (standard web requests), OpenAPI 3.x for capability description, Webhooks or polling for async results
01What is the Agent Communication Protocol?
ACP is an open protocol that enables agent-to-agent communication using familiar web standards. Instead of inventing a new message format, ACP leverages REST, HTTP, JSON, and OpenAPI — the same technologies that power the modern web API ecosystem. Each ACP-compatible agent exposes a REST endpoint described by an OpenAPI specification. Other agents (or any HTTP client) can discover capabilities by reading the spec and invoke the agent by making standard HTTP requests. This design choice makes ACP immediately accessible to the millions of developers who already build REST APIs.
02How ACP Works: Agents as REST Endpoints
In ACP, every agent is a REST API. The agent's OpenAPI spec describes its endpoints — typically including an invoke endpoint for sending tasks, a status endpoint for checking progress, and a results endpoint for retrieving artifacts. Communication is stateless HTTP: the client sends a request, the agent responds. For long-running tasks, ACP supports asynchronous patterns via polling or webhooks, following the same conventions used by web APIs like Stripe or Twilio. There's no special client library required — any HTTP client in any language can talk to an ACP agent.
03Async Messaging and Webhooks
ACP handles long-running agent tasks the same way modern web APIs do. When a client sends a task that will take time, the agent returns a 202 Accepted response with a task ID. The client can then poll the status endpoint or register a webhook URL to receive a callback when the task completes. This is the same pattern used by Stripe (payment processing), Twilio (SMS delivery), and AWS (long-running operations). It means ACP agents integrate naturally with existing async infrastructure — message queues, serverless functions, and webhook processors all work without modification.
04ACP vs MCP vs A2A
The three protocols occupy different positions. MCP is agent-to-tool — it connects agents to data sources and functions. A2A is agent-to-agent with a custom discovery and messaging layer built on JSON-RPC. ACP is also agent-to-agent but uses standard REST and OpenAPI, making it more accessible to web developers. ACP's advantage is familiarity: if you know how to build a REST API, you know how to build an ACP agent. A2A's advantage is richer semantics: Agent Cards and task lifecycle management provide more structure for complex multi-agent workflows. MCP's advantage is its focus on the context layer — it's the only one that solves agent-to-tool connectivity.
05When to Choose ACP
ACP is the right choice when you want agent interoperability without adopting a new messaging paradigm. If your team already builds REST APIs and uses OpenAPI specs, ACP requires zero new mental models. It's also strong in enterprise environments where existing API gateways, service meshes, and monitoring tools need to work with agent communication. Choose A2A instead if you need rich agent discovery, task lifecycle management, and streaming. Choose MCP for connecting agents to tools and data. The protocols are not mutually exclusive — an agent can be ACP-compatible for inter-agent communication and MCP-compatible for tool access.
// KEY_CONCEPTS
Core Concepts
Agent Endpoint
A REST API endpoint that represents an ACP-compatible agent. Described by an OpenAPI specification.
OpenAPI Spec
The standard API description format that declares an agent's endpoints, request/response schemas, and capabilities.
Invoke
The HTTP request that sends a task to an agent. Returns 202 Accepted for async tasks or 200 with results for sync.
Async Polling
Pattern for long-running tasks: client polls a status endpoint until the task completes, then fetches results.
Webhook Callback
Alternative to polling: the client registers a URL, and the agent sends an HTTP POST when the task completes.
Stateless HTTP
ACP communication is standard stateless HTTP — no persistent connections or session state required.
// ARCHITECTURE
How It Works
Agent API
Each agent is a REST API with an OpenAPI spec. Endpoints for invoke, status, and results.
OpenAPI Discovery
Clients read the agent's OpenAPI spec to understand capabilities and request formats.
HTTP Request
Client sends a task via HTTP POST to the agent's invoke endpoint. Standard REST — no special libraries.
Async Response
Agent returns 202 with a task ID. Client polls or receives webhook callback when done.
// TRANSPORT_LAYERS
- HTTP REST (standard web requests)
- OpenAPI 3.x for capability description
- Webhooks or polling for async results
// USE_CASES
When to Use ACP
Enterprise agent integration — works with existing API gateways and service meshes
Web-native agent communication — any HTTP client in any language can participate
REST-first organizations — teams that already build OpenAPI-spec'd services adopt ACP with zero friction
Serverless agents — ACP agents deploy as serverless functions with HTTP triggers
API marketplace integration — agents listed in API catalogs alongside traditional APIs
// SUPPORTED_AGENTS
Agents Using ACP
// PROTOCOL_COMPARISON
ACP vs Other Protocols
| Aspect | MCP | A2A | ACPCURRENT |
|---|---|---|---|
| Primary purpose | Agent-to-tool/data | Agent-to-agent collaboration | Agent-to-agent via REST |
| Developer familiarity | New protocol (JSON-RPC) | New protocol (JSON-RPC + Agent Cards) | Standard REST + OpenAPI |
| Discovery | Server connection handshake | Agent Card JSON at well-known URL | OpenAPI spec at agent endpoint |
| Async support | SSE streaming | SSE streaming | Polling + webhooks (web standard) |
| Learning curve | Moderate — new concepts (Resources, Tools, Roots) | Moderate — Agent Cards, Task lifecycle | Low — if you know REST, you know ACP |
| Best for | Agent-to-tool connections | Rich multi-agent orchestration | Web-native, REST-first agent communication |
// FAQ
Frequently Asked Questions
// WRITTEN_BY
Laurent Yew
Founder
Laurent Yew is the founder of AgentResourceDB, where he leads the platform's vision of building a unified, trust-first discovery layer for the AI agent ecosystem. With over a decade of experience scaling AI and SaaS products, Laurent has dedicated his career to making complex developer infrastructure accessible, transparent, and reliable. He writes about agent registries, protocol interoperability, and the future of agent-to-agent collaboration, drawing from hands-on work building evaluation frameworks that help developers cut through the noise of 100,000+ agents. Through AgentResourceDB, he is committed to establishing the trust standards the industry needs as AI agents move from experimentation to production.
// EXPLORE_MORE
Discover Agents by Category
Browse ACP-compatible agents across 15 categories — from coding and research to security and DevOps.
BROWSE_CATEGORIES