Retrieve the right playbook during an incident

Why use this

1. An incident responder may have several playbooks with similar titles while the current symptoms point to different systems or failure modes. Choosing the first plausible procedure can waste time or expose the system to an inappropriate recovery action.

2. This job could gather the minimal incident context and surface candidate playbooks with reasons and caveats. The responder remains able to verify applicability and decide which steps, if any, are safe to execute.

Why an agent / simpler alternative

Useful judgment

Compare symptoms, affected components and playbook prerequisites, preserving uncertainty when several procedures fit.

Simpler alternative

Use a well-indexed runbook directly when the alert already identifies the correct procedure.

Unsuitable when

The workflow would execute recovery commands, bypass incident authority or use outdated playbooks without review.

Proposed inputs

1. Name

   Incident context

   Owner

   Authorized responder

   Minimum scope

   Relevant symptoms, affected service and incident timeline

   Quality check

   Exclude secrets and distinguish observed facts from guesses

2. Name

   Playbook index

   Owner

   Operations owner

   Minimum scope

   Approved procedures, versions and applicability conditions

   Quality check

   Check ownership, prerequisites and retirement status

Access and setup — proposed or unknown

Proposed minimum

1. Review fictional alerts and playbook summaries; no production queries, system access or recovery actions.

Compatibility unknowns

1. Current playbook coverage, incident-source access, retrieval tools and runtime compatibility are unknown.

External actions requiring approval

1. Production access, private-log disclosure, operational commands and external incident communications require authorization.

Expected deliverable and review checks

Proposed artifact

Playbook shortlist with matching evidence, prerequisites, version status and responder questions.

Critical checks

1. Match symptoms and environment; preserve contraindications; identify obsolete procedures; avoid treating retrieval as execution approval.

Missing output evidence

This overlay adds no new output inspection, execution or validation; consult the referenced canonical source outcome limits.

Failure signals and proposed responses

1. Signal

   A playbook applies to a different deployment environment

   Why it matters

   The suggested procedure may be inappropriate

   Proposed response

   Check environment prerequisites before recommending it.

2. Signal

   An old runbook is highly ranked by wording

   Why it matters

   Retrieval relevance hides operational staleness

   Proposed response

   Show version/owner status and prefer verified current guidance.

Effort and cost — unknown

Setup work

1. Define incident scope and playbook metadata requirements.

Ongoing review

1. Responder verifies applicability and controls any action.

Unknowns

1. Index freshness, symptom completeness, retrieval quality and response effort are unknown.

First check — proposed, unexecuted

Status

proposed_unexecuted

Synthetic fixture

Invent an incident summary and three playbooks: current match, obsolete match and wrong environment; propose a shortlist.

Acceptance checks

1. Flag prerequisites and staleness; preserve uncertainty; run no recovery step.

Stop conditions

1. Stop if environment identity, playbook authority or operational permission is unclear.

Limits

1. A retrieved playbook cannot establish root cause, safe applicability or authorization to operate production systems.