Shouldn't AgentCard.url be optional for Well-Known URI Discovery?

[tiswanso]

Hi A2A-folks!

In digging in a bit on the sample agent implementations I noticed AgentCard.url is a required attribute. For the Well-Known URI discovery use-case, this looks like it requires an endpoint workload (A2A server) to know the public details of how it's hosted which I'd consider an anti-pattern for public service hosting.

Could the semantics be changed to something like step 4 below (my edit)?

Process:

1.  A client agent knows or programmatically discovers the domain of a potential A2A Server (e.g., smart-thermostat.example.com).
2.  The client performs an HTTP GET request to https://smart-thermostat.example.com/.well-known/agent-card.json.
3.  If the Agent Card exists and is accessible, the server returns it as a JSON response.
4.  If the Agent Card `url` parameter is present, the client uses the URL for further interaction with the agent, otherwise, the client continues to use the domain of the well known URI.

Client SDKs supporting step 4 semantics would make the Well-Known URI discovery method much more realistically usable for simple hosting using typically existing workload deployment methods.

The issue that I see is that requiring agent instances to return AgentCard's with URLs that clients should use is that it makes it more complicated to develop and release agent implementations to other organizations. Those that handle the workload hosting and tie in via existing service exposure mechanisms would not typically have to handle configuring workload level configuration with information only available in the hosting platform runtime. Also from an agent developer standpoint, this service discovery tie-in requires the agent endpoint implementation to be configurable at runtime to be able to build the AgentCard.url value. The hosting platform operations would have to provide the endpoint URL constituent information in the agent implementation-specific way.

The alternative is to bring in a whole extra agent registry type of service that allows mapping custom URLs to agent instances in order to serve Agent Cards to clients that are different than what the individual agent endpoints respond with, ie. something that mutates AgentCards returned from agent instances.

I think a somewhat related past discussion: #166

[tiswanso]

The example that I was looking at getting working is deploying multiple helloworld agent instances as different agent services in a k8s cluster. I am exposing them via an ingress gateway (& loadbalancer) behind different URL paths. The configuration for the request routing to agent service is via the gateway-api CRDs.

Normally, with other workload types that's where it ends. I just point the service clients at the domain + URL path of the ingress gateway + service.

However, with A2A agents, I need to

1. modify the helloworld agent to allow getting configured with the info to build the AgentCard.url: https://github.com/tiswanso/a2a-samples/blob/fix-helloworld-container-hosting/samples/python/agents/helloworld/__main__.py#L18-L30

2. deploy the agent instances in k8s with the configuration set for the URL of the domain for the ingress gateway + URL path configured in the gateway-api CRDs. In this case AGENT_HOST, AGENT_PORT, and AGENT_PATH env variables.