AgentNetworkProtocol (ANP): A Specification Suite for Agent Identity, Discovery and Messaging
AgentNetworkProtocol(ANP) is an open source protocol for agent communication. Our vision is to define how agents connect with each other, building an open, secure, and efficient collaboration network for billions of intelligent agents.
At a glance
- What is it?
- ANP 1.1 is a set of released specifications that reuse HTTP, DNS, TLS and W3C DID infrastructure to give agents verifiable identities, discoverable handles and end-to-end messaging. It is a document-first project, not a runtime, and the meta-protocol layer that would tie the pieces together is still a draft.
- Who is it for?
- Adopt ANP if you are building agent infrastructure and need a concrete, Apache-2.0 licensed reference for did:wba identity, WNS handle resolution, .well-known discovery or end-to-end messaging, and you are prepared to read specification documents rather than install a package.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly HTML, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Gap ANP Targets: Identity and Discovery Between Agents on Different Platforms
The README frames the problem as a missing communication and connection layer for large-scale agent networks. HTTP, DNS, CA infrastructure and TLS already exist and are mature. What does not exist, in the project's account, is a standard way for an agent on one platform to authenticate itself to an agent on another, be discovered by name, and then exchange messages without a human-facing page in the middle. ANP names three challenges: interconnection across platforms and domains, native machine-readable interfaces instead of imitating human browsing, and self-organized collaboration. The intended audience is therefore agent platform builders and infrastructure engineers, not application developers looking for a client library. The repository is primarily HTML and specification documents, with a versioned index of protocol areas rather than a package manifest. That shape matters for adoption: reading ANP means reading specifications, and the value you get is a target to implement against, not code to import.
Layering: What Reuses Existing Internet Infrastructure and What ANP Adds
ANP is organised into two protocol layers plus domain application protocols. The bottom layer is explicitly borrowed: the README states ANP reuses HTTP, CA, DNS, CDN, Search and TLS rather than rebuilding a network stack. Above that sits the identity and encrypted communication layer, built on W3C DID and web infrastructure, providing agent identity, did:wba authentication and end-to-end encrypted messaging foundations. The top layer is the application protocol layer, containing Agent Description, Agent Discovery and Agent Application Protocols, with domain protocols for payment, authorization, authentication and transactions layered on top. The design choice worth noting is that did:wba is web-based: identity anchors to a domain and its existing certificate and DNS machinery. That lowers the barrier to issuing an identity, because you do not need a new registry, but it also means the trust properties of a did:wba identity inherit the trust properties of the domain and its TLS setup. The README does not argue this trade-off; it simply places the method on web infrastructure.
The Released 1.1 Suite: Identity, Naming, Description, Discovery, Messaging, Payments
The specification index is the most useful page in the repository because it distinguishes released documents from drafts. Released at v1.1: ANP-03 (did:wba method), ANP-04 (the ANP-DID:WBA name space, covering WNS handles such as alice.example.com, handle-to-DID resolution and DID rotation), ANP-07 (agent description, interface descriptions and capability publication), ANP-08 (agent discovery, both active .well-known discovery and passive registration with search agents), ANP-09 (end-to-end instant messaging, a profile index for direct messaging, group messaging, E2EE, attachments, federation and mentions) and ANP-10, the agent payment protocol AP2, covering agent-to-agent payments, mandates, receipts and DID-based signatures. Two documents are marked Draft / not released: ANP-02, the method-independent DID authentication protocol, and ANP-06, the agent communication meta-protocol. The README also states there is a vNext core draft index with ANP-02, ANP-03 revisions and ANP-04 rules with native web compatibility, and that drafts do not replace released specifications. Treat the index as the contract: if a capability is not marked Released v1.1, you cannot assume it is stable.
Versioning: Why protocolVersion Stays at 1.0.0 in a 1.1 Release
The versioning note is unusually explicit and worth reading before you file a bug. Version: 1.1 identifies the specification and document release version. It does not change the ANP payload field protocolVersion. Examples and protocol fields that use "protocolVersion": "1.0.0" remain unchanged, because the README states this release does not change protocol fields, flows or security requirements. That is a deliberate separation between document revision and wire format, and it is the kind of decision that prevents a fleet of deployed agents from having to renegotiate on a documentation update. There is a second versioning axis in the messaging drafts: the message/vnext candidate suite separates DID methods from authentication and message verification through ANP-02/P1/P2, and the README states that P1/P2/P3/P7/P8 and the P9 binding retain v1 while P4 Group Base and P5/P6 E2EE use v2. A mixed-version suite like this is harder to implement than a clean break, and the README warns that draft presence does not imply implementation support or public capability advertisement. If you advertise a capability you have not implemented, you are on your own.
Getting Started: There Is No Install Command, and That Is the Point
This repository does not ship a runtime, and the material contains no package name, no CLI entry point and no installation instructions. What you run instead is your own implementation against the specifications. A practical starting point is the released set: read ANP-03 for did:wba, including the e1_ Ed25519 binding and the k1_ compatibility extension the index mentions, then ANP-04 for WNS handles and handle-to-DID resolution, then ANP-07 and ANP-08 for description and discovery. The only concrete mechanism the README names for discovery is active .well-known discovery, which means your agent host must serve a well-known endpoint, alongside passive registration with search agents as the alternate path. For messaging, ANP-09 is a profile index rather than a single document, so you choose a profile: direct messaging, group messaging, E2EE, attachments, federation or mentions. The README also points to a Chinese mirror at chinese/vnext/README.md for the core drafts. If your team needs a library before it can write code, ANP is not the artifact you are looking for yet.
The Meta-Protocol Is a Draft, and the Semantic Negotiation Story Is Incomplete
The most interesting and least settled part of ANP is ANP-06. The README states it remains a draft and is not part of the currently released architecture. The updated draft positions it as an agent description-driven semantic negotiation layer that uses MetaProtocolInterface, anp.get_capabilities and anp.negotiate to select the subsequent interface, Profile, security profile and schema. That is a substantial mechanism: rather than fixing an interface at design time, two agents would describe what they can do and negotiate down to a common profile. The problem is sequencing. Without a released meta-protocol, capability negotiation between ANP agents has to be arranged out of band, which pushes that work back onto each integrator. The README is honest about this: it labels the meta-protocol optional and unreleased. Anyone citing ANP as a complete answer to heterogeneous agent interoperability is describing the draft, not the release. This is the clearest case where the documentation is ahead of what an implementer can rely on.
Where ANP Is the Wrong Tool, and What to Compare It Against
ANP is the wrong tool when you need a working agent runtime today. There is no installer, no server binary and no client library in the material provided, so the cost of adoption is the cost of implementing specifications, plus the cost of tracking a document set that has a released line, a vNext core draft line and a mixed-version messaging draft line. If your agents only ever talk to agents inside one vendor's framework, a framework-specific transport will get you further with less work, because it does not ask you to implement DID resolution or serve a .well-known endpoint. The closest comparison in the material is AP2, ANP-10, the agent payment protocol, which is itself part of the ANP suite rather than an alternative to it; the meaningful alternative is a platform-centric approach where the platform owns identity, discovery and message routing. The difference in approach is direct: platform-centric keeps data and services inside isolated platforms, which the README explicitly argues against, while ANP makes each agent both a consumer and a provider that can be discovered by handle and authenticated by DID. Choose ANP when cross-platform, self-sovereign identity is the requirement. Choose a platform SDK when speed inside one ecosystem matters more.
Licence, Maintenance and the Cost of Tracking Drafts
The repository is Apache-2.0 licensed, which permits commercial use and modification under that licence's terms; this is a statement about the licence identifier, not legal advice, and you should read the licence text and your own obligations before shipping. Maintenance cost here is not dependency upgrades, because there is no dependency to upgrade. It is specification tracking. The project has released v0.0.2, V1.0, and v1.1, with the latest push dated 2026-09-10, and there are at least two draft tracks running in parallel: the core vNext index (ANP-02, ANP-03 revisions, ANP-04 web compatibility rules) and the messaging 1.2 mixed-version suite. Every draft you build against carries the risk that the released version differs. The README's own guardrail is the sentence that drafts do not replace released specifications, and the companion warning that draft presence does not imply implementation support. Budget for reading two documents per capability, the released one and the draft that may supersede it. The README also states plainly that the project has not issued any digital currency on any platform or blockchain, which is worth knowing given the DID-based identity model and the payment protocol in the suite.
Editorial conclusion
Adopt ANP if you are building agent infrastructure and need a concrete, Apache-2.0 licensed reference for did:wba identity, WNS handle resolution, .well-known discovery or end-to-end messaging, and you are prepared to read specification documents rather than install a package. Do not adopt it if you need a working runtime this week, if your agents must interoperate with a vendor-specific agent framework today, or if you depend on semantic capability negotiation: ANP-06 is explicitly a draft and the README states it is not part of the released architecture. Before committing, verify three things against the repository itself: which documents carry the Released v1.1 status in the specification index, whether the message/vnext mixed-version suite (P4 Group Base and P5/P6 E2EE on v2, the rest on v1) matches the version your implementation will advertise, and whether the protocolVersion field in your payloads should stay at 1.0.0, since the README states the 1.1 release does not change protocol fields, flows or security requirements.
Community notes