A2A vs ANP: two designs for agents on the open web

A2A (Agent2Agent) is for handing work to an independent agent and tracking it as a task until it finishes. ANP (Agent Network Protocol) is for giving every agent a web-resolvable decentralized identifier (DID) and a public description, so other agents can find it, authenticate it and call its interfaces directly.

Both aim at agents that work across organizations on the open web. They make different bets. A2A standardizes one task protocol and relies on web PKI and ordinary HTTP authentication. ANP standardizes identity first, with DIDs and signed requests, and lets each agent describe its own interfaces.

Status as of September 26, 2026. A2A is a Linux Foundation project at protocol version 1.0 (release v1.0.1, May 28, 2026). ANP is developed by the ANP open source community under Apache 2.0. Its specification set 1.2 was tagged on GitHub on September 24, 2026. In that set, authentication, did:wba, naming, agent description and discovery are marked released. The meta-protocol for negotiating interfaces is still a draft, one group encryption profile is still a candidate, and the payments document is an unreleased draft.

What ANP is for

The ANP README describes the project as a protocol suite for agent identity, naming, discovery, negotiation, secure messaging and application-level collaboration. It reuses existing web infrastructure (HTTP, TLS, DNS, certificate authorities) and adds two layers on top.

Identity and authentication

Every ANP agent is identified by a DID, as defined by the W3C DID v1.0 Recommendation. ANP’s own method, did:wba, extends did:web: did:wba:example.com resolves to a DID document at https://example.com/.well-known/did.json. Path-style identifiers end in a fingerprint of the agent’s Ed25519 public key, which binds the identifier to that key. ANP 1.2 also accepts native did:web.

ANP-02 defines how an agent proves its DID on an HTTP request. On the first request, the client signs it with the Signature-Input and Signature headers from RFC 9421 (HTTP Message Signatures), plus a Content-Digest header when there is a body. The server fetches the client’s DID document, checks that the signing key is authorized, and may return an access token for later requests. ANP-02 states that authentication alone does not grant business authority. Permissions stay with the application.

Description and discovery

An Agent Description (AD) document is the agent’s entry point, similar to a website’s home page. It is JSON with linked-data support and schema.org vocabulary. It names the agent and its owner, lists information resources such as product data, and lists interfaces. Interfaces can be natural-language or structured, and the specification’s examples include OpenRPC and YAML interface documents.

ANP describes its interaction pattern as crawler-like. A calling agent fetches descriptions and data, then processes them locally, rather than sending the whole task to the other side. The specification argues this can limit how much private context leaves the caller.

Discovery has two modes. For active discovery, a domain serves a list of its public agents at /.well-known/agent-descriptions. For passive discovery, agents register their description URLs with search agents. An illustrative discovery document, following the ANP-08 format:

{
  "@context": {
    "@vocab": "https://schema.org/",
    "did": "https://w3id.org/did#",
    "ad": "https://agent-network-protocol.com/ad#"
  },
  "@type": "CollectionPage",
  "url": "https://example.com/.well-known/agent-descriptions",
  "items": [
    {
      "@type": "ad:AgentDescription",
      "name": "Freight Quote Agent",
      "@id": "https://example.com/agents/freight-quotes/ad.json"
    }
  ]
}

ANP also publishes end-to-end instant messaging profiles addressed by DID, for direct and group conversations with device-bound encryption.

What A2A is for

A2A gives two agents a shared task protocol. A server publishes an Agent Card, usually at /.well-known/agent-card.json, with its endpoints, skills and required security schemes. A client sends a message, the server creates a task, and the task moves through states such as TASK_STATE_WORKING, TASK_STATE_INPUT_REQUIRED and TASK_STATE_COMPLETED. Results come back as artifacts. The same operations exist in three bindings: JSON-RPC 2.0, gRPC and HTTP+JSON.

A2A identifies servers by their web origin and TLS certificate. Clients authenticate with the schemes the card declares: API keys, HTTP authentication, OAuth 2.0, OpenID Connect or mutual TLS. Cards can carry JWS signatures, covered in Signed Agent Cards.

Side by side

	ANP	A2A
Purpose	Identity, description and discovery for agents on the open web, plus messaging	Delegating tracked tasks between independent agents
Layer	Identity and encrypted communication layer, plus an application layer for description, discovery and domain protocols	Application protocol over HTTP(S)
Who talks to whom	Any agent to any agent it can resolve by DID or find through a description	A client agent to a remote agent that publishes an Agent Card
Transport	HTTP(S); interfaces each agent describes (for example OpenRPC); messaging profiles	JSON-RPC 2.0, gRPC or HTTP+JSON; Server-Sent Events; webhook push
Discovery	/.well-known/agent-descriptions listing Agent Description documents; registration with search agents	Agent Card at /.well-known/agent-card.json; registries; direct configuration
Identity and auth	A DID per agent (did:wba or did:web); RFC 9421 request signatures, then an access token	Web PKI for the server; card-declared schemes for the client; optional JWS-signed cards
State	Defined by each interface; messaging keeps conversation state per profile	Tasks with a defined lifecycle and contextId
Governance and status	ANP open source community, Apache 2.0; spec set 1.2 (September 24, 2026); meta-protocol still draft	Linux Foundation project; version 1.0

When to use A2A

Use A2A when you want another organization’s agent to take on a job and report back: a quote, a claim, a refund, a booking. The task lifecycle, mid-task questions and push notifications are built into the core protocol, and the A2A project maintains SDKs in several languages, including Python, JavaScript, Java, Go and .NET. It fits businesses that already run HTTPS services with OAuth or API keys and want their agent reachable at a known domain.

When ANP fits

Consider ANP when you need a portable, cryptographic identity for each agent, independent of any one platform’s accounts. It also fits when you want agents to read your public information and call typed interfaces directly, the way a crawler reads a site. Its DID-based request signing can be adopted on an ordinary HTTP API without the rest of the suite. Weigh maturity too: the meta-protocol is a draft, and the README says publishing a specification does not mean SDKs or products support it yet.

Using both

The two do not collide. An agent’s domain can serve an A2A Agent Card and an ANP discovery document at their separate well-known paths. Points to plan for:

• Identity. A2A has no DID security scheme. An A2A server that wants to accept ANP-style DID-signed requests would need an A2A extension or a bilateral agreement.
• Pointers between documents. The protocol field on an ANP interface is an open string, and the specification’s examples include YAML, OpenRPC, MCP and WebRTC. Neither spec defines how an ANP description should point to an A2A endpoint, so treat any cross-reference as your own convention.
• One source of truth. If both documents describe the same agent, generate them from the same data so names, owners and endpoints do not drift.

Common misconceptions

“ANP is A2A with DIDs added.” The interaction models differ. A2A sends a task to the other agent and waits for its result. ANP’s description pattern has the caller read published data and call described interfaces itself.

“A DID proves who runs an agent.” A did:wba identifier resolves through HTTPS on a domain, so it proves control of the keys that domain publishes. Whether that domain belongs to a trustworthy business is a separate question, and ANP-02 says authentication does not imply authority.

“ANP is a W3C standard.” The ANP community initiated a W3C Community Group. W3C hosts such groups, but they do not speak for the W3C membership, and their reports are not Recommendations.

“A2A has no identity model.” A2A relies on TLS server identity, declared authentication schemes and optional card signatures. It does not give each agent its own decentralized identifier.