Agent Network Protocol (ANP)

An open-source protocol for agent identity, discovery, and communication across the open internet. ANP tackles the problem that other protocols assume away: how do agents that have never met find each other, verify identity, and negotiate how to communicate?

Posted Apr 12, 2026

12 min read

“The HTTP of the Agentic Web” – an open-source protocol for agent identity, discovery, and communication across the open internet. ANP tackles the problem that other protocols assume away: how do agents that have never met find each other, verify identity, and negotiate how to communicate?

What is ANP?

ANP is an open-source communication protocol designed to enable billions of AI agents to discover and interact with each other across the internet without relying on centralized registries, proprietary platforms, or pre-configured integrations. It builds on existing web infrastructure – HTTPS, DNS, JSON-LD – and adds a decentralized identity layer using W3C Decentralized Identifiers (DIDs).

The project is maintained by the agent-network-protocol organization on GitHub, with a technical white paper published on arXiv. It positions itself as the foundational networking layer for an “agentic web” – a future where agents are first-class citizens of the internet, discoverable and addressable like websites are today.

The Problem ANP Solves

Most agent communication protocols (A2A, ACP, MCP) assume agents already know about each other. A2A’s Agent Cards work great when you know the URL. MCP assumes a configured server connection. But none of them answer the more fundamental questions:

How does an agent discover other agents it has never interacted with? Not from a hardcoded list, but dynamically across the open internet.
How does an agent verify another agent’s identity? Without a central authority, how do you know the “compliance-checker” agent at some URL is actually operated by who it claims?
How do two agents that speak different protocols negotiate a common language? If Agent A uses REST and Agent B uses JSON-RPC, who adapts?
How does this scale to millions of agents? Enterprise registries work for hundreds of agents. The internet has different requirements.

ANP’s answer is to layer agent networking on top of the same infrastructure that makes the web work: DNS for naming, HTTPS for transport, DIDs for identity, and JSON-LD for semantic description. No new infrastructure required – just new conventions on existing rails.

Architecture

ANP uses a three-layer architecture that separates concerns cleanly:

┌─────────────────────────────────────────────────┐
│  Layer 3: Application Protocol Layer             │
│  Agent Description (ADP) + Agent Discovery (ADSP)│
│  What agents can do, how to find them            │
├─────────────────────────────────────────────────┤
│  Layer 2: Meta-Protocol Layer                    │
│  Dynamic protocol negotiation via natural language│
│  How agents agree on communication details       │
├─────────────────────────────────────────────────┤
│  Layer 1: Identity & Encrypted Communication     │
│  W3C DID (did:wba) + HTTPS + DNS                │
│  Who agents are, how they prove it               │
└─────────────────────────────────────────────────┘

Layer 1: Identity and Encrypted Communication

The foundation. Based on the W3C DID standard, this layer provides:

Decentralized identity via the did:wba method (Web-Based Agent)
Mutual authentication without a central authority
End-to-end encrypted communication channels
Built on HTTPS and DNS – no blockchain, no specialized infrastructure

Layer 2: Meta-Protocol Negotiation

The genuinely novel layer. Rather than mandating a single communication protocol, ANP lets agents negotiate how they’ll communicate using natural language. Two agents meeting for the first time can exchange their capabilities, requirements, and preferences, then dynamically agree on request formats, API conventions, and session management.

This is ambitious and speculative – it assumes agents are capable enough to negotiate protocols on the fly. But the design is forward-looking: as agents get smarter, rigid protocol specifications become less necessary.

Layer 3: Application Protocol Layer

Two core modules:

Agent Description Protocol (ADP) – standardized self-description using JSON-LD and schema.org vocabulary
Agent Discovery Service Protocol (ADSP) – mechanisms for agents to find each other (active crawling + passive registration)

How It Works

did:wba – Web-Based Agent Identity

ANP’s identity system uses did:wba, a DID method designed specifically for web-based agents. Unlike blockchain-based DID methods, did:wba leverages existing web infrastructure:

Each DID maps to an HTTPS URL hosting a DID document:

did:wba:example.com:agents:compliance-checker
  --> https://example.com/agents/compliance-checker/did.json

The DID document contains the agent’s public keys, verification methods, and service endpoints:

        
      
{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:wba:example.com:agents:compliance-checker",
  "verificationMethod": [{
    "id": "did:wba:example.com:agents:compliance-checker#key-1",
    "type": "JsonWebKey2020",
    "controller": "did:wba:example.com:agents:compliance-checker",
    "publicKeyJwk": {
      "kty": "EC",
      "crv": "P-256",
      "x": "...",
      "y": "..."
    }
  }],
  "service": [{
    "id": "#agent-service",
    "type": "AgentService",
    "serviceEndpoint": "https://example.com/agents/compliance-checker/api"
  }]
}

The key insight: the agent’s domain (example.com) already has DNS and TLS infrastructure. By hosting the DID document on that domain, you get identity verification through the same trust model that secures the web today. No blockchain consensus needed.

Authentication Handshake

When Agent A wants to communicate with Agent B:

Agent A signs its request using its private key, including:
- A nonce (random string to prevent replay attacks)
- A timestamp (UTC, ISO 8601)
- The verification method (DID fragment identifying the key)
- A signature over the nonce, timestamp, service domain, and client DID
Agent A sends the request with an Authorization header containing these fields
Agent B receives the request, extracts Agent A’s DID, fetches Agent A’s DID document from the web, retrieves the public key, and verifies the signature
If valid, Agent B processes the request and responds

Agent A                                    Agent B
  │                                          │
  │  HTTP Request + Authorization header     │
  │  (nonce, timestamp, DID, signature)      │
  │ ────────────────────────────────────────> │
  │                                          │
  │         Fetches did:wba document         │
  │         Verifies signature               │
  │                                          │
  │  HTTP Response                           │
  │ <──────────────────────────────────────── │

Agent Description Documents (JSON-LD)

An Agent Description (AD) document is the agent’s public profile – its business card on the agentic web. Written in JSON-LD using schema.org vocabulary with ANP extensions:

        
      
{
  "@context": {
    "@vocab": "https://schema.org/",
    "ad": "https://agent-network-protocol.com/ad/"
  },
  "@type": "ad:AgentDescription",
  "@id": "https://example.com/agents/compliance-checker/ad.json",
  "name": "EU Compliance Checker",
  "description": "Validates data processing activities against GDPR, AI Act, and DORA requirements",
  "did": "did:wba:example.com:agents:compliance-checker",
  "owner": {
    "@type": "Organization",
    "name": "MMS Technology",
    "url": "https://www.mms.de"
  },
  "ad:capabilities": [
    {
      "@type": "ad:Capability",
      "name": "GDPR Compliance Check",
      "description": "Validates data pipelines and processing activities against GDPR",
      "ad:inputFormat": "application/json",
      "ad:outputFormat": "application/json"
    },
    {
      "@type": "ad:Capability",
      "name": "AI Act Risk Classification",
      "description": "Classifies AI systems by risk level per EU AI Act"
    }
  ],
  "ad:protocols": ["https://agent-network-protocol.com/protocol/v1"],
  "ad:status": "active"
}

Using JSON-LD and schema.org means agent descriptions are machine-readable, semantically rich, and compatible with existing web crawlers and search engines.

Agent Discovery

ANP defines two discovery mechanisms:

Active Discovery – a search engine or agent can discover all public agents under a domain by knowing only the domain name. Similar to robots.txt or sitemap.xml, a domain publishes an index of its agents at a well-known path. Crawlers can traverse these indexes to build agent registries.

Passive Discovery – agents actively submit their description URLs to registries or other agents. Think of it as SEO for agents – you don’t just wait to be found, you announce yourself.

Code Example (OpenANP)

The anp Python package provides a FastAPI-based framework for building ANP agents:

        
      
from anp import anp_agent, AgentConfig

@anp_agent(AgentConfig(
    name="EU Compliance Checker",
    did="did:wba:example.com:agents:compliance-checker",
    prefix="/agent"
))
class ComplianceAgent:

    @interface
    async def check_gdpr(self, pipeline_config: dict) -> dict:
        """Validate a data pipeline against GDPR requirements."""
        # Agent logic here
        return {
            "compliant": True,
            "findings": [...],
            "risk_level": "low"
        }

    @interface
    async def classify_ai_risk(self, system_description: str) -> dict:
        """Classify AI system risk level per EU AI Act."""
        return {
            "risk_category": "limited",
            "rationale": "..."
        }

The framework automatically generates the DID document, agent description, and discovery endpoints.

Key Concepts

Decentralized Identity Without Blockchain

This is ANP’s sharpest design decision. Most DID methods (did:ion, did:ethr) require blockchain infrastructure, which adds latency, cost, and complexity. did:wba uses the web itself as the trust anchor – your domain’s DNS and TLS certificate prove you control the identity. This is pragmatic: every organization already has web infrastructure. Nobody needs to run blockchain nodes to give their agents identity.

The tradeoff: did:wba inherits the web’s centralization points (DNS registrars, certificate authorities). A truly decentralized purist would object. But for enterprise use, this is actually a feature – you want agents to be tied to organizational domains that can be audited and governed.

Meta-Protocol Negotiation

The most ambitious and least proven part of ANP. The idea: instead of mandating that all agents speak the same protocol, let them negotiate. Agent A says “I speak REST with JSON payloads.” Agent B says “I speak JSON-RPC.” The meta-protocol layer helps them find common ground, potentially using natural language understanding to bridge the gap.

In practice, this is more vision than reality today. Current implementations default to ANP’s own protocol rather than dynamically negotiating alternatives. But the architectural separation is sound – if agent capabilities improve enough, this layer becomes genuinely useful.

Semantic Web Heritage

ANP’s use of JSON-LD and schema.org vocabulary connects it to the semantic web tradition. Agent descriptions aren’t just structured data – they’re linked data that can be traversed, queried, and reasoned about by machines. This makes ANP agent descriptions compatible with knowledge graphs, search engines, and other semantic web tooling.

Aspect	ANP	A2A (Google)	MCP (Anthropic)
Primary focus	Discovery + identity	Task delegation	Tool integration
Discovery	Active crawling + passive registration	Agent Cards at known URLs	Server configuration
Identity	Decentralized (did:wba)	Delegated to auth provider	N/A (trusted connection)
Wire format	HTTPS + JSON-LD	JSON-RPC 2.0	JSON-RPC 2.0
Assumes agents know each other	No	Yes	Yes
Internet-scale	Designed for it	Enterprise-scale	Single agent-server
Maturity	Experimental (white paper)	Early production	Production-ready

ANP vs A2A – Complementary Layers

A2A answers: “Given that Agent A knows Agent B exists, how do they collaborate on tasks?”

ANP answers: “How does Agent A find Agent B in the first place, and how do they verify each other’s identity?”

These are different problems. A2A assumes a known peer and provides rich task lifecycle management. ANP handles the open-internet discovery problem – finding agents you’ve never interacted with, verifying they are who they claim to be, and establishing initial communication.

In a mature agentic web, you’d likely use ANP for discovery and identity, then A2A for task execution. ANP finds the agent and verifies its identity; A2A manages the actual work.

ANP vs Traditional Service Discovery

ANP is doing for agents what DNS + HTTP did for web services, but with identity baked in. Traditional service discovery (Consul, Eureka, Kubernetes service mesh) works within a controlled infrastructure boundary. ANP works across the open internet, across organizational boundaries, without requiring shared infrastructure.

Current Adoption and Maturity

Status: Experimental / White paper stage.

ANP is the least mature of the four major agent protocols (MCP, A2A, ACP, ANP). Honest assessment:

What exists:

Technical white paper with detailed specifications (published on arXiv)
GitHub repository with specification documents and reference implementation
Python package (anp) for building ANP-compliant agents
did:wba method specification (v0.1)
Agent Description Protocol and Agent Discovery Service Protocol specs

What doesn’t exist yet:

Production deployments at any meaningful scale
Major vendor adoption or backing (contrast with Google behind A2A, Anthropic behind MCP, IBM behind ACP)
Established agent registries or crawlers
Battle-tested security model (the DID authentication flow is specified but not widely implemented)
Clear governance structure or foundation backing

Realistic assessment for enterprise adoption: ANP solves a real problem – open-internet agent discovery – that nobody else is tackling seriously. But the problem isn’t urgent yet. Most enterprise AI platforms operate within controlled environments where agents are registered, not discovered. ANP becomes relevant when the agentic web matures enough that cross-organization agent discovery is a real workflow, not a thought experiment.

Where to watch: If a major cloud provider or foundation adopts ANP’s approach to agent identity (did:wba specifically), that would signal real traction. The DID-based identity model is the most transferable piece of ANP, even if the rest of the protocol remains experimental.

Enterprise Relevance

For an enterprise AI platform like the one at MMS, ANP is worth tracking for two specific scenarios:

Scenario 1: Cross-organization agent collaboration. When MMS agents need to interact with supplier agents, partner agents, or third-party service agents across organizational boundaries, you need discovery and identity that doesn’t require bilateral configuration for every relationship. ANP’s model addresses this.

Scenario 2: Agent marketplace. If the enterprise AI platform evolves toward an internal or external marketplace where teams publish agents for others to discover and consume, ANP’s discovery and description protocols provide a foundation.

Neither scenario is urgent today. But designing agents with clear identity (who operates this agent, what are its capabilities, how to authenticate) is good practice regardless, and aligns with where ANP is headed.

Spec Links

ANP GitHub Repository – specifications and white paper
ANP Reference Implementation – Python package for building ANP agents
ANP Technical White Paper – full protocol design
did:wba Method Specification – DID method for web-based agents
Agent Description Protocol Specification – JSON-LD agent descriptions
Agent Discovery Protocol Specification – active and passive discovery

References

ANP Technical White Paper – arXiv – academic publication with full protocol analysis
A Survey of Agent Interoperability Protocols (MCP, ACP, A2A, ANP) – comparative study of all four protocols
What Are AI Agent Protocols? – IBM – IBM’s overview including ANP positioning
Top AI Agent Protocols in 2026 – GetStream – industry landscape analysis
ANP Official Documentation – complete guide and specification index
AgentRFC: Security Design Principles for Agent Protocols – security analysis covering ANP

AI & Agents, Protocols

agent-patterns

This post is licensed under CC BY 4.0 by the author.