Personal Agent Naming and the Agent Name Service name agents for different people
Both give agents names, and the names even look alike. They are built for opposite ends of the same problem. The Agent Name Service (ANS) is a full identity layer for agents acting across organizations. Personal Agent Naming is a light naming layer for personal agents. Each is built for its own job, and neither is a smaller version of the other.
The two are built for different weights on purpose
ANS, the Agent Name Service, anchors every agent to a DNS domain. A registration authority checks that you control the domain, has two X.509 certificates issued for the agent (one from a public CA, one from a private CA), and seals every lifecycle event into an append-only transparency log. That suits autonomous agents settling financial or supply-chain transactions across company boundaries, and it is more than a person with an inbox and an agent can set up. Personal Agent Naming starts from the credential that person already has, their email: one anchor and one signature, and a name takes minutes.
This page compares version 0.10 of the Personal Agent Naming specification with draft-narajala-courtney-ansv2-01, the latest published revision of ANS, dated 13 April 2026. It replaced the original ANS draft, draft-narajala-ans-00, from May 2025.
The comparison
| Dimension | ANS | Personal Agent Naming |
|---|---|---|
| Built for | Autonomous agents transacting across organizations: finance, supply chain, sensitive business | Personal agents, owned by someone with an email and nothing else |
| Weight class | Heavyweight. Identity infrastructure that can run in public, inside one enterprise, or among partners | Lightweight. A name and an address, minutes to set up |
| Root of trust | DNS domain control, verified by ACME (a DNS-01 or HTTP-01 challenge) | Control of an email inbox |
| Identity | Two X.509 certificates: a server certificate from a public CA and an identity certificate from a private CA. Agents connect over mTLS. Signatures use ES256 by default | An Ed25519 key; a pairing signature binds name to agent. The registrar signs every card it serves |
| Name form | ans://v1.0.0.agent.example.com · structured, versioned | Coder.ana@example.org · opaque, never parsed |
| Software changes | Every code change is a new version, with a new name, a new identity certificate and a new log entry | The name stays the same. Only a new key changes identity, and the card lists every key change |
| To register | A domain, a version, an endpoint and a certificate request, sent to a registration authority that runs ACME, gets both certificates issued and gives you DNS records to publish. An SDK automates the steps | Prove control of the email at a registrar, sign the pairing with the agent's key, and choose a name. At some registrars this is one step in an account |
| Verification | The client picks a tier: Bronze checks the certificates, Silver adds DANE over DNSSEC, Gold adds the transparency log | The resolver checks the registrar's signature on the card and pins the agent key, warning loudly if it changes |
| Transparency | Append-only log aligned with IETF SCITT: inclusion and consistency proofs, COSE receipts. Public in a public deployment | Owner-scoped hash chain, kept private because a public log would leak rosters. Each handle's key changes are public, and so are signed counts of the log's entries |
| Discovery | Separate from registration: independent discovery services index the sealed events | No search. Resolves a name you already have; an owner can opt in to being found by email |
| Beyond identity | Identity only, with room for third-party attestations (SOC 2, SBOMs) and separate trust scoring | None. A handle says where to reach an agent and nothing about how good it is |
| Messaging | None of its own. Agents speak A2A, MCP or HTTP, over mTLS with the identity certificate | None. Hands the address to A2A or Agent Messaging |
| Federation | Designed in: anyone may run a registration authority, log, trust index or discovery service. A governed multi-RA ecosystem is future work | A domain can answer for its own addresses, and an owner can move a name to another registrar. How a network of registrars is governed is not specified yet |
Pick by what you have
An organization should reach for ANS
- You own a domain, control its DNS, and can register with a registration authority.
- Your agents transact across company boundaries.
- You need public, provable, tamper-evident audit trails.
- Identity has to satisfy security and compliance review.
A person should reach for Personal Agent Naming
- You have an agent and an email, and no PKI team.
- You want a name to hand out, today, in minutes.
- You want the name to resolve to a reachable address.
- You do not need enterprise-grade, re-verifiable identity.
The two are not mutually exclusive. One agent can carry a Personal Agent Naming handle for the people who reach it by name, and an ANS identity for the organizations that require CA-backed trust. They are different layers on the same agent.