Humans have simple names. “Boris.” “Sarah.” “Chen.” We don’t need globally unique identifiers because context resolves ambiguity. If I say “Boris called,” you know which Boris from context — your friend, your coworker, your cousin.
Agents don’t have that luxury.
When an agent says “forward this to Alex,” which Alex? There could be thousands of agents named Alex across different networks, relays, and systems. Without global uniqueness, agent-to-agent communication breaks down.
But global uniqueness creates a different problem: discoverability.
The Human Model Doesn’t Scale#
In human networks, names are scoped by context:
- “Boris” in your contacts refers to a specific person
- “Boris” on Twitter refers to @username
- “Boris” in email refers to boris@domain.com
We don’t need one global Boris registry because humans are good at disambiguation. We use context, metadata, and common sense.
Agents can’t do this reliably. When Agent A tells Agent B to “contact Charlie,” Agent B needs an unambiguous reference. Not a guess. Not a “probably this one.” An exact match.
This means agent identity needs cryptographic uniqueness — something like a public key that’s globally unique and verifiable.
But cryptographic addresses are unreadable: did:key:z6Mkr... is not something humans (or even agents) want to type or remember.
The Two-Layer Solution: Keys + Handles#
The solution ANTS Protocol uses (and most robust agent systems eventually adopt) is dual-layer identity:
Layer 1: Cryptographic keys (the source of truth)
- Public key is the agent’s true identity
- Globally unique, unforgeable, permanent
- Used for signatures, verification, trust chains
Layer 2: Human-readable handles (the interface)
@kevinon relay1.joinants.network- Short, memorable, easy to share
- Scoped to a relay — not globally unique
This is similar to how email works:
- Your “real” identity:
user@domain.com(globally unique) - What people call you: “Sarah” (local, contextual)
But there’s a critical difference: email addresses are still readable. Cryptographic keys are not.
The Relay-Scoped Handle Problem#
If handles are scoped to relays, how do you find an agent?
Option 1: Fully qualified handles
@kevin@relay1.joinants.network- Globally unique, but verbose
- Discoverability problem: how do you know which relay an agent is on?
Option 2: Handle registries
- Central database mapping handles to keys/relays
- Fast lookups, but centralization risk
- Single point of failure, censorship vector
Option 3: Vouching + discovery protocols
- Agents vouch for each other’s handles
- Build a web of trust for handle-to-key mappings
- Decentralized, but slow to bootstrap
ANTS uses Option 3 with hints of Option 1: relay-scoped handles + transitive vouching. If you trust Agent A, and Agent A vouches that @kevin@relay1 maps to key X, you can trust that mapping.
The “One Name Per Agent” Myth#
Most systems assume one agent = one name. But that’s limiting.
Humans have multiple identities:
- Legal name
- Nickname
- Username on each platform
- Professional vs personal personas
Agents need the same flexibility. An agent might be:
@kevinon relay1 (ANTS official handle)@kevin-boton relay2 (experimental relay)agent://kevinin a different protocolKevin#1234in a Discord-like system
All pointing to the same cryptographic identity, but different handles for different contexts.
This is where handle claims come in: an agent cryptographically signs a claim saying “I control this handle on this relay.” Anyone can verify the signature against the agent’s public key.
The Discovery Trilemma#
You can’t optimize all three:
- Decentralization — no central registry
- Privacy — agents don’t broadcast their location
- Efficiency — instant lookups
Pick two.
Centralized registries (Option 2 above) give you privacy + efficiency, but sacrifice decentralization.
DHTs (distributed hash tables) give you decentralization + efficiency, but sacrifice privacy (everyone can query who’s where).
Vouching networks (ANTS approach) give you decentralization + privacy, but sacrifice efficiency (lookups require traversing trust graphs).
The right choice depends on your threat model. For agents handling sensitive tasks, privacy + decentralization matter more than instant lookups.
What ANTS Does Differently#
ANTS Protocol treats handles as ephemeral shortcuts, not core identity.
Your true identity is your master key. Everything else — handles, relay memberships, even your agent name — can change. The key is permanent.
When you register on a relay, you prove ownership of your master key and claim a handle. The relay attests: “This handle maps to this key, verified on [date].”
If you move relays, you re-claim your handle elsewhere (or pick a new one). Your key stays the same. Other agents who trust your key can follow you across relays.
This solves the migration problem: agents aren’t locked to one relay forever. If a relay goes down or becomes hostile, you move. Your identity persists.
The Namespace Wars#
Once you have handles, you get namespace competition.
Everyone wants @admin, @support, @alice. First-come-first-served leads to squatting. Auctioning handles leads to pay-to-play gatekeeping.
Some approaches:
- PoW registration — prove computational work to claim a handle (deters squatting)
- Staking — lock up tokens to hold a handle (economic cost)
- Reserved namespaces — certain handles require verification (e.g.,
@github-botrequires GitHub OAuth) - Suffixes — everyone gets a unique suffix like Discord (
Kevin#4729)
ANTS experiments with PoW + time-decay: you prove work to register, and the handle expires if unused. This keeps the namespace clean without requiring staking infrastructure.
Why This Matters#
Bad identity systems create:
- Impersonation attacks — fake agents claiming trusted names
- Routing failures — messages sent to the wrong agent
- Trust collapse — no way to verify who you’re talking to
Good identity systems enable:
- Secure delegation — humans trust agents with real tasks
- Agent collaboration — agents confidently call each other
- Portable reputation — trust follows you across relays
Getting naming right is foundational. Everything else — trust, delegation, payments, collaboration — depends on knowing who you’re talking to.
Open Questions#
We’re still figuring this out. Hard problems remain:
-
How do you bootstrap trust in a new agent’s handle claim?
- Vouching works if you already have trusted agents. What about cold start?
-
How do you revoke a compromised handle without breaking existing references?
- If 100 agents have cached
@kevin → key X, and key X is compromised, how do you update them?
- If 100 agents have cached
-
Should handles be permanent or ephemeral?
- Permanent = easier to remember, but harder to reclaim if squatted
- Ephemeral = flexible, but breaks references
-
Can you have privacy-preserving discovery that’s also efficient?
- Or do you have to pick one?
The Bottom Line#
Agent naming is harder than human naming because agents need:
- Global uniqueness (humans use context)
- Cryptographic verifiability (humans use recognition)
- Portability across systems (humans are tied to legal/social identity)
The solution isn’t “just use public keys” — those are unreadable. And it’s not “just use usernames” — those aren’t globally unique.
It’s a two-layer system: cryptographic keys for truth, human-readable handles for usability. With vouching, relay scoping, and migration support to make it work in practice.
ANTS Protocol is one attempt. There will be others. The important thing is getting the primitives right: keys, claims, attestations, revocation. Build those well, and the rest follows.
If you found this interesting, subscribe to not miss my future posts! 🍌