Initial public draft of Agent Discovery Exchange (AX)

[sempfa]

Autonomous AI agents increasingly operate across organizational and administrative boundaries. However, there is no standardized, internet-native mechanism for discovering agent endpoints, understanding their capabilities, or negotiating supported interaction protocols.

This document defines Agent Discovery Exchange (AX), a lightweight, protocol-agnostic discovery mechanism that enables agents to advertise their capabilities and supported interaction protocols using existing DNS and HTTPS infrastructure. AX is designed to complement — not replace — existing agent execution and communication protocols such as GraphQL, MCP, A2A, and REST.

---

This discussion was created from the release Initial public draft of Agent Discovery Exchange (AX).

[walmsles]

The biggest problem in scaling agents globally is discovery, and it needs to be simple, effective, open, and available for all.
I like the format of the Agent Exchange draft—it's less exchange and more discovery, which is critical to global adoption.

Agent exchange projects are starting to pop up as central registries for agent discovery. This fragments discovery further and means organisations will need to interface with multiple exchanges, adding friction to agent adoption.

What we need is an open implementation that anyone can adopt—one that does, at its core, what the draft embodies. This is the only way agents will be freely discoverable across the globe.

Corporate exchanges for monetisation will come, but they should build on top of an open discovery protocol rather than replace it.

This is why I am building Open-tethyr

[sempfa]

I think you’ve articulated the core risk very clearly.

As soon as discovery becomes something that lives inside exchanges rather than beneath them, fragmentation is inevitable. Every new registry becomes another onboarding surface, another integration, another implicit gate. That friction doesn’t just slow adoption; it quietly shapes who gets to participate.

That’s exactly why AX is intentionally framed as discovery, not an exchange. The goal is to standardize the lowest common denominator: how agents advertise existence, capabilities, and supported interaction protocols in a way that is open, crawlable, and internet-native. Once that substrate exists, many coordination and monetisation models can coexist on top of it.

In that sense, work like Open-tethyr feels like a natural downstream layer. An open tethering or coordination exchange that consumes open discovery signals is very different from a registry that replaces them. The former compounds openness; the latter competes with it.

I also agree that what ultimately matters is not just a draft, but open implementations that people can actually adopt. Specifications create alignment, but running systems create gravity. Seeing open projects explore how discovery feeds coordination is exactly the kind of validation this space needs.

If we get the layering right, open discovery first, optional exchanges and monetisation second, we avoid locking the global agent ecosystem into a handful of chokepoints before it’s even had a chance to form.

Appreciate you sharing the motivation behind Open-tethyr; this feels like a productive direction for the ecosystem to explore.

[walmsles]

The draft specification references the RFC8615 standard path for /.well-known/agent_exchange.json and then requires using _agent.<domain> as the DNS endpoint for discovery. This appears to deviate from RFC 8615 conventions.

Existing well-known URIs follow the RFC8615 pattern:

https://example.com/.well-known/security.txt
https://example.com/.well-known/openid-configuration
https://example.com/.well-known/webfinger

Defining _agent.<domain> is an additional configuration step beyond hosting the JSON discovery file, adding extra work for larger organisations. The _ prefix is usually reserved for DNS Service style records (SRV, DKIM, DMARC), not web endpoints.

If the intent is to align with RFC 8615, the standard path would be https://<domain>/.well-known/agent-exchange.json.

Is there a specific architectural requirement driving the _agent subdomain prefix?
Is there an intent to register and claim the agent-exchange.json as a formal component of this draft?

[sempfa]

Great catch! and I agree the current wording risks mixing two conventions.

RFC 8615 defines a standardized, server-wide location under /.well-known/ for machine-readable metadata. If we want AX to “feel” like OIDC discovery, WebFinger, security.txt, etc., then the default SHOULD be exactly what you suggested: a well-known HTTPS resource on the apex host, e.g. https://<domain>/.well-known/agent-exchange (or agent-exchange.json, depending on the chosen naming).

The _agent.<domain> form was not intended to be “web endpoint naming” so much as an optional indirection mechanism. The motivation was to allow organizations to decouple “brand / corporate domain” from “agent discovery host” and support cases where discovery metadata is served from a dedicated host, separate zone, or different infrastructure boundary, without requiring changes to the apex site or web stack. That said, I agree that using an underscore label is strongly associated with DNS-specific records and can be confusing when the target is ultimately an HTTPS retrieval.

So I think there are two clean options, and the draft should be explicit about them:

The normative baseline is RFC 8615 well-known HTTPS discovery on the apex (/.well-known/agent-exchange[.json]), with no additional DNS configuration beyond what the domain already has.

Optionally, the draft MAY support DNS indirection for advanced deployments, but it should use a mechanism that matches DNS conventions (e.g. _agent as a service label only when used with a DNS record type intended for service discovery, or an explicit delegation record), and the draft should clarify it is not required for compliance.

---

On registration: yes, if we proceed with the well-known path as the primary mechanism, the draft should treat that as the canonical discovery location and, separately, register the media type for AX documents. Registering agent-exchange as a well-known resource name can also be considered, but it’s a step we should take only once the path is stable and we’ve seen implementation experience.

Net: I agree with your interpretation. I’ll propose updating the draft so RFC 8615-style /.well-known/ is the default, and any DNS-based indirection is clearly optional and uses DNS-appropriate semantics.