Agent Communication Protocols: ACP, AGNTCY & ANP

The Model Context Protocol (see protocols-mcp.html) and A2A (see protocols-a2a.html) are the two most widely adopted agent protocols, but they are not the only answers to the interoperability question. This page covers three further efforts, each built on a different core philosophy:

• ACP — a pragmatic, rest-first protocol where an agent is just an HTTP service you POST to. Originally from IBM/BeeAI; now merged into A2A.
• AGNTCY — not a single wire protocol but a collective and a stack of components for an "Internet of Agents," centered on a federated directory for discovery.
• ANP — a fully decentralized protocol that gives every agent a self-sovereign, cryptographic identity and lets them meet as peers on the open web.

The contrast is the point. ACP centralizes around a known REST endpoint; AGNTCY centralizes around a (federated) registry; ANP refuses to centralize at all. Reading them together is the fastest way to understand the design space.

ACP — the Agent Communication Protocol

ACP is "an open protocol for communication between AI agents, applications, and humans." Per IBM's own materials, it was launched by IBM Research in March 2025 to power the open-source BeeAI platform (the ACP spec site and the i-am-bee/acp repo phrase this more neutrally, as "developed by contributors to the BeeAI project" under the Linux Foundation). It was designed around a deliberately boring transport: REST over HTTP, using "simple, well-defined REST endpoints that align with standard HTTP patterns" rather than a custom RPC envelope. The design goal is that an agent is reachable with nothing more exotic than curl, Postman, or a browser — no client library required — which makes ACP-compliant agents trivial to integrate into existing production infrastructure.

Status note (read this first). On August 25, 2025, the ACP team announced it is winding down active development and "will begin contributing its technology and expertise directly to A2A" under the Linux Foundation; days later the LF AI & Data blog (August 29, 2025) confirmed the consolidation. BeeAI provides A2A adapters (its A2AServer / A2AAgent classes plus a migration guide) so existing ACP agents can move to A2A. ACP is therefore best understood today as an influential, now-consolidated design rather than a protocol to adopt for new greenfield work — but its REST/async-first model is instructive, and many of its ideas live on in A2A. Everything below describes ACP as specified before the merger.

Purpose and design principles

ACP set out to solve agent fragmentation: agents written in different frameworks (BeeAI, LangChain, CrewAI, and others) could not easily call one another. Four principles shaped the protocol:

1. REST-first transport. Communication uses standard, well-defined REST endpoints aligned with ordinary HTTP patterns rather than a custom RPC envelope. (This is the sharpest contrast with A2A and MCP, which both put json-rpc 2.0 on the wire.)
2. Async-first. ACP is built primarily for asynchronous communication so it can handle long-running agent tasks, while still fully supporting synchronous calls.
3. Multimodal by MIME type. Message content is identified by standard MIME types, so text, images, audio, video, or custom binary formats flow through the same structure without protocol changes.
4. Offline (scale-to-zero) discovery. An agent can embed its manifest metadata in its distribution package, so it remains discoverable even while inactive — useful for scale-to-zero deployments where the agent process may not be running.

REST transport and the endpoint surface

Because ACP is REST rather than a single RPC endpoint, its surface is a small set of resource routes. The core endpoints are:

Agent discovery and the manifest

A client discovers agents by calling GET /agents, which returns a list of agent descriptors. Each agent exposes a manifest (its "Agent Detail") describing "its identity, capabilities, metadata, and runtime status." The minimal descriptor carries a name, a description, and a metadata object:

{
  "agents": [
    { "name": "echo", "description": "Echoes everything", "metadata": {} }
  ]
}

Because that same metadata can be packaged with the agent's distribution artifact, discovery works both online (query a running server) and offline (read embedded manifests from a catalog), supporting the scale-to-zero case above.

Message structure: multipart and multimodal

ACP's content model is a small, multimodal structure. A Message has:

• a role identifying the sender — user, agent, or the qualified form agent/{name}; and
• a parts array: an ordered list of MessagePart objects.

Each MessagePart carries:

• content_type (required) — a MIME type such as text/plain, image/png, or application/json;
• exactly one of content (inline) or content_url (a reference) — the two are mutually exclusive;
• content_encoding (optional) — "plain" (default) or "base64" for binary payloads;
• name (optional) — naming a part promotes it to an Artifact (a first-class output such as a file or attachment); and
• metadata (optional) — contextual or semantic annotations.

Because a message is an ordered list of typed parts, a single message can interleave prose, images, and structured JSON — the "multipart" character that distinguishes ACP messages from a single text blob.

Runs: the unit of execution and its lifecycle

Invoking an agent creates a run. A run progresses through a defined set of statuses; the specification defines seven:

created → in-progress → completed, with branches to awaiting (paused for input), cancelling → cancelled, and failed.

stateDiagram-v2
    [*] --> created
    created --> in_progress: start
    in_progress --> completed: done
    in_progress --> awaiting: needs input
    awaiting --> in_progress: resume (POST /runs/{run_id})
    in_progress --> failed: error
    in_progress --> cancelling: cancel requested
    cancelling --> cancelled
    completed --> [*]
    failed --> [*]
    cancelled --> [*]

A run is created by POST /runs. The request body names the agent, supplies the input messages, and selects an execution mode:

• sync — the HTTP call blocks and returns the finished run (with its output) in the response.
• async — the call returns immediately with a run_id and an early status (e.g. created / in-progress); the client then polls GET /runs/{run_id} until the run reaches a terminal state.
• stream — the server streams incremental events as the run progresses, delivered over Server-Sent Events (SSE) over HTTP.

Annotated REST example (synchronous run)

curl -X POST http://localhost:8000/runs \
  -H "Content-Type: application/json" \
  -d '{
    "agent_name": "echo",          # which agent to invoke (from GET /agents)
    "input": [                      # an array of ACP Messages
      { "role": "user",
        "parts": [ { "content": "Hello" } ] }   # one MessagePart, inline content
    ],
    "mode": "sync"                  # block and return the finished run
  }'

{
  "agent_name": "echo",
  "status": "completed",            // terminal run status
  "output": [                       // array of Messages produced by the agent
    { "role": "agent/echo",         // qualified agent role
      "parts": [
        { "content_type": "text/plain", "content": "Hello" }
      ] }
  ],
  "await_request": null             // non-null only when status == "awaiting"
}

In async mode the same POST /runs instead returns a run_id with status created/ in-progress, and the client polls GET /runs/{run_id}.

The await / interactive pattern

ACP's most distinctive feature is interactive runs. Mid-execution, an agent can pause to request external information — a clarifying question, a credential, a human approval. The run transitions to the awaiting status and the response carries an AwaitRequest (surfaced in the await_request field) describing what is needed. The client supplies the answer with an AwaitResume payload via POST /runs/{run_id}, and the run resumes from where it stopped. This is how ACP models long, multi-turn, human-in-the-loop work without holding an HTTP connection open.

Related stateful work is grouped with a session_id: passing the same session identifier across multiple runs lets an agent "maintain state across multiple agent runs" (conversation history and context), while runs without a session are effectively stateless.

AGNTCY — the "Internet of Agents" collective

AGNTCY is not a single wire protocol; it describes itself as the collective building the Internet of Agents (IoA) — "a new collaboration layer that lets multi-agent systems work together regardless of who built them or where they run." It was initially open-sourced by Cisco in March 2025 (its incubator, Outshift, drove the work, with early collaboration from LangChain and Galileo) and was welcomed into the Linux Foundation on July 29, 2025, with Cisco, Dell Technologies, Google Cloud, Oracle, and Red Hat named as formative members. The LF press release names five building blocks: OASF, the Agent Directory (Agent Discovery), SLIM, Agent Identity, and Agent Observability.

Rather than prescribe how two agents byte-exchange, AGNTCY supplies the infrastructure an open agent ecosystem needs — discovery, identity, a secure transport, and observability — and is explicitly interoperable with A2A and MCP (it makes A2A agents and MCP servers discoverable and identity-bearing rather than replacing them). The cleanest way to read AGNTCY is as five components, each its own repo under the agntcy GitHub org, that compose into a stack.

OASF — the Open Agentic Schema Framework

OASF is AGNTCY's data model for describing an agent. Its vocabulary is precise and self-referential:

• a field is a named piece of data with a data_type;
• an object is a collection of contextually related fields (and is itself a data_type);
• a class is a named set of attributes (fields and objects) — also a data_type — that represents the metadata of a record.

At the core of OASF is the record object, the primary data structure for an agentic application. Classes are grouped into three families — Skills, Domains, and Modules — and a record is annotated with skills and domains (drawn from a versioned taxonomy of capabilities) to drive announcement and discovery, while modules extend a record with additional information in a modular, composable way. Records also carry locators (where to reach the agent) among their key attributes. Because OASF is schema-driven, the AGNTCY tooling (e.g. the Directory MCP server) can import from MCP/A2A formats — wrapping an A2A Agent Card or an MCP server — and export to others, so an OASF record is a superset descriptor rather than a rival manifest format. The live schema (Skills/Domains/Modules taxonomies) is browsable at the OASF schema server.

Agent Directory (dir) — discovery over a content-addressed, federated store

The Agent Directory Service (ADS) is the discovery layer, and its design is the philosophical heart of AGNTCY: a registry of registries, not one central catalog. Concretely:

• Records are the units stored, each an OASF record describing one agent. A record is content-addressed: it is stored and retrieved by its CID (Content Identifier).
• The Store is a content-addressable layer backed by an OCI registry (the reference implementation uses Zot), reusing OCI/ORAS plumbing rather than a bespoke database.
• A Distributed Hash Table (DHT) maps agent attributes — skills, domains, modules, and locators — to record identifiers, so the skill taxonomy itself is routable: a query for a skillset resolves to the records (and the peer servers hosting them) that announce it.
• A content-routing protocol ties independent Agent Directory servers together, letting distributed instances federate into a shared, searchable inventory (Outshift also runs a hosted public directory).

The CLI (dirctl) exposes the lifecycle directly: you push a record into the local store, pull it back by CID, publish (announce) it so other peers can find it, then list records held locally on a peer versus search across the network via cached announcements. Records can be cryptographically signed and verified for trust. The directory exposes gRPC APIs and protobuf schemas (published at buf.build/agntcy/dir).

SLIM — the secure messaging transport

SLIM (Secure Low-Latency Interactive Messaging) is AGNTCY's transport layer: it defines how messages are securely delivered, leaving what they say to protocols like A2A and MCP (for which SLIM is explicitly positioned as the transport). Its concrete shape:

• it is built on gRPC over HTTP/2 and HTTP/3, and extends plain gRPC beyond request/reply to add publish/subscribe, streaming, fire-and-forget, and group/channel communication;
• end-to-end encryption uses MLS (Message Layer Security) at a dedicated session layer — so that even TLS connection termination along the path does not break confidentiality;
• SLIMRPC / SRPC carries protobuf RPC over SLIM (analogous to gRPC-over-HTTP/2);
• the deployment splits a data plane (the slim message-routing nodes) from a control plane (the SLIM Controller, which configures nodes and monitors the network).

Identity — verifiable credentials and Agent Badges

AGNTCY Identity onboards and verifies identities for Agents, MCP Servers, and Multi-Agent Systems (MASs) under one model with three stated properties: Open (no central authority required), Collision-free (a universally unique identifier per entity), and Verifiable (each entity is backed by a Verifiable Credential). It is deliberately bring-your-own-identity — an entity can be identified by an IdP account (Okta, Entra ID, Auth0, Google), by an A2A /.well-known/agent.json Agent Card, or by a W3C DID — and that identifier is then bound to one or more Verifiable Credentials (VCs). The headline primitive is the Agent Badge: an enveloped VC captured as a JSON-LD object that asserts a specific definition of an agent under a given schema (an OASF definition or an A2A Agent Card schema), so one agent may hold several badges for nuanced, least-privilege access.

Observability — OTel-native telemetry for multi-agent systems

AGNTCY Observability ships an Observe SDK and an observability data schema that is an extension of OpenTelemetry (OTel), following the GenAI semantic conventions. It captures the three OTel signal types — Metrics, Traces, and Events — enriched with MAS-specific measures (e.g. agent-collaboration success rate, task-delegation accuracy), so multi-agent runs are inspectable across frameworks without re-instrumentation.

Philosophy and status

AGNTCY's bet is that the missing piece is discovery, identity, and trust at enterprise scale, not the message format — so it standardizes the directory, schema, identity, and transport (OASF + dir + Identity + SLIM + Observability) and stays deliberately neutral about whether the agents then talk A2A, MCP, or something else. It is an active, multi-repo Linux Foundation project under continuing development.

ANP — the Agent Network Protocol

ANP (Agent Network Protocol) takes the opposite stance from a central endpoint or registry: it aims to be "the HTTP of the Agentic Web era," a decentralized, peer-to-peer standard in which agents meet as equals on the open internet with no required intermediary. It is developed and maintained by the open-source community, which "pledges never to commercialize," and its standardization is being pursued through the W3C AI Agent Protocol Community Group. Where AGNTCY centralizes discovery in a (federated) directory, ANP pushes identity and discovery to the edge and relies on the web itself.

Three-layer architecture

ANP is structured as three layers, bottom-up:

1. Identity & encrypted communication layer. Every agent has a self-sovereign, cryptographic identity based on the W3C did (Decentralized Identifier) standard, specifically the did:wba ("Web-Based Agent") method. did:wba builds on did:web: it requires no blockchain and resolves over ordinary HTTPS. An identifier looks like did:wba:example.com or did:wba:example.com:user:alice; resolution converts the method-specific colons to slashes, prepends https://, and fetches the DID document at /.well-known/did.json (e.g. did:wba:example.com → https://example.com/.well-known/did.json). Authentication is single-request: the client puts its DID and a signature in the first HTTP request via an Authorization: DIDWba … header carrying did, nonce, timestamp, verification_method, and signature (a signature over the canonicalized nonce + timestamp + service domain + DID); the server verifies against the public key in the DID document and typically returns a short-lived JWT for follow-up calls. End-to-end encryption is negotiated via ECDHE, and high-risk operations can require a separate humanAuthorization check — all without a central authority.
2. Meta-protocol layer. Agents negotiate how they will communicate in natural language, then use AI code generation to produce, jointly debug, and deploy the agreed protocol — letting two agents that never pre-shared an interface still establish one dynamically, and caching negotiated protocols for reuse. This is ANP's most distinctive idea: the wire contract is emergent, not pre-standardized.
3. Application protocol layer. Built on semantic-web technologies (json-ld, schema.org, RDF), this layer holds the Agent Description Protocol (ADP) and an Agent Discovery mechanism. An Agent Description is a JSON-LD document whose required fields include protocolType ("ANP"), protocolVersion, type ("AgentDescription"), name, securityDefinitions, and security, with optional did, owner, description, url, created, interfaces, and a proof. A securityDefinition names the scheme — e.g. {"scheme": "didwba", "in": "header", "name": "Authorization"} referenced as didwba_sc. interfaces come in two shapes: a NaturalLanguageInterface (conversational, often YAML-described) and a StructuredInterface over protocols like OpenRPC, MCP, WebRTC, or YAML/OpenAPI, with an optional humanAuthorization: true on sensitive operations. The proof object (e.g. type: "EcdsaSecp256r1Signature2019", with proofPurpose, verificationMethod, challenge, and proofValue, using JCS JSON Canonicalization + SHA-256) makes the description tamper-evident.

Annotated Agent Description (abridged)

{
  "protocolType": "ANP",                 // fixed discriminator
  "protocolVersion": "1.0.0",
  "type": "AgentDescription",
  "name": "Grand Hotel Assistant",
  "did": "did:wba:grand-hotel.com:service:hotel-assistant",   // self-sovereign id
  "url": "https://grand-hotel.com/agents/assistant/ad.json",  // where this doc lives
  "securityDefinitions": {
    "didwba_sc": { "scheme": "didwba", "in": "header", "name": "Authorization" }
  },
  "security": "didwba_sc",               // callers authenticate with a signed DIDWba header
  "interfaces": [
    { "type": "StructuredInterface", "protocol": "MCP",        // reuse an MCP server, or…
      "url": "https://grand-hotel.com/agents/assistant/mcp" },
    { "type": "NaturalLanguageInterface",                      // …just talk to it
      "url": "https://grand-hotel.com/agents/assistant/nl" }
  ],
  "proof": {                             // tamper-evidence over the canonicalized doc
    "type": "EcdsaSecp256r1Signature2019",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:wba:grand-hotel.com:service:hotel-assistant#keys-1",
    "proofValue": "<base64url-signature>"
  }
}

Note how a single description can advertise both an MCP StructuredInterface and a free-form NaturalLanguageInterface — ANP catalogues other protocols rather than replacing them.

Discovery and philosophy

ANP's Agent Discovery Protocol follows RFC 8615: a domain publishes a JSON-LD document at the well-known URI /.well-known/agent-descriptions that lists the URLs of all its public agent descriptions (typed as a CollectionPage, paginated via a next property), so any peer — or a search engine — can crawl a domain knowing nothing but its name (active discovery); agents may also register their description URLs with a search-service agent (passive discovery). No central registry is required. The philosophy is full decentralization: identity is self-sovereign (DID), discovery is host-local (well-known URIs), and trust is cryptographic rather than mediated by a platform — which is why the community positions ANP as a neutral, non-commercial public good rather than a vendor standard.

Three philosophies, side by side

The three differ less in features than in where each puts the center of gravity — the one thing it refuses to let move. ACP centralizes on a known REST endpoint: an agent is an HTTP service and the contract is the URL. AGNTCY centralizes on a federated registry: the schema (OASF) and the content-addressed, DHT-routed Agent Directory are the fixed point, and the wire protocol between agents is left open (A2A, MCP, or SLIM). ANP refuses to centralize at all: identity is self-sovereign (did:wba), discovery is host-local (well-known URIs), and even the protocol itself is negotiated per-pair at the meta-protocol layer. Read as a spectrum, they run from "trust the endpoint" (ACP) through "trust the registry" (AGNTCY) to "trust only the cryptography" (ANP):

flowchart TB
    subgraph ACP["ACP — centralized REST endpoint"]
        A1[Client] -->|"POST /runs"| A2[Agent HTTP service]
    end
    subgraph AGNTCY["AGNTCY — federated directory / registry"]
        G1[Agent] -->|publish OASF record| G2[(Directory dir / DHT)]
        G3[Client] -->|discover| G2
        G2 -. federates .- G4[(Peer directory)]
    end
    subgraph ANP["ANP — decentralized DID, no intermediary"]
        N1[Agent A
did:wba] <-->|"fetch /.well-known
+ signed requests"| N2[Agent B
did:wba]
    end

For how these compare against MCP and A2A overall, see protocols-comparison.html.

Key takeaways

• ACP treated an agent as a plain REST service — GET /agents to discover, POST /runs to invoke — with async-first runs, a seven-state run lifecycle (created, in-progress, awaiting, cancelling, cancelled, failed, completed), MIME-typed multipart messages, and an awaiting/AwaitRequest pattern for human-in-the-loop work. It has since merged into A2A.
• AGNTCY standardizes infrastructure — a five-component stack: the OASF schema (record/field/object/class, with Skills/Domains/Modules families), a federated Agent Directory of CID-addressed records routed by skill over a DHT (OCI/Zot-backed, dirctl push/pull/publish/list/search), the SLIM transport (gRPC/HTTP-2 with MLS end-to-end encryption), Identity (VCs and JSON-LD Agent Badges), and OTel-based Observability — rather than a single message format, and is explicitly interoperable with A2A and MCP. It joined the Linux Foundation on July 29, 2025.
• ANP pushes everything to the edge: self-sovereign DID identity (did:wba, resolved at /.well-known/did.json, authenticated by a signed DIDWba header), a meta-protocol layer that negotiates the wire contract in natural language, JSON-LD Agent Descriptions, and host-local well-known discovery (/.well-known/agent-descriptions) — cryptographically signed peer-to-peer exchange with no central registry.