What's in a Playbook, and How It Gets Used

June 20, 2026 · InfraScout Team

Every team has someone who knows how to review a domain controller properly. They know which checks come first, which numbers are worth worrying about, and which warnings are noise. A playbook captures that method so the AI follows it the same way every time, whoever asks and whenever it runs. This post covers what a playbook is made of, the three ways it runs, how it improves from one version to the next, and what makes one easy to follow.

A structured record, compiled into one document

A playbook is not a loose prompt. It is a structured record with a name, a display name, a version, and a status, and the platform compiles it into one Markdown document. That compiled document is what the AI reads when it fetches the playbook, so every section below ends up in front of the model in a predictable order.

The role comes first. It is a short profile rather than a single sentence. It states the function (what the playbook does), the domain (what it covers and what it deliberately leaves out), the expertise the AI should bring, the decision scope (how autonomous the run is and what, if anything, it may write), and the output (what it delivers, and in which language). A clear exclusion such as "certificate services are out of scope, hand off to the PKI playbook" prevents more drift than any amount of extra instruction.

The objectives follow. This is a short list of outcomes, each led by a bold verb phrase such as Establish a baseline, Identify deviations, or Find the cause, not just the symptom. The objectives describe what a finished run looks like. They are not steps.

The workflow: numbered checks with verdict rules

The workflow is the longest block and the part that does the work. It is split into phases. In a typical health check, Phase 0 discovers the targets and their roles, the numbered check domains (HD-1 through HD-10, say) run the actual checks, optional deep domains go further when something warrants it, and a final phase rolls everything up into the report.

Each check domain answers three questions: what to do, how to judge the result (OK, WARN, FAIL, or N/A, with thresholds), and what to investigate when the result deviates. Here is an invented example for a mail server:

### HD-3 Mail queues

**Do:** Read the length and age of every transport queue on each
mailbox server. Read again after 60 seconds.

**Verdict:**
- OK: all queues under 50 messages, oldest message under 10 minutes
- WARN: any queue over 50 messages, or oldest message 10–60 minutes,
  on both reads
- FAIL: any queue over 500 messages, or oldest message over 60 minutes,
  on both reads
- N/A: server has no transport role

**On deviation:** Identify the next hop and last error for the affected
queue, check whether the destination resolves and accepts connections,
and report why the queue is growing, not just that it is.

## Constraints

- **[operational / high] Two reads before a verdict.** Never report WARN or
  FAIL for a queue based on a single read. If the two reads disagree,
  report OK with a note and save the observation.

Because every check has a number and a verdict rule, the report becomes a matrix instead of an essay. You can compare HD-3 on one server with HD-3 on another, or with last week's run.

Constraints, output format, and visibility

Constraints are typed rules with a severity. The type is one of security, operational, compliance, or technical, and the severity runs from critical to low — so a rule reads as security/critical or operational/high. Each has a title and a short body, like the queue rule in the example above. The constraints you see most often are the ones that make a run safe and trustworthy: stay read-only, never restart a service, never fabricate a verdict you could not measure, save every deviation as soon as you find it, and phrase remediation as a recommendation, not an action. Constraints set how the AI behaves. The enforced limits sit on whatever runs the playbook: the tool groups it may call, the identity it acts as, and how long it may run.

Output format and report structure define what the reader gets. That means a verdict legend, the layout of the matrix, and an outline of the chapters. An assessment may require a full document with a management summary, a findings chapter, and a prioritized plan. A health check usually leads with the matrix and follows with a detail block for every check that is not OK.

Visibility decides who sees the playbook at all. View groups control which users can find and run it, so a specialist playbook stays with the team that owns it.

Shared modules: write it once, fix it everywhere

Most playbooks share building blocks, and those blocks live in shared modules that the playbook includes. The platform inlines the modules at compile time, so the compiled document the AI reads is complete. Typical modules hold:

• Hard rules: read-only by default, no fabrication
• Execution guidelines: plan first, run in parallel, handle timeouts
• A tool reference note that points the AI to the live tool schema as the authority
• Output formats: how to deliver the report, how to generate a DOCX
• Check catalogs, such as Windows and Linux hardening baselines
• Connection recipes, for example opening an authenticated Exchange management session
• Publishing steps, such as writing the result to a team wiki

Reuse matters for three reasons. The safety rules are identical across every playbook, so a health check and an assessment stay read-only in exactly the same way. A fix to a module lands everywhere, because every playbook that includes it is rebuilt when you save. And each playbook stays focused on its own domain instead of repeating boilerplate.

The same structure fits several kinds of playbooks: assessments, health checks, inventories, and event-driven agents. An event-driven agent that enriches a support ticket when it opens, for instance, usually carries a larger set of constraints than a health check, because it reacts to input it did not choose.

Three ways a playbook runs

The most common way is chat. You name the playbook and the target, and the AI fetches the playbook, opens a session per target with the playbook recorded on it, works through the checks, saves findings as it goes, and submits the session for review. A typical starter prompt looks like this:

Follow the domain controller health-check playbook against all domain
controllers in this domain. Save every WARN and FAIL as a finding and
give me the verdict matrix at the end.

In chat, the most-used playbooks are PKI assessments, infrastructure reviews, and domain controller and SQL Server health checks, followed by security reviews and Exchange.

The second way is an agentic workflow. A workflow combines a short instruction with an optional playbook, the tool groups it may use, a service account to act as, and optionally a pinned tenant connection. It starts when someone clicks Run now, when a webhook fires, or on a schedule. Most playbook-backed workflows are health checks and inventories that run on a schedule, while ticket enrichment and sign-in monitoring usually run behind a webhook. Keep the workflow instruction short and let the playbook carry the method. The morning health-check pattern in Health Checks That Are Done Before the Team Arrives shows how this works in practice.

The third is task agents, which are delegation inside a chat rather than a separate way to start a playbook. While following a playbook, the chat agent can hand a scoped sub-job, such as "run HD-4 through HD-6 on these three servers", to a sub-agent with a brief. Several can run in parallel, they are usually read-only, and each one is tracked in the parent conversation's task list.

Draft, published, and better every version

A playbook starts as a draft and becomes available once it is published. An archived playbook is no longer offered, but it stays traceable so older sessions still make sense. Every save bumps the version, and a session keeps the version it started with, so editing a playbook never changes a run that is already in progress. The core playbooks go through many revisions, and editing a module rebuilds every playbook that depends on it.

Those revisions are where real runs pay off. The lessons show up as new rules in later versions: confirm a flaky signal such as a queue with two reads before reporting it, run a check locally on the target instead of remotely when the remote path produces false failures, and never report an asynchronous query that has only half resolved. Each of these starts as a finding you had to question, and ends as a constraint that saves the next person from asking.

TIP

When you correct the AI during a run ("that queue drained, read it again"), treat the correction as a candidate constraint. If it would apply to every run, it belongs in the playbook or in a shared module.

Authoring tips

A few habits separate playbooks that run cleanly from ones that produce essays:

• Number every check and give it a verdict rule. The report becomes a matrix you can compare over time.
• State the thresholds, and add an "on deviation" line to every check so the AI reports why, not just that.
• Write explicit "do not" constraints with a severity, and pair them with "emit remediation as a recommendation."
• Save findings during the run with a stable key, such as host plus check ID, so re-runs and trends line up.
• Discover everything before checking anything, and never skip a target silently. Mark it N/A with a reason.
• Cross-reference sibling playbooks. A certificate finding in a domain controller check hands off to the PKI playbook instead of growing a second PKI review.
• Define the output template and language in the playbook, move publishing into a module, and move any block you have written twice into a module.

The companion posts go through the playbook families one at a time: identity playbooks, server role playbooks, and operational playbooks.

Next steps

To run or write your first playbook, start with Playbooks for how assessments use them. Then see Playbooks (Admin) for managing the catalog and shared modules, and Agentic Workflows for running a playbook on a schedule or a webhook. Findings from every run land in Insights.