In one sentence
A playbook describes an outcome-driven conversation in plain language. Instead of drawing a flow chart with every branch, or stuffing everything into one prompt, you write checkpoints - the things that must be true before the conversation moves on.Why not a big prompt or a graph
A big prompt fails by confusion - the longer it grows, the more the model skips rules. A hand-drawn graph fails by latency and rigidity - extra model calls per node, and real callers walk off your edges.
The full model - and when a graph still earns its place - is in
Thinking in playbooks.
Checkpoints gate outcomes, not utterances
The engine decides what to say each turn. The checkpoints decide when the conversation is allowed to move on. You describe the destination; you do not script every sentence.Example checkpoint
The parts of a playbook
Field-by-field reference for both authoring formats is in
Playbooks.
A small, complete playbook
How it runs: Talker + Director
A playbook is fast because two roles run at once:Talker
Streams every spoken reply the moment it can, so the caller hears a natural,
immediate response - no waiting on bookkeeping.
Director
Runs asynchronously: reads the transcript, extracts slot data, judges
whether a checkpoint’s
done_when is met, and runs any tools - over an
event-sourced log.The full checkpoint model
Go deeper on
done_when / advance_when, slots, and interrupts in the
mental-model guide.Where playbooks come from
You rarely hand-write the YAML from scratch. You author a playbook by talking to a builder agent in the Playground - describe the job, and it writes the checkpoints for you.What is the Playground
The browser app where you author, test, optimize, and ship a playbook.
Build an agent playbook
The hands-on walkthrough: describe an agent and watch its playbook appear.