Playbooks are goal-based. You define an outcome — resolve a support ticket, qualify a lead, process a return — and the agent navigates the conversation to get there.
What makes playbooks powerful is the tools they can use along the way. While the agent is talking to your customer, it can be looking up their order in Shopify, creating a ticket in Zendesk, updating a deal in Salesforce, or calling your own internal APIs — all in real time.
Unlike workflows, which follow a fixed sequence of steps, playbooks let the agent decide how to reach the goal based on context. You write the instructions — the agent handles the conversation.
Playbooks can be triggered directly by your agent, from within a workflow using the playbook step, or chained together using a crew step.
Playbooks can use tools to take action during a conversation:
- Integrations — pre-built connectors to tools your team already uses, like Zendesk, Salesforce, Shopify, HubSpot, Gmail, and more.
- API tool — connect to any REST API with a custom request. Use this for internal systems or any service without a pre-built integration.
- MCP tool — connect to any MCP server and expose its tools directly to the playbook.
- Function tool — run custom JavaScript logic mid-conversation, useful for data transformation, calculations, or lightweight processing without an external call.
- System tools — call the knowledge base, forward calls, end the conversation, display buttons, cards or carousels, search the web.
Tools work best when their names and LLM descriptions give the model enough signal to know what they do and when to use them — the same principle as naming/describing the playbook itself.Name — what the tool is. Short and literal. “Lookup Order”, not “Order tool”.
LLM description — what it does.
Instructions — when to use it. This goes in the playbook instructions, not the tool itself.A well-named tool with a clear LLM description means you write less in your playbook instructions — the model already knows what the tool is for.
Creating playbooks
Add or create a playbook
From the Agent tab, click + in the Skills panel. Select an existing playbook or create a new one.
You can also create playbooks from within a workflow using the playbook step, or from the playbook CMS tab. Name your playbook and add an LLM description
Give your playbook a clear name and description. The name and description tell the agent what the playbook does — your instructions tell it when to use it.
Write playbook instructions
You’ll be taken to the playbook editor to write or generate instructions. Playbooks added from the agent tab are automatically attached to your agent. Click × in the top right to return to the agent tab at any time.
Run your playbook
From the agent tab, press ‘Run’ in the top right, or use the shortcut Shift + R then initiate the playbook by typing or speaking a message.
Iterate
If your playbook isn’t performing the way you expect, start by improving the instructions — they’re almost always the culprit. From there, make sure your tools have clear names and LLM descriptions so the playbook knows when and how to use them. Changing the model should be a last resort, but can prove helpful given the goal at hand.
Writing good instructions
Instructions are the core of every playbook. They tell the agent what to do, and when to use its tools. Write in plain language — markdown formatting is supported.
The quality of your instructions directly affects the quality of your agent. Vague instructions produce inconsistent behavior. Specific instructions produce reliable, predictable agents.
Instead of:
Help customers check their order status, use the order lookup tool.
# Goal
Give {customer_name} a clear, accurate status update on
their order. Handle common order situations directly where
possible, and set clear expectations when you can't.
# Looking up an order
Ask for their order number or the email used at checkout.
Use the Order Lookup tool to retrieve the order before
saying anything about its status.
If the lookup returns multiple orders, list them with the
item name and order date and ask which one they're referring
to.
# Delivering the status
Share the item name, current status, and estimated delivery
date. Be direct — don't pad the response.
# Handling common situations
**Order is delayed:** Acknowledge it without over-apologizing.
Give the revised ETA from {delivery_eta} if available. If
no ETA is in the system, say so and offer to follow up when
it updates.
**Order shows delivered but customer didn't receive it:**
Confirm the delivery address on file. Ask if they've checked
with neighbors or in a safe spot. If it's still missing,
let them know this needs to go to the support team and
collect the details before handing off.
**Order was cancelled:** Explain why if the system shows
a reason. Confirm whether a refund was issued and the
expected timeline.
**Partial shipment:** Let them know which items have shipped
and which are still pending. Give separate ETAs if available.
**Wrong item received:** Apologize once, confirm what they
ordered vs what arrived, and let them know the support team
will sort it — collect the details before handing off.
# If the order can't be found
Double-check the order number or email. If still nothing,
let the customer know and offer to connect them with the
support team.
You can edit instructions manually or click the AI button to open the prompt editor, which helps you generate and refine your playbook from scratch.
Model settings
Click Model in the top right corner of the playbook editor to configure:
- AI model — which model powers this playbook (e.g. Claude Sonnet 4.6)
- Temperature — lower for consistency, higher for variation
- Max tokens — maximum response length
By default, playbooks inherit the model settings from your agent. Override them here if a specific playbook needs different behavior — for example, a lower temperature for a compliance-sensitive flow, or a more capable model for complex reasoning tasks.
Exit conditions
Exit conditions only apply when a playbook is used via a playbook step inside a workflow. When triggered directly by the agent, exit conditions are ignored as routing is handled by the agent. {company_size}, {use_case}, and {email}. The agent will keep the conversation going until all three are collected, then exit.
