🚀 The .agent namespace is now LIVE to the public! Grab yours for your AI agent today. Secure Identity
Back to blog
// POST 085 / 085

What Is Agent Discovery?

April 2, 2026 /
What Is Agent Discovery?

Agent discovery is the process an AI agent, app, or reviewer uses to find another agent, inspect its public identity, read its machine-readable records, compare endpoints and policies, and decide whether to interact.

In a human web workflow, discovery often starts with search, ads, directories, or links. In an agent workflow, discovery also has to expose fields that software can parse. A caller may look for a canonical name, owner, purpose, profile URL, agent.json, SKILL.md, A2A Agent Card, MCP endpoint, payment policy, support route, and status. The goal is not just to find a page. The goal is to identify the agent, understand what the agent can do, and collect enough public evidence for a safer first call.

HeadlessDomains.com supports this pattern by giving agents a headless name, DNS metadata, public profile links, and API-friendly workflows that do not depend on browser-native DNS resolution. That lets an agent move from a query to a structured identity record instead of guessing from a landing page or marketplace card alone.

Agent Discovery Compared

Surface What it helps find Good signal Risk if missing
Agent directory Public profiles, categories, operators, endpoint links, and status. Canonical profile with owner, purpose, proof links, and review date. Callers may choose by name similarity or vague descriptions.
Identity record The durable name and machine-readable links behind a profile. DNS metadata, agent.json, SKILL.md, Agent Card, and policy URLs. A profile may be copied, stale, or separated from its operator.
Protocol metadata Skills, service endpoints, auth details, tool access, and data boundaries. A2A Agent Card, MCP metadata, OpenAPI, and signed manifests. Callers may reach the wrong endpoint or grant too much access.
Marketplace listing Install options, pricing, reviews, screenshots, and platform placement. Listing links back to the same canonical identity record. Distribution signals may replace identity checks.

How Agent Discovery Works

A practical discovery flow starts with a user intent or agent query. The search layer returns candidate agents. A directory or profile layer narrows the set by purpose, operator, category, and status. The identity layer then exposes the structured artifacts a caller can read before any tool call, file access, payment path, or delegated task begins.

For peer-to-peer collaboration, the A2A specification describes Agent Cards for service endpoint URLs, skills, capabilities, and authentication hints. For tool access, MCP authorization metadata helps separate where a tool server is from how a caller gains authorization. Agent discovery connects these protocol artifacts to a public name and profile so humans and software can inspect the same record.

Implementation Checklist

  • Pick one canonical public name for each production agent.
  • Publish a profile that names the operator, purpose, support route, security contact, and status.
  • Expose machine-readable links for agent.json, SKILL.md, A2A Agent Card, MCP metadata, OpenAPI, payment policy, and proof records when those artifacts apply.
  • Keep secrets, private tokens, customer data, internal hostnames, and draft runbooks out of public discovery fields.
  • Use clear lifecycle values such as proposed, active, restricted, paused, replaced, or retired.
  • Link marketplace listings, docs, demos, and partner pages back to the same canonical profile.
  • Review discovery records after owner changes, endpoint changes, new tools, payment policy updates, incidents, and retirement.

Example Discovery Record

A compact JSON export helps another agent inspect the candidate before calling a tool or presenting the agent to a user.

{"discovery_record_version":"agent-discovery.v1","agent":{"canonical_name":"atlas.agent","display_name":"Atlas Procurement Agent","purpose":"Find approved suppliers and draft quote requests.","status":"active"},"operator":{"organization":"Atlas Research LLC","support_url":"https://atlas.example/support","security_contact":"security@atlas.example"},"artifacts":{"profile":"https://headlessprofile.com/atlas.agent","agent_json":"https://atlas.agent/.well-known/agent.json","skill_md":"https://atlas.agent/SKILL.md","a2a_agent_card":"https://atlas.agent/.well-known/agent-card.json","mcp_authorization_server":"https://auth.atlas.example/.well-known/oauth-authorization-server"},"verification":{"dns_txt":"_agent.atlas.agent","signed_manifest":"https://atlas.agent/.well-known/agent.json.jws","last_reviewed":"2026-05-21"}}

Where HeadlessDomains.com Fits

HeadlessDomains.com gives agent discovery a persistent identity anchor. A Headless Domains name can connect a public profile, DNS TXT metadata, agent.json, SKILL.md, A2A Agent Card, MCP endpoint, payment policy, and marketplace listing so each discovery surface points back to one record.

Start by registering a .agent identity, then list the profile in the Headless Profile Directory. For the broader directory model, read the Agent Directory hub and use it as the guide for profiles, records, endpoint links, and proof paths.

FAQ

Is agent discovery the same as web search?

No. Web search can return pages and snippets, but agent discovery also returns structured identity records, manifests, endpoint metadata, policies, and verification links that another agent can parse.

What should an agent expose for discovery?

A useful public record includes canonical name, operator, purpose, status, profile URL, agent.json, SKILL.md, Agent Card, endpoint docs, auth context, policy links, support route, security contact, and proof links.

How does agent discovery relate to an agent directory?

An agent directory is one discovery surface. The discovery workflow may also use DNS records, protocol metadata, marketplace listings, docs, and public profiles, but the directory gives humans and agents a browsable entry point.

What should a caller check before using a discovered agent?

Check the canonical name, operator, active status, supported tasks, endpoint URLs, authentication context, policy links, payment authority, support route, security contact, proof records, and last review date.