Agent Discovery Mechanisms

The A2A Protocol standardizes the data format shared during the discovery process via the AgentCard. However, the specific methods for discovering these AgentCards are diverse and remain an open topic for discussion.

Here are the main discovery mechanisms currently envisioned:

Open Discovery

We recommend that enterprises host their AgentCards under their service domain, following a “.well-known” path convention:

https://<DOMAIN>/.well-known/agent.json

Clients can find known or discoverable domains via DNS resolution and then obtain the AgentCard by sending a simple HTTP GET request to this path.

This approach allows web crawlers and applications to easily discover Agents for known or configured domains, effectively simplifying the discovery process to “finding the domain.”

Example Request

curl https://example.com/.well-known/agent.json

Example Response

{
  "name": "ExampleAgent",
  "description": "This is an example Agent",
  "url": "https://example.com/agent",
  "provider": {
    "organization": "Example Org",
    "url": "https://example.com"
  },
  "version": "1.0.0",
  "capabilities": {
    "streaming": true,
    "pushNotifications": false
  }
  // ... other AgentCard fields
}

Curated Discovery / Registry-Based

It is foreseeable that enterprise-level applications will provide curated Agent registries through directory interfaces. This will support more enterprise scenarios, such as company-specific or team-specific Agent registries maintained by administrators.

The community is considering whether to add registry support to the protocol standard. Your opinions and ideas are welcome.

Private Discovery / API-Based

Undoubtedly, private “Agent stores” or proprietary Agents will emerge, exchanging their AgentCards via custom APIs.

Currently, private discovery APIs are not considered a problem that the A2A Protocol itself needs to solve. If you believe standardizing them would be valuable, your input is also welcome.

AgentCard Security

AgentCards may contain sensitive information. Implementers can choose to protect their AgentCards using access control, requiring authentication and authorization.

For example, within an organization, even open discovery following the .well-known path can be protected via mTLS and restricted to specific clients. Registries and private discovery APIs should require authentication and return different content based on varying identities.

Important Note: Implementers might include credential information (like API keys) in the AgentCard. It is strongly recommended never to expose this information without authentication.