Inside a working playbook

A playbook is not a prompt library and not a ticket queue. It is a defined way to do a recurring piece of work: the sequence, the sources, the moment a person must decide, the record of that decision, and the version everyone should use. A prompt can help with one turn. A ticket can say that work exists. A working playbook carries the method from start to finish, so a team can run it again, teach it, and improve it.

We will follow one hypothetical example through all five parts: a customer-response playbook. A support-style message arrives with a product question and a request for an exception. The team needs an accurate, on-tone reply, grounded in current policy and approved by a person before it reaches the customer. The details are fictional. The design problem is common.

01Steps

Steps are the spine. Each step is a unit of work with a clear finish line: gather the thread, draft the reply, check policy, send the approved message. A step should answer “what happens next?” for the person or agent running the playbook. It should not try to encode every edge case, every soft skill, or every tool path the team might ever use.

Each step needs an action and a visible result. In this example, gathering the inbound message and account history produces a source packet. Drafting produces a proposed reply grounded in that packet. Checking the reply produces a decision. Sending produces the customer-facing outcome. This is enough structure to show where the work stands without turning the playbook into a lecture or a transcript of every keystroke.

Granularity is a craft choice. Too coarse, and the run becomes a single opaque blob: “handle the response.” Too fine, and the playbook turns into a checklist of keystrokes that no one wants to maintain. A useful test is whether a step can complete, leave something inspectable, and hand off cleanly. If two micro-actions always move together and never need separate review, they are probably one step. If a handoff changes who is accountable, or changes what an agent versus a person must do, that is usually a step boundary.

So the customer-response sequence has four meaningful handoffs. First, gather the message, account notes, and open issues. Next, draft from the context the playbook supplies. Then a person reviews tone, factual accuracy, and commitment language. Only after that decision does the send step become available. The outcome is not “an AI said something.” It is a legible path from inbound message to approved reply.

Steps also mark who acts. Some work is better as human judgment with light assistance. Some work is better as AI draft with a tight brief. Naming that in the step keeps the playbook honest. It prevents the common drift where everything becomes “ask the model” until quality collapses, or everything stays manual until the team wonders why the agent is even there.

02Context

Context is the material the work needs but should not reinvent on every run. For customer response, that means current product facts, the tone guide, policy boundaries, known issues, and the escalation path. It can also point to systems reached through MCP or a CLI. The test is practical: does this material help the runner complete a step correctly? If not, it is background, not working context.

When context lives only in one head, the playbook is a script without a set. New people improvise. Agents invent. Reviewers spend their time repairing basics instead of applying judgment. When context travels with the playbook, every run starts from the same floor. The team can update the packet once and know the next run will see it. That is the difference between personal craft and shared practice.

Good context is narrow enough to use. The reply needs approved product language and the current exception policy, not the history of how either was written. It needs the known caveat that changes this answer, not a tour of the whole roadmap. Scope it to the decisions inside the steps, and the draft is less likely to be polished but wrong.

Constraints matter as much as sources. “Be helpful” does not say whether the draft may offer a refund, promise a ship date, or disclose an internal workaround. The packet should state what may be offered, what requires escalation, and which commitments are off-limits. The draft then starts inside a known frame. The review gate checks whether it stayed there.

This context should be resolved for the run, so the work has a stable basis even if company memory changes later. When policy changes, the team updates the playbook or its context for future runs. That preserves both things a team needs: the improved default going forward and an understandable record of what guided earlier work.

03Review gates

A review gate is a deliberate pause where a person must act before the run continues. It belongs where the cost of a wrong move rises or where judgment cannot be reduced to a rule. Elsewhere, it adds delay and teaches reviewers to click through. The goal is not more approval. It is real approval at the right boundary.

Place a gate where risk concentrates. Customer-facing language is a classic concentration point. So is money, access, legal commitment, or anything irreversible. Do not place a gate on every draft sentence or every internal note. If the team will not slow down for the check, the gate is decoration. If the team will slow down for noise, the gate trains people to approve without reading.

In the customer-response playbook there is a single gate before anything customer-facing ships. The AI-assisted draft may be excellent. The context packet may be complete. Still, a person reads the proposed reply against the thread, the commitments it makes, and the tone. Only after that human completion does the run move to send. Internal prep steps do not need the same stop. The gate is one, and it is real.

Human-gated steps are not surveillance. They are process. The point is to make judgment visible at the moment it matters, not to watch every keystroke. A gate answers: has a responsible person accepted this state of the work? If the answer is yes, the run proceeds. If the answer is no, the work does not become the customer’s problem.

Teams sometimes add gates because they do not trust the steps or the context. Fix the packet and sequence first. A gate is a decision point, not a substitute for a clear method. When the draft is grounded and the steps are the right size, one gate at the shipping boundary may be enough for this kind of work. To see how an owner can scope and test that first run, read how to make one workflow repeatable.

04Review records

A gate without a record is a moment that vanishes. A useful review record preserves the artifact under review, the playbook version used, the decision, and enough reasoning to understand it later. Those details turn “someone checked it” into a reusable account of what good review meant in that run.

For the customer response, the artifact is the proposed reply beside the inbound thread. The decision is approved or returned for revision. The basis can stay short: the product caveat is present, the tone matches the guide, and the draft makes no exception beyond current policy. The reviewer completes the gate, and the run keeps that decision with the work it governed.

Records are not for catching people out. They are for making the work inspectable enough to trust. When a reply later looks odd, the team can see whether the process ran, which version guided it, and who signed off. When a new teammate asks how to review well, past records show what good review actually checked. When the playbook improves, old runs remain understandable as products of their version, not mysterious history.

Keep the record proportional to the decision. A paragraph required for every routine reply invites filler. An empty approval captures too little. Here, a brief step note plus the completed human-gated step can preserve the useful surface: what was checked and why the send was allowed. If the case is unusual, attach the fuller conversation transcript to the run instead of forcing every review into an essay.

Once the reviewer approves this reply, the send step can proceed. Months later, the team can inspect the run, its notes, and any attached transcript without rebuilding the story from a loose chat history. That history is not a scorecard for the person. It is part of the work.

05Versions

Versions are how improvement becomes default. An approved change to steps, context, gates, or record expectations becomes a new playbook version. New runs use that version. Old runs keep the version they actually used. Nothing is rewritten in place in a way that erases what people already did.

Without versions, “the process” is whatever the last person remembered. With versions, the team can point at what is current, roll forward deliberately, and understand past work against the rules of its day. That is the same discipline software teams use for code, applied to how the organization runs AI-assisted work.

A version change should be intentional. Editing an organization-authored playbook appends a version, while the active version determines what future runs resolve. If the change affects what people do, which context they use, or where approval is required, it deserves that boundary. The mechanics matter because they keep improvement from silently rewriting history.

Return to the customer-response playbook. After several runs, the team notices that drafts often miss a recurring product caveat that support people know by heart. Version two adds that caveat to the context packet and a one-line check in the human review step: confirm the caveat appears when the thread touches that product area. The gate stays singular. The steps stay roughly the same size. What changes is the floor the draft starts from and the basis the reviewer uses.

Once version two is active, the next run gets the improved default without a private tip. The draft uses the added caveat. The reviewer checks for it. Earlier runs remain tied to the version they resolved at the start. For the practical release discipline around that change, see how to version a playbook without losing the thread.

Versions also make teaching honest. You can say, “We used to miss this case. Here is when we fixed it.” That is calmer than pretending the process was always perfect, and more useful than leaving every lesson trapped in one operator’s notes.

The takeaway

A working playbook is five parts in combination. Steps define the sequence at a grain people can finish and hand off. Context carries the sources and constraints so the work does not depend on one memory. Review gates place human judgment where risk concentrates, not everywhere. Review records answer what was checked, which version applied, on what basis, and by whom. Versions turn an approved improvement into everyone’s default without erasing the past.

The customer-response example is hypothetical, but the pattern is not. Recurring AI-assisted work becomes team capability when the method is written down, resolved with the context it needs, paused where a person must decide, recorded lightly, and improved through versions. Constraint provides the place for those playbooks to live, run, be reviewed, and versioned beside the AI tools a team already uses.

See how that looks in practice. Browse the Bank.