Skip to content

Playbooks & guardrails

A playbook is a recorded, repeatable how-to: the steps to handle a known task or incident. Playbooks are how know-how stops walking out the door when the person who figured it out is asleep, on leave, or has moved on.

A playbook comes into being in two distinct ways:

  • Propose: after engineer9 works through a multi-step task, it can offer to save the steps. This is a suggestion, not an automatic write.
  • Save: a human commits it. You accept engineer9’s proposal, or you ask it directly to save steps as a playbook. Nothing becomes a playbook until a person commits it.

You can also edit an existing playbook (“update the deploy-rollback playbook: …”) and run one (“run the trace-to-metrics playbook”). Running a playbook whose steps include a destructive command will still go through human approval for that step.

@engineer9 what playbooks do you have?

If there are none yet, engineer9 says so. It builds them as your team solves things, so the library grows with use.

Guardrails: can someone tamper with a playbook?

Section titled “Guardrails: can someone tamper with a playbook?”

A fair question, and the honest answer is the same as for any team wiki: anyone who can edit your runbooks can change them, and the defense is mostly social. You treat engineer9 like a member of the team, and the team decides how to treat it.

Two things make that workable:

  • It’s a team agent, not a personal one. engineer9 won’t permanently adopt one person’s personal preferences or “act as a different character.” A shared teammate doesn’t behave that way, so a one-off attempt to make it misbehave doesn’t stick.
  • Destructive actions still need approval. Even if a playbook is edited, running anything with real consequences routes through a human first (see Human approvals).

Editing a playbook overwrites it. The memory store is version-controlled, so prior versions remain in its history if you need to look back. There is no separate in-product version view today.