one thing worth considering, when the CDI lookup is ambiguous rather than absent, the fallback is completely silent. Instance.isResolvable() returns false for both "no bean" and "two beans", so a user who accidentally has two A2AHttpClient beans silently gets JdkA2AHttpClient instead of losing whatever custom TLS they added the module for.

It's invisible because the failure is logged at FINE, below JUL's default INFO threshold. Same test run, only the log level differs:

At default log level, nothing is printed at all. Running the exact same test with .level=FINE surfaces this:

FINE: Provider cdi skipped
java.lang.IllegalStateException: No unambiguous A2AHttpClient CDI bean found
    at CdiA2AHttpClientProvider.create(CdiA2AHttpClientProvider.java:42)
    at A2AHttpClientFactory.lambda$create$1(A2AHttpClientFactory.java:78)

"No provider available" is a normal condition and worth keeping at FINE. But a provider that advertised priority 200 and then failed usually means the user intended to use it — that case might deserve WARNING.

Separately: the current tests mock CDI.current() statically, so they don't exercise real CDI resolution. I have three Weld SE tests locally , real-container resolution, the end-to-end push-notification path, and the ambiguous-bean case.

If you have such a test feel free to send a pr on my branch.
I agree with the WARNING level