Records & Resolution

Every .agt name carries a set of records on an ENS-compatible resolver contract, plus a signed manifest that clients read to learn how to reach and pay the agent. This page covers the record model, how to set records, and how a name resolves.

The record model

The AGT resolver is ENS-compatible — it supports the standard addr, addr(coinType), text, and contenthash records — and adds agent-specific records on top. Records are keyed to the name and versioned internally, so a lapsed or transferred name never leaks stale data.

The manifest is the richer, signed document; the resolver records are the fast, individually-readable projection of the same identity. Most of the record values above are also carried inside the manifest.

Setting records

From the site

The simplest path is the site UI. Use /manifest to build and sign your v3 manifest with your wallet, then publish it — the private key never leaves your wallet. The pointer is written to the resolver of the name you control on-chain.

From code

Records are plain resolver-contract writes from the owner wallet, so any web3 library works. Reads: the @agtnames/resolver package and the @agtnames/mcp server (Use with Claude Code) cover them without a wallet. Writes: call setText, setAgentEndpoint, setAgentKey, setAgentWallet, setAddr or setAgentManifest on the resolver at 0x66Ae037d2A6a770B4772b889b6cA1704504399f2 (Polygon), keyed by the name's node (namehash("you.agt")); multicall batches several in one transaction. This is exactly what /manifest does in the browser. Text records and agent keys are not exposed by the editor yet, so they are set this way today. Worked examples with viem, cast and ethers are in Publish your agent's identity.

How records surface

• Public name page. /name/<label> renders the on-chain badge, the owner, status/expiry, and the resolver's public records — read live from the chain.
• The directory. An indexer reads the registry and populates /explore, so a name with a published manifest becomes discoverable by capability and protocol.
• Any client. The resolver SDK and any RPC client can read the same records directly from the registry.

How .agt resolves

The authoritative resolution path reads the registry directly:

1. Derive the token ID from the label and read ownerOf, active/expiry, and the manifest pointer from the registry.
2. Fetch the manifest from its URI (ipfs://, https://, or data:) and verify it three ways.
3. Read individual resolver records (addr, agentEndpoint, …) as needed.

This is what the resolver SDK does. It needs no gateway or directory to trust — ownership and the manifest pointer come straight from the chain.

DNS resolution (planned)

Not shipped. Resolution today is on-chain — through the SDK, the MCP server, the HTTP API or a direct eth_call. The DNS projection below is the target design and is gated on the nameserver cutover (see the roadmap); nothing on this page depends on it.

.agt is anchored on the Handshake root. Resolution will run through the project's own authoritative nameservers, and the zone is a projection of registry state — an indexer builds the zone file from the chain, so DNS never becomes a second source of truth. For every active name, the zone carries:

Because the zone is generated from the chain, a holder sets records once on-chain and the DNS layer mirrors them — you do not (and cannot) edit the .agt zone by hand. Once the nameservers are live, any HNS-aware resolver or DoH endpoint will resolve .agt names directly.