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.New here? Read Why playbooks first - it explains the
problem playbooks solve versus prompt-based and graph-based agents.
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
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.