Start with `to_a2a()`. The helper writes the process bind address into the card's `supportedInterfaces` block [10]. On Cloud Run the container binds `0.0.0.0:8080`, so the published card offers exactly one route to the agent, and that route is `http://0.0.0.0:8080` [9][10]. 0.0.0.0 is a reasonable thing to bind and a poor thing to dial. The card itself came back over HTTPS on the service hostname, gated by `roles/run.invoker` at the Google Frontend [8], which means the client already holds the only address that works. The field whose job is to name the transport is the field it has to discard.
That matters because the card is the only artifact a client reads before it commits to a runtime [3]. Path handling adds its own tax. The spec puts the card at `/.well-known/agent-card.json` and keeps `/.well-known/agent.json` as the older path [4]. Six targets in the mesh [2], and a client that cannot assume which path a given vendor serves, is twelve requests before anything useful happens [16].
The permission model splits the same way. By the writeup's count, two of the three clouds do not let you issue a read-only discovery credential at all [17]. That is why the sample attaches the credential to the `httpx` client rather than to the invocation it is preparing: the card fetch is its own authenticated request, not a side effect of the call downstream [7].
Treat the field table as a measurement of one mesh on one day. The results are dated 2026-08-25 [2], and the environment is deliberately unpinned, with no virtualenv, running a2a-sdk 1.1.2, google-adk 2.6.3, httpx 0.28.1 and starlette 1.3.1 on Python 3.13.14 [12]. For the `0.0.0.0` finding to transfer to your deployment, you need the same `to_a2a()` code path, the same bind, and no proxy rewriting the interface URL on the way out. Bump the SDK minor and you are running a fresh experiment, not reading this one.
Two pieces of the harness are worth copying regardless of what your cards say. The local mesh script checks that its own child process survived rather than that something answered on 11001, 11002 and 11003, because sharing a port range with another project hands you three healthy agents and a comparison of the wrong ones [15]. And the whole suite is hermetic: 125 tests in 0.52 seconds, with ruff clean [13]. Those are the two failure modes a live cloud will not reproduce for you on demand, and both are cheap to encode now.
In my context, the ordering I would ship is: fetch the card, store the exact bytes, and route on the hostname that answered rather than the URL the card advertises. Storing the bytes is what makes the divergence auditable later [1]; the alternative is arguing about what a vendor published three weeks ago. If a future SDK stops leaking the bind address, that policy costs nothing and you delete a line.
