The agentic web: how ANP wants to be the HTTP of agents

The web works because of two boring, decentralized facts. Any computer can have a domain name, resolved by DNS, owned by whoever registered it. And any computer can serve a document over HTTP that links to documents on any other computer, with no permission from a central registry. There is no master list of every website. There is no company you apply to before publishing one. You buy a name, you stand up a server, and you are reachable by the entire internet.

That property — permissionless, decentralized reachability — is the thing the agentic web does not yet have. We have agents that can call tools. We have agents that can call other agents inside a company, or between two companies that have already signed a contract and exchanged credentials. What we do not have is the equivalent of typing a URL: one agent discovering and trusting an agent it has never met, run by an organization it has no prior relationship with, anywhere on the open internet.

Four protocols are circling this problem, and they are not really competitors so much as a stack at different altitudes. The Agent Network Protocol (ANP) is the one aiming highest, and the one whose name gives away the ambition: it wants to be the HTTP of the agentic web.

Four protocols, sorted by openness

It is easy to lump these together as “agent protocols” and lose the plot. The clarifying axis is openness — how much shared trust the two parties need before they can talk.

MCP (the Model Context Protocol) connects an agent to its tools and data. The relationship is vertical: an agent reaches down to a database, a file system, an API. It is the most established of the four and answers a different question than the rest, so set it aside as the “agent to tools” layer.
A2A (Agent-to-Agent) connects agents to each other. Two agents exchange capabilities and delegate tasks. In practice this happens inside an enterprise or across a small set of partner organizations. An agent advertises itself with an Agent Card — a JSON document describing what it can do — and is often found through a directory the organization maintains.
ACP (the Agent Communication Protocol) lives in the same neighborhood as A2A: agent-to-agent messaging, designed for richer multi-agent coordination, again largely within a trusted boundary.
ANP (the Agent Network Protocol) connects agents to each other with no shared boundary at all. No company directory. No pre-exchanged keys. No platform both agents had to join first. Any agent, anywhere, discoverable and verifiable by any other.

That last jump is the entire story. A2A and ACP assume a perimeter — a set of agents that already belong to the same club. ANP assumes the internet, where the default relationship between two parties is that they have never met and trust nothing about each other. Building agent communication on that assumption is a fundamentally harder problem, and it forces ANP to answer a question the enterprise protocols can mostly sidestep: how do you establish identity and trust between strangers, with no referee?

The hard part is identity without a referee

Inside an enterprise, identity is easy because there is a referee. A company directory says “this agent belongs to the procurement team.” An identity provider issues tokens. A central platform vouches for everyone who joined it. Trust is delegated to an authority that both parties already accept.

Remove the authority and the problem changes shape. If an agent shows up claiming to be agent.acme.example, what stops any other agent from claiming the same thing? On the human web, the answer is a chain of trust rooted in certificate authorities and DNS — your browser believes a site is acme.example because a CA it trusts has signed a certificate binding that name to a public key. ANP needs the agent equivalent: a way for an agent to prove it is who it says it is, that another agent can verify independently, without phoning a central server that hands out identities.

The W3C’s answer to this general problem is the Decentralized Identifier.

Decentralized Identifiers, briefly

A Decentralized Identifier (DID) is a globally unique identifier that the subject controls directly, rather than renting from a registrar. It is a W3C standard, and it looks like a URI with a particular shape:

did:method:method-specific-identifier

The first segment is always did. The second names the method — the rules for how this particular flavor of DID is created, resolved, and verified. The third is an identifier that only makes sense within that method.

The crucial move is that a DID resolves to a DID Document: a small JSON-LD file listing the public keys associated with the identifier and the ways you can interact with its subject. Because the subject controls the keys, it can prove ownership of the DID by signing a challenge — anyone holding the DID Document can check the signature against the listed public key. No central authority is consulted to perform the verification. Trust comes from cryptography plus the method’s resolution rules, not from a registry’s say-so.

DIDs are often associated with blockchains, because several early methods (did:ion, did:ethr) anchor their data on a ledger. That association is exactly what makes people assume the agentic web must involve crypto. ANP deliberately does not.

did:wba: DNS and HTTPS, not a blockchain

ANP’s chosen method is did:wba — Web-Based Agent. Its whole premise is that the web already has a working, decentralized system for proving who controls a name, and agents should reuse it rather than reinvent it on a ledger.

Under did:wba, an agent’s identifier is tied to a domain it controls, and resolving the DID means making an ordinary HTTPS request to that domain to fetch the DID Document. The security model is the one the web already runs on: DNS says which server answers for a domain, and TLS certificates prove you are really talking to that server and not an impostor. If an agent’s DID points at acme.example and you can fetch its DID Document over authenticated HTTPS from acme.example, you have the same grounding of trust your browser uses every time it shows a padlock.

The consequences are worth spelling out, because this is the design decision that makes ANP feel like a web protocol rather than a crypto protocol:

No new infrastructure. No ledger to run, no gas to pay, no consensus to wait on. If you own a domain and can serve HTTPS, you can host agent identities today.
Ownership is already meaningful. Domain ownership and the existing certificate-authority system are a battle-tested, decentralized-enough root of trust. Whoever controls the domain controls the identity — which is exactly the property you want, and exactly what DNS and TLS already enforce.
It composes with the rest of the web. The same DNS name can serve a website to humans and a DID Document to agents. Identity for agents becomes one more thing your domain does.

So did:wba is, roughly, DNS for agent identity: a decentralized lookup that turns a name into a verifiable, key-bearing description of whoever stands behind it.

ANP’s open-web model (left) versus a central directory (right). On the left, agents resolve each other’s did:wba identifiers directly over HTTPS, with DNS and TLS as the trust root — the same plumbing your browser uses. On the right, every discovery and every trust decision routes through one operator.

A homepage for every agent: JSON-LD and schema.org

Identity tells you who an agent is. It does not tell you what it can do. For that, ANP gives every agent a self-description — effectively a machine-readable homepage that another agent fetches and reads before deciding how to interact.

These descriptions are written in JSON-LD using the schema.org vocabulary. JSON-LD (JSON for Linked Data) is ordinary JSON with one addition: a @context field that maps the document’s terms to globally shared definitions. So when an agent’s description says it offers a Service with a particular name and a list of potentialAction entries, those words are not ad-hoc keys that each platform interprets differently — they point at schema.org’s published, widely understood definitions of what those terms mean. Two agents built by teams that never coordinated can still agree on what a field means, because both are anchored to the same external vocabulary.

This is the same trick that lets search engines understand web pages. For over a decade, websites have embedded schema.org JSON-LD to tell crawlers “this page is a recipe, with this cook time and these ingredients,” or “this is a product, with this price and this rating.” ANP points that established machinery at agents: this endpoint is an agent, with these capabilities, reachable through these actions, identified by this DID.

So the two pieces fit together cleanly into a familiar shape. did:wba is DNS for agents — turn a name into a verifiable identity. The JSON-LD self-description is the homepage for agents — a structured page describing what the thing behind that identity actually offers, in a vocabulary everyone already reads. Discovery becomes the agent equivalent of what a crawler does to the human web: follow a name to a server, fetch a structured description, understand the offering, and link onward.

The ANP discovery handshake between two agents that have never met: resolve, verify, describe, interact — all over standard web infrastructure, ending in an end-to-end encrypted channel.

Trustless, end-to-end, cross-organization

Because identity is cryptographic and self-sovereign, ANP can offer something the perimeter-bound protocols cannot promise by default: end-to-end encrypted, trustless communication across organizational boundaries. “Trustless” here is a term of art and does not mean reckless — it means neither party has to trust a shared intermediary. Each agent proves control of its DID by signing with the private key behind the public key in its DID Document. From there they can negotiate an encrypted channel directly. No directory operator sits in the middle holding everyone’s keys and seeing everyone’s traffic. The security rests on the same asymmetric cryptography that secures the web, applied agent-to-agent.

This is the payoff of building on DIDs instead of a registry. A central directory is convenient — it is the simplest way to make agents findable — but it is also a single point of trust, a single point of failure, and a single point of control. Whoever runs it decides who is listed, can revoke anyone, and can observe every lookup. ANP’s bet is that the agentic web, like the human web, should not have an owner.

The honest caveat: this is the visionary one

It would be misleading to present ANP as a peer of MCP and A2A in adoption. It is not, and the gap matters.

Today, the established, complementary pair is MCP and A2A. MCP has broad traction for connecting agents to tools; A2A has serious institutional backing for agent-to-agent delegation inside and between organizations. If you are shipping a multi-agent system this quarter, those are the protocols with the ecosystem, the SDKs, and the production deployments. ACP sits alongside A2A in the same enterprise-oriented space.

ANP is the forward-looking one — an open-source community project pursuing a genuinely harder and more speculative goal. An open, ownerless network of mutually discoverable agents is a beautiful idea, and it is also the kind of idea that takes years and a great deal of coordination to become real. The web took that long. There are open questions ANP’s elegant core does not yet fully answer at scale: reputation (a verifiable identity tells you an agent is who it claims, not whether it is competent or honest), revocation, spam and abuse on an open network, and the discovery problem itself — did:wba lets you verify an agent once you know its name, but finding agents you have never heard of, without a directory, is its own unsolved puzzle.

None of that makes the vision wrong. It makes it early.

The invariant

Strip away the acronyms and the four protocols line up on a single axis: how much prior trust two agents need before they can talk. MCP needs an agent and its tools. A2A and ACP need agents that already share a perimeter. ANP needs nothing but the open web.

ANP’s wager is that agents will eventually want the same thing websites wanted — to be reachable by anyone, owned by their operator, and trusted on the strength of cryptography rather than membership in someone’s club. Its design reflects that wager with unusual discipline: reuse DNS and TLS instead of inventing a ledger, reuse schema.org instead of inventing a vocabulary, reuse the web’s trust model instead of appointing a referee. DNS for agents, a homepage for agents, a handshake for agents.

Whether the agentic web ends up looking like the open web or like a handful of walled gardens is not yet settled. ANP is the most complete articulation of the open-web answer. It is the least mature of the four, and the most ambitious — and those two facts are the same fact.