Playbooks
Use Studio Playbooks as reusable instruction sets that tell agents when to act, what instructions to follow, and which tools, integrations, system tools, tables, or custom tools they can use.
Connect the screen to the operation it controls: customer signal, agent behavior, workflow path, channel, CRM context, and review outcome.
What the Playbooks page is for
The Playbooks list is the library of reusable operating instructions. Use search and status to find an existing playbook before creating another one.
The Create Playbook panel exposes the fields that matter operationally: When to use, Instructions, Select tools, Integrations, System tools, Tables, Custom tools, an Enabled switch, and Save.
Why playbooks matter
A playbook is not another generic content page. It is a reusable operating instruction set that can be attached to agents so behavior stays consistent across repeated business moments.
Use Playbooks when the same job appears across customers, channels, or workflows: ticket creation, payment links, candidate sourcing, pipeline updates, presentations, bid monitoring, or location assistance.
System diagram
Business request -> When-to-use rule -> Playbook instructions -> Tool or table context -> Agent action -> Workflow or Max Activity
Operational setup loop
First write the When to use rule so the agent knows the exact situation. Then write instructions as a repeatable operating procedure. Finally attach the tool, table, integration, or custom action that lets the agent complete the job.
The Tools module validates the action side of this model: Create Custom Tool asks for Tool name, When to use, and Tool type. Tables validate the structured data side with existing Contacts, Subscribers, Qualified Leads, and Retargeting tables.
Examples worth teaching
Support ticket creation: when a customer describes a problem, identify the ticket details, priority, company, and owner before creating the record.
Payment link creation: when a customer asks to pay, confirm the company, amount, plan, and allowed payment tool before generating the link.
Pipeline update: when a teammate asks to move or summarize a deal, check the current record first and only update fields that are explicitly supported by the request.
Good playbook shape
A good When to use rule names the situation in plain language. A good instruction block names the data to check, the action to take, and the cases that require human review.
Keep each playbook narrow. If one playbook covers support, sales, billing, and research, split it before attaching tools.
Debugging a bad result
If the agent used the wrong playbook, tighten When to use. If the right playbook produced the wrong output, tighten Instructions or remove unnecessary tools.
If a tool call fails, check whether the integration, table, or custom tool is connected and whether the playbook has permission to use it.
FAQs
What is a Studio Playbook?
Use Studio Playbooks as reusable instruction sets that tell agents when to act, what instructions to follow, and which tools, integrations, system tools, tables, or custom tools they can use.
When should I create one?
Create a playbook when the same instruction pattern repeats: create a support ticket, generate a payment link, research a candidate, update pipeline, prepare a presentation, or monitor bids.
How should this page fit into onboarding?
Use it to understand the product surface, inspect real UI states, and connect the concept to daily operating workflows before configuring production behavior.
What should I verify before using this in production?
Verify ownership, permissions, source context, failure behavior, and the handoff path so teammates can trust what the system does next.