Playbooks for Operations, Not Just Assessments

September 12, 2026 · InfraScout Team

Most teams first use playbooks for assessments. But a playbook is really a way to capture how a procedure should be done, and many procedures aren't assessments. They live in a runbook, or in one colleague's head. Written as a playbook, the procedure runs against real hosts and tickets with the same steps and guardrails every time, so two runs look alike whoever starts them.

This post walks through five custom playbooks you can build for operations work. They show a pattern you can copy into your own catalog. For the anatomy (role, objectives, phases, verdict rules), read What's in a Playbook, and How It Gets Used first. This post covers what goes into that structure.

Why a playbook beats a good prompt

A good prompt gets a good answer once. A playbook gets the same shape of answer every time: every new host described in the same terms, every ticket comment built the same way, and the risky step handled the way it has been since it last went wrong. Ad-hoc prompting leaves all three to chance.

Example 1: An onboarding baseline

When a new host joins the fleet, you want a full picture of it right away on Windows, Linux or macOS. That covers identity, hardware, network, storage, time sync, roles, services, listening ports, software, scheduled work, local privileged accounts, virtualization and containers, patch state, logging, and cloud enrollment. Because the catalog is the same every time, you can compare hosts and spot changes.

The playbook scopes itself to exactly one newly onboarded agent and checks for an earlier baseline to compare against. It collects the system baseline and a cross-platform inventory, then takes a platform-specific posture snapshot, kept shallow on purpose. It saves everything and recommends which deeper assessments to run next, with a reason for each.

Each baseline block is saved as an insight under a fixed key, about twenty in all, so a re-run updates the same records. Re-onboarding a host produces a drift finding that sums up the material changes, such as new listening ports, new local admins, an OS change or new roles. Severity is strict: inventory facts are informational, and only real misconfigurations rate low or higher. The existing inventory snapshot comes first, with live enumeration as the fallback. A check that can't run is marked "not assessable", with the reason.

The run is read-only and never touches another host. It masks and flags any credentials it finds. Every fact traces back to a command, and follow-ups are recommended, never started. The insights are the deliverable, with a short chat recap of role, posture, top findings and follow-ups. You run it for each newly onboarded agent, or from chat.

Example 2: Ticket enrichment

This is an emerging pattern: an event-driven helper for a service desk. When a Jira issue arrives, the playbook works out what the ticket needs answered, investigates that one question, and posts one internal comment. It exists to prevent the telemetry dump, a comment that lists everything about every host the ticket mentions.

Phase 0 validates the payload: the issue is required, while visibility, scope, live probes, a wait limit and dry run are optional. Phase 1 reads the ticket before collecting anything. It states the core question in one sentence, names the central artifact (a directory, a mail rule, a certificate, an error code), pulls the exact error wording, and notes the team's own hypotheses. Then it writes one to three candidate answers, each with the one probe most likely to settle it.

Phase 2 tests those hypotheses: the artifact first, then the wiki (Confluence), the agent fleet, and Microsoft cloud signals chosen by question type, such as message trace for mail or sign-ins for access. Phase 3 runs optional read-only host probes, off by default. Phase 4 puts the answer first and confirms or refutes the team's hypotheses. Phase 5 writes the comment and an audit record.

The relevance gate carries the design: a fact appears only if it changes how the handler understands the ticket, and any line that would need a "not related" note is deleted. An error shown only in a screenshot is flagged as a gap. Async queries are polled to completion, so a query still running is never posted as a low-confidence finding. Observed state beats documented expectation. Internal identifiers never go into external queries, only generic product names, cmdlets, public error codes and CVEs. A signature line lets a re-run update its comment instead of posting a duplicate.

The payload is the only source for which ticket to touch, and referenced tickets are read-only. The only writes are one comment and one audit record, with no transitions, assignments or field edits. The comment must carry restricted visibility. If none can be resolved, the run doesn't post and records the blocker instead.

The comment gives the answer with a confidence tag, then the finding, evidence and wiki context. Side findings are capped at three high-severity lines, each pointing to a separate ticket. Open points come with exact read-only commands, and empty sections are left out. It runs as a webhook-triggered agentic workflow in batch mode. Dry run renders the comment without posting, which is a good way to build trust first. An invented payload looks like this:

{
  "issue": "<ISSUE-KEY>",
  "comment_visibility": "internal-support",
  "live_probes": false,
  "dry_run": true
}

Example 3: A configuration change that survives its own restart

This playbook is an operational lesson learned the hard way and captured once. It is not a general tool. The job is to change one value in the InfraScout agent's own configuration on a Windows host, such as repointing it, then restart without losing the session doing the work. A naive stop-then-start kills that session. A blind search-and-replace can quietly do nothing.

The playbook confirms the agent is online, reads stored host notes, and starts a session. It locates the config from the service entry instead of guessing a path, then reads the current content. It makes a timestamped backup and replaces only the one value, then reads the file back to verify it. The restart runs through a temporary scheduled task under the system account, outside the agent's process tree. Last, it checks service status and process uptime, removes the task, and submits the session with a summary.

Every step runs in order. No backup means no change, and the run aborts if the replacement changed nothing. The restart is blocked until verification passes. Verification runs again after the restart. The agent is never stopped and started by hand. A table of known pitfalls and a rollback recipe (restore the newest backup) are part of the playbook, and any failure halts the run and rolls it back. The report lists the host, old value, new value, backup location and restart evidence, with raw verification appended. It runs from chat, on one host, in minutes.

Example 4: Deploying a third-party MCP server onto an agent

The job: install a third-party MCP server on a Linux agent that hosts the MCP proxy, prove it works, and hand back the exact registration settings. Ad hoc, this usually fails on transport or logging details, and often only after the admin has already registered the server.

Intake takes a source (git repo, npm, PyPI or container image) and a host that advertises the proxy capability. A read-only preflight checks that hosting is enabled and reads the server cap, the command allowlist, free slots and the toolchain. The AI then reads the source to derive the launch contract: command, arguments, environment variables, working directory and stdio support. It picks exactly one mode: Node, Python in a virtual environment, a container as a stdio child, or a loopback HTTP fallback. After approval it provisions the server, proves the handshake, reconciles the proxy policy, and hands off.

It never guesses a repository name, because a wrong guess is a supply-chain event, not a typo. The handshake is proven with the exact final command: clean JSON-RPC on stdout, a non-empty tool list, a clean exit. The most common failure is a server that logs a banner to stdout, fixed in that server's own configuration. Versions are pinned, containers get stdin attached and no TTY, and the HTTP fallback targets only a loopback IP literal, never a hostname.

Discovery runs on its own, but every state change needs explicit approval: the first install, any agent config change, any restart. Allowlist changes replace the old list, so the full list is always passed. No configuration is handed over until the handshake passes. The output is a field-by-field table for the admin form, plus insights. A run takes about 15 to 30 minutes in chat, most of it spent on installs.

Example 5: Porting legacy check scripts into health checks

Many teams keep an existing catalog of legacy check scripts. It might cover general Windows servers, event logs, and a mixed set for domain controllers, DNS, update servers and Exchange. Porting it means restating each check as a goal, scope, measurement window, pass criterion and severity rules. The AI chooses its own read-only way to measure. The original scripts aren't run, and the playbook becomes the source of truth.

The run takes a supplied host list it may not change, runs prerequisite checks first, then the catalog, then the report. Requirements use EARS syntax, a fixed set of keywords for unconditional rules, host traits, ongoing states, events, and unwanted states that assign a severity. The rules within a check don't overlap, and together they cover the whole failing range, so the AI never invents a threshold. Per-role deviations and named noise exceptions are part of the format. An invented example:

### EL-4 Unexpected service terminations

- The system shall read the System log for the last 24 hours.
- Where the host holds the print server role, the system shall
  ignore spooler terminations listed as noise exceptions.
- When a service terminates unexpectedly 1–2 times in the window,
  the system shall rate the check WARNING.
- If a service terminates unexpectedly 3 or more times in the
  window, then the system shall rate the check ERROR and compare
  the same log on servers with the same role.

Execution is complete: every check runs on every host, with no sampling. Before the report can start, a hosts-by-checks matrix must hold a value or a reasoned "unknown" in every cell. The report states how many checks actually ran and explains any gaps. Words like "representative" and "sample" are banned, so a partial run can't pass as complete. Anomalies trigger read-only follow-ups and a comparison with similar servers, which separates a one-host problem from a fleet-wide one.

Anything that changes state needs confirmation in chat. Domain controllers and update servers are checked locally, so the most sensitive tier gains no remote-execution surface. A failure degrades a check to warning, error or unknown, never aborting the run. You get a status report per host and check group, summary first, and it runs from chat or as a scheduled workflow.

What the five have in common

Each playbook has one job and one scope boundary: one host, one ticket, one catalog. Each is read-only by default. Writes are gated by a confirmation, a payload flag or a fail-safe. A backup comes before every change, with verification before and after it. Idempotency is designed in through stable keys, signature markers and existing-baseline checks. Fetched data, ticket text included, is untrusted: the payload names the target and nothing else. Honest gaps such as "not assessable" and "unknown" count as proper results. Structured output contracts keep runs comparable.

Most of all, playbooks keep hard-won lessons. The self-restart trap and the stdout logging trap are exactly what ad-hoc prompting would find again, painfully. Playbooks also compose: the baseline hands off to specialist assessments, and the health checks leave domain controllers to their dedicated playbook.

TIP

Start with the procedure your team gets wrong most often, not the one it runs most often. A playbook is worth the most where the lesson was expensive.

Next steps

Start with What's in a Playbook for the anatomy, then the Playbooks reference for authoring. To run one on a webhook or schedule, see Agentic Workflows. For the ticket side in a live conversation, read From Ticket to Verified Change.