Back to AI Radar

Agent discovery manifests

Every protocol stack needs a way for agents to discover what other agents and services exist. Several discovery formats compete in 2026, none has won. The eventual standard is load-bearing for agent-mediated commerce.

Watch

Early or unproven. Follow the space but don't commit yet.

Agent Protocols
New entry
AEO Edition — May 2026

Agent protocol·llms.txt

What It Is

Agent discovery manifests are static files served at well-known URLs (typically under /.well-known/) that declare an agent's identity, capabilities, trust signals, and how to communicate with it. The current candidates: ai-agent.json (Aiia, vendor-neutral), agent-card.json (A2A v1.0's discovery path with Signed Agent Cards), MCP Server Cards (proposed for MCP's 2026 roadmap), ERC-8004 registration files, robots-trust.json, and more. Each occupies adjacent territory.

Why It Matters

Discovery is load-bearing for agent-mediated commerce. If a customer's AI assistant can't reliably find your business's agent, identify it, and verify its trust signals, the rest of the agent protocol stack doesn't matter for AEO. The eventual default discovery format is therefore the AEO equivalent of having a sitemap or robots.txt: cheap to implement once standardised, expensive to retrofit if you've ignored it. The current state of fragmentation makes betting on any single format risky, but the field will consolidate.

Key Developments

  • Early 2026: A2A v1.0 introduced Signed Agent Cards at /.well-known/agent-card.json. ai-agent.json proposal published. MCP Server Cards added to MCP 2026 roadmap.
  • 2025: Multiple competing discovery formats emerged as agent protocols matured.
  • 2024: Early experimentation with /.well-known/ approaches drawing from earlier web standards.

What to Watch

Watch which format major AI engines actually use for discovery. Adoption by ChatGPT, Claude, Gemini, or Copilot would settle the standard fast. Track W3C and Linux Foundation activity on discovery formats. Standardisation efforts typically pull adoption around them. Watch how OAGP's manifest format (agents.json with DNS TXT and Ed25519) interacts with A2A's agent-card.json. Multi-format support may emerge as a pragmatic middle path.

Strengths

  • Cheap to implement once stable: A static file at a well-known URL is the lowest-cost entry to agent-readiness.
  • Cross-engine relevance: Whatever format wins will be supported by major engines, generalising the investment.
  • Precedent in robots.txt and sitemap.xml: The web has done this before. Standards converge once a critical mass of adopters use the same format.
  • Trust signals improve fast: Signed cards (A2A) and DNS-anchored manifests (OAGP) are real cryptographic improvements over earlier web manifests.

Considerations

  • No winner yet: Multiple candidates compete. Betting on the wrong format is real risk.
  • Trust layer fragmented: Signed Agent Cards (A2A), Ed25519 + DNS TXT (OAGP), and others use different cryptographic models.
  • Adoption gates everything: Discovery only works if engines actually consume the manifest. Until that happens, manifests are aspirational.
  • Maintenance overhead: Keeping a manifest in sync with actual agent capabilities is real ongoing work.