Playbooks and Flows¶
Preview
Framework v2 is not yet available to all accounts.
Some situations are conversations; some are procedures. Answering a question about laser hair removal is a conversation: the agent should listen, look things up, and respond in its own words. Booking a call is a procedure: collect a name and email, offer times, confirm, book, send the confirmation. v2 gives you one Playbook shape for both, with one addition for the second kind.
Two kinds of Playbook¶
An open-ended Playbook has a when-to-use line, a body, and uses.
The agent reads the body and decides, turn by turn, what to say and
what to do. This is the right shape for anything where the path depends
on the person: discovery, questions, objections, qualification.
A Playbook with a Flow has the same parts plus a fixed path: a short list of steps that the platform walks in order. The agent's job inside a Flow is narrower: understand what the person said, fill in the step's blanks, and phrase the next question. It does not decide what the next step is. This is the right shape for anything that must happen the same way every time: booking, consent and opt-in, intake forms, handing someone to a human.
| Use an open-ended Playbook when… | Use a Flow when… |
|---|---|
| The path depends on what the person says. | The path is the same for everyone. |
| A good answer needs judgment. | A wrong step has a cost (a wrong booking, a missing consent). |
| You would brief a new teammate in prose. | You would give a new teammate a checklist. |
Mia's Welcome, Answer treatment questions, and Qualify are open-ended. Book a consultation call and Talk to a person carry Flows.
Describing a Flow in plain words¶
You do not draw a Flow. You write the Playbook's body as you would any other, describing what should happen, and ask the Copilot to generate the path. The Copilot reads the body, the agent's capabilities, and the message templates in Content, and proposes the steps. Where a step needs reviewed copy and no template fits, it proposes a new template into Content for you to review.
Mia's booking Playbook body:
Confirm the person's name and email if we do not have them, offer times from the team's calendar, confirm before booking, send the booking confirmation, then return to general help.
The Copilot compiles it into a path you can read as a checklist:
- Collect full name and email. Skipped for anything already on the Person record.
- Collect a preferred time from the team's real availability, shown as a tappable time picker on RCS and a numbered list on SMS.
- Confirm: "Book Tuesday 2:00 pm with Dana?"
- Book the call through Scheduling.
- Send the Booking confirmation template.
- End with the outcome call booked, and return to the Playbook the conversation came from.
The steps are shown read-only in the Playbook editor's Deterministic path panel. You review them; you do not edit them step by step. If you change the body, lint notes that the words and the path no longer match ("Body changed since the path was generated. Regenerate?"); you regenerate or keep the old path. The path is what runs, so a body edit takes effect on the conversation only once you regenerate.
The Deterministic path panel¶
On the v2 runtime every Playbook on the Playbooks page has a Deterministic path panel below its instructions. A Playbook that carries a path is marked Guided and the panel lists its steps.
| Control | What it does |
|---|---|
| Generate path | Reads the saved instructions, uses, and the agent's capabilities, templates, and People fields, and proposes a path. Shown when the Playbook has none. |
| Regenerate | The same, for a Playbook that already has a path. The proposal is shown as changes to the current path (before and after). |
| Use this path | Saves the proposal as the Playbook's path. Until you click it nothing is stored. |
| Try again | Generates a fresh proposal in place of this one. |
| Discard | Drops the proposal and keeps whatever the Playbook had. |
| Remove path | Deletes the path; the Playbook goes back to open-ended. |
A proposal arrives with a checks strip and the generator's notes. The
strip reports the three checks every proposal passes through: the
path is valid against the Flow specification; every reference in it
resolves (a step that books a call requires Scheduling in uses, a
template it sends must exist in Content, a field it records to must be
a People field, a step it jumps to must exist); and a dry run with a
cooperative person reached an outcome. Lint errors are listed in the
proposal and Use this path stays disabled until they are gone;
warnings are listed and do not block. The notes are the generator's
own caveats: what the instructions asked for that a path cannot
express, or an assumption it made.
Generation runs from the text as saved. While a Playbook has unsaved edits the panel says Save your changes first and the buttons wait, so the path you review was generated from the words on the page. Generation takes ten to forty seconds.
Through the API the same loop is POST …/playbooks/{id}/flow:generate
followed by a PATCH carrying flow; see the
Agent API. The Copilot
uses the same call when you ask it to turn a Playbook into a path.
Digressions and returning¶
People do not follow checklists. Halfway through booking, a person asks "Is the consultation free?" Two things can happen, and the agent picks by judgment. For a quick aside it answers in its own words and the Flow re-asks its question in the same reply — the person sees the answer, then the time picker again. For a real change of subject ("forget the call for now, I have questions about the laser first") the Flow pauses, Answer treatment questions takes over, and when the person comes back to booking the Flow picks up where it left off with everything already collected still in hand. The person does not repeat their name. This is on by default for every Flow and is the reason a Flow does not feel like a phone tree.
Corrections work the same way. "Actually, we're a dermatology clinic" changes the value already collected and the Flow continues from where it was. "Never mind" ends the Flow without booking, and the agent returns to general help; asking to book again later starts fresh.
When the agent hands a conversation into a Flow it writes at most one short bridging sentence — the Flow's first question, with its options, follows in the same reply.
What "deterministic" buys you¶
A Flow is deterministic: the same inputs walk the same path. That gives you three things an open-ended Playbook cannot promise.
- Predictable. The confirmation is always asked before the booking is made. The confirmation template is always the one you reviewed. There is no turn on which the agent decides to skip a step.
- Testable. A Flow can carry example conversations with the outcome each should reach, and Anychat can run them before you go live and after each change; see Checking your agent.
- Checkable. Because every step names what it touches, lint can verify the Flow against the rest of the Brief: a step that books a call requires the Playbook to use Scheduling; a step that sends a template requires that template to exist in Content; a step that hands to a Playbook requires that Playbook to exist. A broken reference is reported when you save, not discovered by a customer.
Inside a Flow the agent has less to decide, so Flow turns are also faster and cheaper than open-ended turns.
Where Flows come from¶
Three places. Scheduling ships its own booking Flow, so a booking Playbook that uses Scheduling can adopt it without generation. Anychat's catalog carries library Flows for common procedures (opt-in, intake). And the Copilot generates one from any Playbook body you write. All three are copied onto your agent and are yours to keep, review, and regenerate.
Generation is checked before you see it: the proposed path is validated against the Flow specification, every reference in it is linted (the capabilities the Playbook uses, the templates in Content, the People fields it records to, the steps it jumps to), and it is dry-run with a cooperative person to make sure every branch reaches an outcome. A warranty-intake Playbook written as four sentences — which product, when it was bought, what the problem is, whether it is within 24 months — comes back as a path with a date question, the 24-month rule as a real check, a booking for covered claims, and three distinct outcomes.