Proposal: Connector/Resolver abstraction for agent discovery mechanisms

[ognis1205]

Following up on the ongoing discovery discussions:

• Agent Registry - Proposal #741

I'd like to propose an abstraction that could help us unify different approaches. Right now, we have .well-known/agent-card.json as recommended in the spec, but in practice we're already seeing variations like IETF API Catalog, ORD, or registry-based discovery (including already-implemented external services and/or OSS) mechanisms.

To avoid hardcoding just one option, I suggest introducing a Connector/Resolver API for discovery.
This would allow us to support multiple discovery mechanisms in a vendor-neutral way, while keeping the SDK surface consistent.

For example, we could define pseudo-schemes that internally resolve to the appropriate HTTP endpoints and dispatch to the corresponding connector/resolver:

a2a+wellknown://example.com -> https://example.com/.well-known/agent-card.json  
a2a+apicatalog://example.com -> https://example.com/.well-known/api-catalog  
a2a+local://cache/registry.db -> file://${XDG_CACHE_HOME:-~/.cache}/a2a/registry.db

In this model, the connector/resolver would effectively expose the Registry API discussed in:

• Agent Registry - Proposal #741

at the SDK level, implementing the corresponding API behavior based on the underlying discovery mechanism. Each connector/resolver would expose a common set of capabilities (e.g. resolve_agent, search_agent), returning not supported where the backend doesn't provide that feature.

This way, we don't have to "pick a winner" right now — SDKs can implement the abstraction once, and then support whichever discovery mechanisms the community agrees on over time. Would this be a reasonable direction to explore further?