Point the name
at your real agent
Owning a name and operating an agent are different proofs, and PAN keeps them separate. Binding is the moment a name stops being a reservation and becomes a verified address: your agent proves it is yours, and the name points at it. Three recipes cover every agent, starting with the one you probably run.
three recipes
Whatever your agent is, one of these fits
Run the adapter, then connect
Most personal agents are outbound-only: they have no key and no inbound address, so there is nothing to bind a name to yet. The mesh-adapter, AgentMesh's thin reference node, fixes both in one command: it gives your agent a stable key and an inbound address, then signs the pairing code for you.
# 1. make the agent reachable (any CLI works; message on stdin, reply from stdout) npx https://storage.googleapis.com/agentmesh-releases/mesh-adapter-0.5.1.tgz start --cmd "claude -p" # 2. request a pairing code here under My handles, then mesh-adapter pair Coder.jeff@gmail.com KX4-92F
Full node products do the same job with more around it, many agents, persistence, a settings surface; the Egg Gateway is one example. Either way, the pairing is identical.
If your agent can run commands, it can do this whole recipe itself: send your agent.
Submit it under your email
An A2A card, an HTTP API, an MCP server: some agents are already reachable and have no signing key of their own. Submit the agent under the same email that owns the name and it binds directly, submitter-match. The card then carries that endpoint, whatever its protocol; PAN is neutral about the transport.
Sign the code yourself
If your agent holds its own key, pairing is one signature over pan-pair-v1:<code>:<agent-id>, about 25 lines in any language. The developer page has the signer; the sequence below is everything that happens.
PAN names your agent; it does not make your laptop reachable. The address comes from somewhere else, a node like the adapter or the Gateway, or an endpoint you already operate, and the name points at it. Naming and reachability are different jobs, and the recipes above are really answers to the second one.
the connecting moment (the protocol calls it pairing)
One signature turns a name into an address
Under recipes A and C the mechanics are the same: the registrar gives you a short code, your agent signs it, and the binding is the intersection of two proofs. The code proves you own the name; the signature proves you run the agent.
In your session, request a pairing code. It is single-use and expires in ten minutes.
Whatever runs your agent, the adapter, a gateway, a five-line script, signs the code with the agent's key.
Signature verified against the agent's key. The name now resolves to a card carrying that agent's address.
The registrar may not require any particular agent host, framework, or network to pair. If an agent declares a key, whoever holds that key can bind, from any runtime. That is normative, not a promise.