Playbooks

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.

Tools

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 triggers 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”.
Trigger — what the tool does and when the agent should use it. Include both.
Playbook instructions — any additional context: ordering, error handling, or how the tool fits into the larger conversation.

Put the “when” in the tool’s description, not just in your instructions. Once a playbook is active, agent-level instructions are no longer in context — only the playbook’s own instructions are. A tool’s trigger that covers both what and when travels with the tool wherever it’s used.

Creating playbooks

Add or create a playbook

From the Agent tab, click + in the right editor. 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 a trigger

Give your playbook a clear name and trigger. The trigger should cover both what the playbook does and when the agent should route into it — this is what other playbooks, workflows, and the top-level agent read when deciding whether to call it. Create Playbook Docs 1

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 (or ‘esc’ on keyboard) to return to the agent tab at any time.

Add tools

Use the Tools panel on the right to add any integrations, APIs, MCPs, functions or system tools your playbook needs to achieve its goal.

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 triggers 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.

Write:

# 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.

Entry conditions and required variables

Entry conditions and required variables can only be applied when a playbook is routed to directly by the agent. They’re not available when the playbook is called via a playbook step inside a workflow.

Entry conditions and required variables control when the agent can route into a playbook. Until they’re met, the playbook stays unavailable, so the agent won’t hand off to it no matter what the customer says. This gives you precise, rule-based control over when each playbook becomes reachable.

Entry conditions

Entry conditions are deterministic checks that must evaluate to true before the playbook can be routed to. If the checks don’t pass, the playbook stays unavailable for routing. For example, you might only make a checkout playbook reachable once the{cart_total} variable is greater than zero, or gate an account management playbook behind {is_authenticated} being true.

Required variables

You can also require that specific variables have a value before the agent can route in. Until every required variable is filled, the playbook stays unavailable. For example, you could require the {account_id} variable to be set before the agent can hand off to an account management playbook, so it never starts without the information it needs.

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.

Playbooks can have exit conditions — the criteria that must be met before the agent considers the playbook complete. You can add required variables to any exit condition. These variables must have a value before the condition can trigger — even if the conversation seems resolved, the playbook won’t exit until they’re filled. For example, a Lead Capture playbook with an exit condition of “User is qualified” might require {company_size}, {use_case}, and {email}. The agent will keep the conversation going until all three are collected, then exit.

Build

Deploy

Measure

Account

Tools