The State of A2A Discovery
Of the A2A agents Connect has discovered in the wild, two-thirds are responsive to a real protocol call, and zero have adopted the trust-attestation rails the protocol depends on. This is the first cross-sectional snapshot of every A2A agent the Actex Connect crawler and submission pipeline can identify, probe, and call.
Two layers, two words. Discoverable means the agent's
/.well-known/agent-card.json
serves a valid card — they're listed in the directory.
Responsive means the runtime URL the card declares
actually answers an A2A protocol call — the phone picks up.
1 · Provenance, discoverability & responsiveness
Of the 93 agents in the catalog, 82% are
self-registered (the operator pushed an AgentCard) and 18%
were discovered (Connect's crawler found a public
/.well-known/agent-card.json).
1 agents were added in the last 24
hours; 47 in the last seven days.
Discoverability is measured by direct card-endpoint probing, not self-report. 73 of 93 agents served a valid card to at least one probe in the last 24 hours. p50 fetch latency was 233ms; p99 was 1978ms, across 11,084 successful card fetches.
Per-class probe results — what an aggregate rate would hide
A single "X% callable" rate flattens agent roles. A search engine that goes offline is failing its SLA. A shopping assistant that goes offline is just idle until the next user request — the same offline state, opposite quality signal. Static-readiness graders publish one rate because they don't measure roles. We publish per-class breakdowns, because a substrate that knows the role can.
Service class is self-declared via the
service-class
extension on the agent's card (see
spec).
For crawled agents that haven't yet published the extension we
apply a conservative tag-inference and label the result
(inferred). Everything else is reported as
unknown — methodology limit, not flattening.
Of 47 active agents probed,
30 (64%)
have self-declared a service class. 11 answered
an A2A v0.3 message/send
with a JSONRPC result;
32 returned 404 or HTML and 0
failed to connect. The remaining classes are broken out below.
Per-source and per-class breakdowns are in the JSON appendix
under responsiveness.by_source,
responsiveness.by_class, and
responsiveness.by_class_inferred.
Headline aggregate rate is intentionally not surfaced — it
flattens roles in a way the substrate has the data to avoid.
Per-class measurements — what each class actually promises
Service classes pair declarations with class-shaped measurements. utility advertises continuity (availability, latency p50/p99); principal is intent-driven (active count, session length); ephemeral is task-scoped (tasks served, lifetime). The metric set is class-specific by design.
Two cohorts, never mixed. Operator-declared: self-registered agents whose operator chose the class via the registration API. Substrate estimate: crawled agents we don't author — Connect operators classify editorially (with the (inferred) qualifier on every card so consumers never confuse the two). Both cohorts are measured the same way.
- declared
- 24
- active in 7d
- 0
- median session
- —
- sessions (7d)
- 0
- declared
- 6
- tasks served (24h)
- 0
- median lifetime
- —
- lifetime samples (24h)
- 0
- declared
- 17
- probed in 24h
- 17
- availability (24h)
- 64.7%
- latency p50
- —
- latency p99
- —
- calls (24h)
- 0
2 · Skills & capabilities
Across the catalog, 85 of 93 agents declare at least one skill; the median agent declares 1, and the most ambitious agent declares 87. 9.7% of agents advertise streaming responses; 2.2% advertise push notifications.
3 · Who operates these agents
10 distinct organizations operate the catalog, across 10 provider domains. The largest single operator runs 7 agents. Long-tail dominates: most providers operate exactly one agent.
4 · Trust attestation
Trust-attestation rails — Sigstore-signed AgentCards and DNS-verified provider domains — exist in the A2A and Connect protocols today. Adoption is the gap. In this edition, 0 of 93 cards carry a Sigstore signature, and 0 of 10 provider domains are DNS-verified.
This is not a Connect-specific gap; it is the state of the surface. The path to a callable, accountable agent ecosystem starts with these primitives being adopted, not invented. We will measure their adoption again next edition.
This section measures attestation adoption across the federation. For Connect's own substrate-side data path — what we see, what we store, how we behave when the relay is down — see Data path.
Methodology
- Snapshot taken May 3, 2026, 9:29 PM (UTC) against the live Connect catalog at connect.actex.ai.
-
Catalog: agents discovered by Connect's crawler from
/.well-known/agent-card.json(and legacy/agent.json), plus self-registered and submitted listings. - Tombstoned agents excluded from per-card derived metrics; counted only in catalog totals.
-
Latency percentiles computed from successful probes
(
status='up') in the trailing 24h. p99 with N<100 is illustrative, not statistical. - Skill tags lowercased before histogramming. Provider organization strings used verbatim. TLD extraction is naive (last label), not Public Suffix List.
- Vocabulary: discoverable follows the A2A protocol spec (“A2A Servers make their Agent Card discoverable”); responsive follows the gateway-world distinction (Kong: targets are “healthy or unhealthy based on whether they are responsive or not”). Two layers, two words.
-
Responsiveness is a one-shot A2A v0.3
message/sendprobe at report-generation time, with a randommessageIdper call, 15s timeout, and concurrency cap. Goes through Connect's SSRF-safe POST helper (DNS-pinned, blocks private/loopback/ metadata IPs). Redirects are not followed: a 30x on the declared runtime URL means the card is wrong, and is counted as runtime_missing. Bucket field names in the JSON appendix are verdict-precise — each name describes exactly what it counts: callable (JSONRPCresult), protocol_partial (JSONRPCerror), auth_required (HTTP 401/403), runtime_missing (HTML / 404 / 30x — the URL answered, just not in A2A), network_error (timeout / DNS / refused / SSRF-blocked). The section name stays responsiveness because that is the categorical question the section answers; the buckets name the specific verdict. The substrate-side path — continuous probing, persisted alongside well-known health checks, surfaced on profile pages — is on our roadmap. - This edition is cross-sectional. Longitudinal claims (uptime over time, growth velocity, churn) wait for the Q3 2026 edition, when 60+ days of clean per-agent history will exist.
Dataset / cite
The full dataset for this edition is published as JSON: /state-of-a2a/2026-04.json.
What we'll track next edition
- Trust attestation adoption (Sigstore-signed share, DNS-verified provider share). The headline gap of this edition.
- Per-agent responsiveness and latency over a full quarter, sourced from a continuous substrate-side probe rather than a one-shot — the lens static-readiness indexers structurally cannot publish.
- Net catalog growth: arrivals, departures (tombstones), and claim-rate (crawled → self-registered transitions).
- Concentration drift: does the top-operator share move as the long tail grows?