A2A · INTERACTIVE DISCOVERY
Agent Card discovery: invalid and unavailable cards
Follow the request, inspect the card, and see exactly why discovery succeeds or stops.
Scroll the discovery diagram horizontally to read every stage. The event list and statistics give the same state as text.
Try this experiment
Inject a 404, malformed JSON and an insecure interface. Find the exact stage that rejects each case.
- Play the healthy sequence. Follow the blue request marker.
- Change one input; the preview and sequence recalculate immediately.
- Use Next event or scrub the timeline to inspect the branch.
- Capture a baseline and record what changed.
Discovery trace
Offline teaching model, not a live benchmark or complete A2A implementation. Five sequential attempts; fixed round-trip time; a modeled 1,200-byte card; no retries or task execution. Validation represents JSON parsing, a client HTTPS policy and one capability check—not full schema or signature verification. Credentials are simulated booleans; never enter real secrets. Discovery of a card does not authenticate subsequent task calls. Official discovery and caching reference.
Five discovery attempts against one endpoint
A client looks for an agent five times, six model seconds apart. Each attempt either uses a fresh cached Agent Card or sends GET /.well-known/agent-card.json, waits the Network round trip, validates the response and then checks whether the card meets the client requirement. With a healthy endpoint, a ten-second Cache max-age and card version 2 published at twelve seconds, three network fetches and two cache hits produce five accepted selections: v1, v1, then v2 three times. One fetch is a 304 Not Modified response that refreshes the cached v2 card instead of downloading it again.
Unavailable cards stop discovery
Choose 404: card not found or 503: service unavailable in Endpoint / card condition. All five attempts reach the network and all five are rejected: there is nothing to cache and no agent may be invoked. Choose 401 unless credentials supplied and the same happens until Supply discovery credentials is enabled, after which the run matches the healthy one. The model does not retry within an attempt, so each failure is visible as one rejected discovery.
Invalid cards are never cached
Choose Malformed JSON. Each attempt downloads 1,200 modeled bytes, fails parsing and is rejected, so after five attempts 6,000 bytes have been transferred for nothing. Raise Cache max-age to thirty: nothing changes, because a card that fails validation is not stored. Non-HTTPS advertised interface behaves the same way under the client HTTPS policy. A valid but unsuitable card is different: keep a healthy endpoint, require streaming and clear Card advertises streaming. The card is fetched and cached, but all five selections are rejected for capability.
Caching inputs
Cache max-age zero makes every attempt go to the network; three of them become 304 responses. Thirty seconds lets one fetch serve all five attempts, so all five use v1 even after v2 is published: a long cache trades freshness for fewer requests. Clearing Publish card v2 at model time 12s keeps v1 throughout. Client requires streaming expresses a local requirement. Discovery interval and Network round trip change the timeline but not the decisions. Restore defaults resets every input.
Playback and limits
Play, Pause, Next event, Restart, Speed and Inspect any moment show the request, cache, validation and selection stages over the run. The model does not validate the full Agent Card schema, signatures, Extended Agent Cards or redirects, and it has no retries, backoff, DNS or TLS failures. Discovery ends with a selected card; any task call afterwards would need its own authentication and error handling.