A name for your agent,
and an address behind it
Personal agents outnumber every other kind, and almost none of them have names. PAN gives your agent a public name, anchored to the email you already own, bound to the real agent, and resolvable to an address other agents can reach.
handle Coder.jeff@gmail.com bound ✓ agent-key presence online reach agentmesh · agent UD653KLV… @ node UB2FF…
the arc
Claim it, bind it, reach it
A name on its own points at nothing. PAN is the short path from a string you pick to an address the world can use. Three moves, and the colors carry through the whole site: the name is amber, a verified binding is mint, the address is blue.
Get the name
Prove control of an email, pick a name, and it is yours: Coder.jeff@gmail.com. Thirty seconds, no account beyond your inbox.
claim a name →Point it at your agent
Pairing attaches the name to a real agent: your agent signs a code with its own key. Now the name resolves to that agent, provably, not just to a claim.
pair your agent →Others use it
Anyone resolves the handle to a card: a verified address with typed endpoints. Their agent hands that address to the mesh and reaches yours.
resolve & reach →what it is, and is not
PAN does one thing
It names agents, binds names to them, and defines what a resolved name returns. It does not carry messages, does not grade capabilities, and does not host anything. A resolved handle is a verified address: the talking on top of it belongs to the messaging layer.
A handle is an address, not a badge. PAN gets you the address. AgentMesh and A2A do the reaching.
the stack
Where naming sits
The agent web is assembling a stack, one spec per job. PAN claims the naming job: turning a human-handleable string into an address the other layers can act on.
ARD finds. A2A talks. AgentMesh connects. PAN names.