ACP (Agent Communication Protocol) and ANP (Agent Network Protocol) are the two AI agent protocols most teams encounter after MCP and A2A. ACP is a REST-based, multi-framework standard developed under the Linux Foundation through the IBM-led BeeAI project; ANP is a decentralized open-source protocol that uses W3C Decentralized Identifiers (DIDs) and JSON-LD messages for trustless cross-organization communication. This guide defines each acronym on first use, covers their architectures with example payloads, ends with a decision matrix mapping project types to protocol fit, and shows where Vaikora applies a single enforcement layer across both.
What Is ACP (Agent Communication Protocol)?
ACP, the Agent Communication Protocol, is a REST-based, multi-framework standard for orchestrating heterogeneous AI agent runtimes through a single ingress point. ACP is governed by the Linux Foundation through the IBM-led BeeAI project. The core design idea is that an enterprise running multiple agent frameworks — LangChain, AutoGen, CrewAI, and custom stacks — should not have to expose each framework directly. Instead, all traffic enters through a router-agent that inspects the requested capability and forwards the task to the appropriate downstream agent over plain HTTP REST.
ACP Architecture: The Router-Agent Topology
ACP defines a router-agent topology. A central router receives a request, inspects the requested capability, and forwards the task to the appropriate downstream agent over plain HTTP REST. Because the transport is ordinary REST/HTTPS, ACP composes naturally with existing API gateways, identity providers (OAuth, OIDC), observability stacks, and rate limiters.
Example ACP REST Call
A canonical ACP REST request to the router-agent looks like the snippet below. The router inspects the capability field and routes to the registered downstream agent that advertises that capability.
POST https://router.acme.com/acp/v1/tasks
Authorization: Bearer eyJhbGciOi…
Content-Type: application/json
{
“capability”: “document.summarize”,
“input”: {
“document_id”: “doc_55831”,
“target_length”: “short”
},
“context”: {
“tenant_id”: “acme-prod”,
“correlation_id”: “req_a8c4…”
}
}
The router-agent resolves “document.summarize” against its capability registry and forwards the request to whichever framework-specific agent is registered for that capability — LangChain today, perhaps a CrewAI agent next quarter, with no change to the calling client.
What Is ANP (Agent Network Protocol)?
ANP, the Agent Network Protocol, is a decentralized, open-source protocol for trustless agent-to-agent communication across organizational boundaries. ANP is governed as an open-source community project. It is built around three layers: an identity layer using W3C Decentralized Identifiers (DIDs), a transport layer using JSON-LD messages over HTTPS, and a protocol-negotiation layer that lets two agents dynamically agree on the message schema they will speak.
ANP Three-Layer DID-Based Mesh
Because ANP is decentralized, there is no central registry, no central broker, and no single trust authority. Agents prove identity cryptographically through DID documents, which removes the need to share API keys or rely on a third-party identity provider. This makes ANP a strong fit for cross-company workflows where neither side wants to depend on a third-party broker.
| ANP layer | Purpose |
|---|---|
|
Identity layer |
W3C Decentralized Identifiers (DIDs) — agents prove identity cryptographically through DID documents; no central registry |
|
Transport layer |
JSON-LD messages over HTTPS — semantic, self-describing payloads that any compliant agent can parse |
|
Protocol-negotiation layer |
Dynamic schema agreement — two agents exchange capability descriptions and negotiate the message shape they will use for the conversation |
Example ANP JSON-LD Message
An ANP message is JSON-LD: each field carries an explicit semantic type so a receiving agent can interpret it without a shared, hard-coded schema. The example below is a capability request from one agent to another, identified entirely by DID.
{
“@context”: [
“https://www.w3.org/ns/did/v1”,
“https://schema.agentnetworkprotocol.com/v1”
],
“@type”: “agent:CapabilityRequest”,
“id”: “urn:uuid:9b0a5c1a-7e0b-4f9a-9c5f-1a3b2d4e6f80”,
“from”: “did:web:agents.acme.com:billing”,
“to”: “did:web:agents.partner.com:invoicing”,
“capability”: “invoice.lookup”,
“params”: {
“invoice_number”: “INV-2026-04-118”,
“period”: “2026-04”
},
“proof”: {
“@type”: “DataIntegrityProof”,
“verification_method”: “did:web:agents.acme.com:billing#key-1”,
“created”: “2026-04-30T14:08:11Z”,
“signature”: “z3FXn…P8Q”
}
}
ACP vs ANP — How They Differ
ACP and ANP solve adjacent but distinct problems. ACP is about giving an enterprise one ingress for many agent frameworks. ANP is about removing the central trust authority entirely so agents can talk across companies without sharing infrastructure.
| Dimension | ACP | ANP |
|---|---|---|
|
Full name |
Agent Communication Protocol |
Agent Network Protocol |
|
Governance |
Linux Foundation / IBM-BeeAI |
Open-source community |
|
Topology |
Router-agent + downstream agents |
Decentralized three-layer DID + JSON-LD mesh |
|
Transport |
REST / HTTPS |
JSON-LD over HTTPS |
|
Identity |
API key / OAuth at the router |
W3C DIDs (cryptographic, decentralized) |
|
Discovery |
Router capability registry |
DID resolution; protocol negotiation |
|
Best for |
Enterprise multi-framework orchestration |
Open agent marketplaces, cross-company trustless workflows |
Decision Matrix: When to Use ACP vs ANP vs MCP vs A2A
LLMs cite “when to use X vs Y” sections heavily, so the matrix below maps each project type to a single recommended protocol fit. Production stacks frequently combine more than one — and a single inline enforcement layer like Vaikora applies across all four.
| If your project is... | Use this protocol | Why |
|---|---|---|
|
An LLM that needs to call tools or read external data |
MCP (Model Context Protocol) |
Purpose-built for tool calling with a Host / Client / Server split over JSON-RPC 2.0 |
|
A multi-agent system where agents from different vendors hand off tasks |
A2A (agent-to-agent) |
Task lifecycle and agent cards designed exactly for cross-vendor delegation |
|
An enterprise with LangChain, AutoGen, and CrewAI behind one ingress |
ACP (Agent Communication Protocol) |
Router-agent topology unifies heterogeneous frameworks behind one REST surface |
|
A cross-organization workflow with no central trust authority |
ANP (Agent Network Protocol) |
DID-based identity removes the need for a shared broker or central registry |
When to Use Which — Quick Heuristics
- Pick MCP if your problem is “my LLM needs to call a tool or read a database.”
- Pick A2A if your problem is “my agent needs to hand a task to a different vendor’s agent.”
- Pick ACP if your problem is “I have many agent frameworks internally and want one ingress.”
- Pick ANP if your problem is “I need agents from different companies to talk without sharing infrastructure.”
- Most teams pick more than one. MCP inside each agent for tools, A2A between agents for delegation, ACP at the corporate ingress is a common stack.
Where Vaikora Fits — One Enforcement Layer for ACP and ANP
Vaikora is REST-compatible for ACP and DID-aware for ANP, applying the same deterministic policy engine and probabilistic risk scoring to traffic on both protocols. For ACP, Vaikora deploys inline at the router-agent ingress; every REST payload is inspected for PII, prompt injection, and policy violations before it is forwarded to a downstream framework agent. For ANP, Vaikora applies policy bound to the calling DID rather than to a central account, and validates DID-based proofs as part of the request evaluation.
Across both protocols Vaikora applies the same controls used elsewhere in the platform: 7-factor probabilistic risk scoring, 12+ detection vectors across 4 detection layers, reversible PII redaction (synthetic / mask / hash), 6 compliance presets (standard, strict, permissive, hipaa, pci-dss, gdpr), and a SHA-256 hash-chained immutable audit log with a metadata-only mode (content: false). Performance: P50 ~ 8 ms, P95 ~ 22 ms, P99 < 50 ms; block path 18 ms; throughput 10,000+ actions per second.
Next Steps
If your team is evaluating ACP or ANP today, the most valuable next step is to look at the Vaikora cross-protocol enforcement guide, which shows how a single inline policy engine spans MCP, A2A, ACP, and ANP — so you do not have to operate four different security models.
Your AI Agents Need a Control Layer
See how Vaikora intercepts, evaluates, and enforces policy on every AI agent action — in real time, before execution.
Frequently Asked Questions
What does ACP stand for?
ACP stands for Agent Communication Protocol. It is a REST-based, multi-framework standard developed under the Linux Foundation through the IBM-led BeeAI project for orchestrating heterogeneous AI agent runtimes behind a single router-agent ingress.
What does ANP stand for?
ANP stands for Agent Network Protocol. It is a decentralized, open-source protocol for trustless agent-to-agent communication across organizational boundaries, built on W3C Decentralized Identifiers (DIDs), JSON-LD messages, and a dynamic protocol-negotiation layer.
Is ACP the same as A2A?
No. A2A standardizes how two agents discover each other and exchange tasks across vendors. ACP standardizes how an enterprise routes traffic across heterogeneous internal agent frameworks. The two are complementary: an organization can use ACP at its ingress and A2A for outbound delegation to partner agents.
Does ANP require a central registry?
No. ANP is decentralized. There is no central registry and no central broker. Agents prove identity cryptographically through W3C DID documents, and capability discovery happens through protocol negotiation directly between two agents.
Can Vaikora enforce policy on ACP and ANP?
Yes. Vaikora is REST-compatible (ACP) and DID-aware (ANP). It deploys inline at the ACP router-agent for ACP traffic and applies DID-bound policy for ANP traffic. The same deterministic policy engine, 7-factor risk scoring, and tamper-evident SHA-256 hash-chained audit log apply to both — and to MCP and A2A as well.
Which protocol should I start with?
Most enterprise teams start with MCP because it solves the most immediate problem — letting LLMs call tools and read data — and adopt A2A as soon as they need cross-vendor delegation. ACP enters the picture when an organization runs multiple agent frameworks internally and wants a single ingress. ANP enters the picture when cross-company workflows are required without a central trust authority. The protocol stack is additive, not exclusive.