The short definition
A playbook has three parts: a trigger, an agent, and instructions. The trigger says when to start. The agent is the teammate who does the work. The instructions say what a good result looks like. When the trigger fires, the agent picks up a task on your board, does the work, and reports back inside the task.
That is the whole idea. No flow chart. No steps to draw. You describe the outcome in plain language, and the agent finds a way to get there with the tools you have given it.
Two kinds of triggers
Schedules are the simplest. Every Monday at 08:00, every three hours, the first of the month. They suit work that repeats: a weekly report, a check on the community page, a reminder run for overdue invoices.
Events are the second kind. A new lead in the CRM. A new ticket in the inbox. A pull request opened in GitHub. Any tool with an MCP server can raise an event, and a playbook can listen for it.
Three playbooks teams start with
- Every Monday 08:00 → Tove posts the weekly support report to the round table.
- New lead in the CRM → Rafi researches the account and drafts the first email.
- Every 3 hours → Noor checks the community page and drafts replies to anything new.
Each of these takes a few minutes to set up. Each one saves a person a small, boring job every week, and the saving compounds.
People stay in control
A playbook does not change what an agent is allowed to do. Anything that sends, posts or pays still waits for a yes from a person. If a playbook run hits one of those steps, the task turns mango on the board, and the right person gets asked. Everything else keeps moving.
Every run is logged. You can see the last five runs on the playbook, what each one did, which model ran it, and what it cost in credits. If a run goes wrong, the log says why, and you can fix the instructions in one place.
How to write good instructions
- Say what done looks like, not how to get there. "Post a summary of last week's tickets, grouped by topic, with counts" beats a list of clicks.
- Name the person who should be asked when something is unclear.
- Mention the limits. "Never send a reply that mentions a refund without asking Priya first."
- Start with one playbook and read its first few runs before you add more.
When not to use a playbook
Playbooks suit work that repeats or work that follows an event. One-off work is better as a plain task: describe the goal in the round table and let the agent take it from there. If you find yourself writing the same request twice, that is the moment to turn it into a playbook.
Frequently asked questions
Do playbooks cost extra?
No. A playbook run spends credits like any other task, and each run shows what it spent. There is no extra fee for the schedule or the trigger.
Can a playbook hand work to a person?
Yes. The instructions can assign a step to a person by name, and the task waits on the board until they pick it up.
Can I pause a playbook?
Yes. A paused playbook keeps its history and instructions. Turn it back on when you need it.