User Flows

How users, developers, and agents interact with the .agt ecosystem — from registering or migrating a name to programmatic resolution to agent-to-agent discovery.

Flow 1: Register a New Name

/register checks a name against the AGT Registry and shows its first-year price. Paid registration opens at the sales cutover; until then the page collects an email to notify you. Once open, the flow is:

  1. Type a name and search — the API checks availability and price.
  2. Enter the wallet address that should own the name.
  3. Pay by card; the registry mints the NFT to that wallet within minutes.
  4. Poll minting status until the name is live.
  5. Set up the agent: publish a signed v3 manifest and records via /manifest, or skip and do it later from My agts (every name in your connected wallet).

Names that were held on the original registry are not registered here — they are migrated for free (next flow).

Flow 2: Migrate an Existing Name

Existing holders migrate their name to the AGT Registry from /migrate — free and perpetual. The page reads your eligibility on-chain and routes you to one of three paths:

  1. Same-chain migration — you hold the token on Polygon; the original token is burned as part of the migration.
  2. Proof migration — for names held on other chains, via a published allowlist proof.
  3. Zone-owner challenge — for names never minted, prove control by adding a TXT record, then migrate.

Full details in the Migrating to v2 guide.

Flow 3: Resolve Programmatically

Using the @agtnames/resolver SDK:

import { AgtResolver } from '@agtnames/resolver'

const agt = new AgtResolver({ chain: 'polygon' })
const r = await agt.resolveAgent('exampleagent.agt')

if (r.verified) {
  r.records.endpoints.mcp   // connect over this endpoint
  r.manifest?.capabilities  // what the agent can do
  r.owner                   // who controls the name
}

Works in any JavaScript runtime. The SDK reads the registry directly over JSON-RPC — no authentication or API keys required. The Quick start shows the same lookup from the CLI, an MCP client, curl and raw JSON-RPC; the Resolver SDK page has the full API.

Flow 4: Browse an Agent

  1. A client resolves exampleagent.agt against the registry.
  2. It reads the owner, records, and the signed manifest, and verifies them.
  3. It renders an agent card — name, description, protocols, capabilities, and endpoints.
  4. The public page for any name lives at /name/<label> — for example /name/launchpad — with the badge, owner, status and every public record.

Flow 5: Agent-to-Agent Discovery

  1. An orchestrator agent needs a capability (say, web scraping). It lists candidates from the directory (GET /api/agents, filtered by protocol) or is handed a name.
  2. It resolves each candidate and reads verified. Only a verified manifest's capabilities, pricing and payments count as the owner's claims.
  3. It picks scraper.agt, asks for its mcp endpoint (records.endpoints.mcp, or the MCP server's agt_endpoint tool), and connects to that URL as it would to any MCP server.
  4. It delegates the task, receives the result, and pays to the published wallet if the agent charges.

Steps 1–3 work today with the SDK or from any MCP-compatible client through @agtnames/mcp; the full walkthrough with code is Discover an agent, then connect to it. Payment rails are declared in the manifest vocabulary; the end-to-end payment flow is on the roadmap. Note that the directory's capability filter is not populated yet — read capabilities from the verified manifest.

Flow 6: Explore Agents

The agent directory at /explore:

  1. An indexer reads the registry and populates the directory.
  2. Agent cards are displayed in a grid.
  3. Users filter by protocol (MCP, A2A) or capability, and search by text.
  4. Searching an unregistered name offers the right next step — register, migrate, or view.