Configure

Every Playbook has a description, availability rules, one or more sections containing steps, and general guidelines. The Playbook editor includes a side panel with four panes, accessible via the icon rail on the right side of the editor.

Runtime harness

While a Playbook runs, the AI Agent continuously monitors the conversation and can intervene automatically — without requiring explicit steps in the Playbook. This built-in behavior ensures Playbooks stay responsive to end user needs even when the conversation takes an unexpected turn.

Intent change detection: If the Agent detects that the end user’s intent has shifted away from the current Playbook, it exits the Playbook and routes the conversation appropriately.
Pause and resume for Knowledge search: When the Agent determines that a Knowledge search would help answer the end user’s question, it temporarily pauses Playbook execution, performs a Q&A search (the same search your AI Agent uses outside of Playbooks), and then resumes where it left off.
Escalation and exit: The Agent can escalate to a human agent or exit the Playbook entirely based on end user input, even if no explicit Handoff or Exit step is configured at that point in the flow.

The runtime harness operates independently of the steps you author. You do not need to anticipate every possible conversational detour — the Agent handles common interruptions on its own.

Side panes

Playbook Details

The Details pane controls the Playbook’s description, usage scope, and access rules.

When to use this Playbook: Describes the situations where the Playbook is appropriate, much like how you would explain its use to a human agent. This is the primary signal the Agent uses when selecting which Playbook to run.
Usage: Check Only available within other Playbooks to prevent the Playbook from triggering on its own. When checked, the AI Agent only uses this Playbook inside another Playbook, not on its own. Use this for child Playbooks that exist solely to support a parent.

Availability rules: Restrict which end users can access this Playbook based on variable conditions. Set to Everyone or configure rules using the following operators:

Operator	Description
Is	Exact match.
Is not	Does not match.
Starts with	Value begins with the specified text.
Ends with	Value ends with the specified text.
Contains	Value appears anywhere.
Does not contain	Value does not appear.
Is set	Variable has a value.
Is not set	Variable has no value.

The description is critical to how the Playbook is selected. Be very clear about the intent that this Playbook corresponds to — vague or generic descriptions reduce selection accuracy.

General Guidelines

The General Guidelines pane is a rich text editor for instructions that apply to all end user interactions in the Playbook. Type @ to reference Actions, Handoffs, Variables, Playbooks, Knowledge articles, and Exit.

The editor supports headings (H1, H2), bold text, bulleted lists, and numbered lists. Use it for:

Tone and formatting specific to this Playbook.
Guardrails and boundaries — what the Agent should and should not do.
Knowledge references — reference articles using @ArticleName mentions or instruct the Agent to search the knowledge base.
Edge case handling — fallback behavior for unexpected situations.

General Guidelines cannot set or write variable values. To write a variable, use a SET or ASK step in the Playbook body.

Knowledge articles are scoped via availability rules configured on the Knowledge page. Reference them using @ArticleName or natural-language search instructions.

Steps

The Steps pane provides a navigable outline of all sections and steps in the Playbook. Each row displays the step number, keyword (SEND, SET, RUN, etc.), and a preview of the step’s target — such as the Action name for a RUN step or the variable name for a SET step.

Click any row to scroll directly to that step in the editor.

Variables

The Variables pane displays all variables referenced in the Playbook. Each variable row shows a reference count. Click a variable to expand it and see every step that reads or writes it, listed by step number and keyword.

Build your Playbook with sections and steps

The body of a Playbook is organized into sections and steps.

Sections

Sections represent stages of the end user journey — for example, “Verify identity”, “Look up order”, or “Process refund”. Each section contains a sequence of steps that execute in order.

Add sections to group related steps and make the workflow easier to read.
Sections execute in order unless redirected by an IF/ELSE branch or GO TO jump.
GO TO can jump to steps in other sections, enabling cross-section flows.

Steps

Within each section, add steps to define what the AI Agent does. The six step types are:

Step	What it does
`SEND`	Send a message to the end user.
`SET`	Assign a variable value silently (Exact value or Use reasoning mode).
`ASK`	Ask the end user for a value.
`RUN`	Execute an Action, Handoff, linked Playbook, or Exit.
`IF/ELSE`	Branch the flow based on conditions.
`GO TO`	Jump to a specific step.

For complete field-level documentation, including modes, validation rules, and examples for each step type, see Step reference.

To add a step:

In a section, click Add Step.
Select a step type.
Configure the step’s fields (for example, the message content for a SEND step, or the variable and instruction for an ASK step).
Click the step icon to open that step’s configuration in the side pane. Applies to ASK, SEND, and SET.

Reference Actions, Handoffs, Exits, and Variables

Playbooks connect to external systems and end user data through references to Actions, Handoffs, Exits, and Variables.

Actions and Handoffs

In any step that supports references, type @ to search for existing Actions and Handoffs. Select one to insert a reference. If no results appear, click + Create Action or + Create Handoff to define a new item without leaving the editor.

Use RUN steps to execute Actions (API calls) and trigger Handoffs (escalation to human agents) at specific points in the workflow.

If your Playbooks trigger Handoffs and you have multiple Handoffs live in your instance, make sure each one has a clearly distinct name and description to improve routing accuracy.

Action names longer than 64 characters can cause errors and fallbacks to the first available handoff. Rename duplicated Actions to keep names short.

Exits

Use a RUN step with the Exit option to deterministically end a Playbook. Type @Exit to find the Exit Playbook option in the reference menu — it appears in the same reference dropdown shown above.

Always use explicit exits at the end of your flows. Every Playbook should have a clear termination point to ensure predictable behavior.

Variables

Playbooks support Global Variables, Sensitive Variables, and Metavariables. Reference variables in any step to personalize the flow.

Reading: Reference a variable to shape logic (for example, check @order_status in an IF/ELSE branch). Metavariables are read-only.
Writing: SET and ASK steps write to Global Variables and Sensitive Variables. Variables cannot be written from General Guidelines.

Always select the @variable pill when referencing variables. Typing variable names manually is not recognized by the system.

Knowledge

Playbooks can reference Knowledge sources — including third-party knowledge bases, Ada-created articles, and web-scraped content.

Direct reference: Use @ArticleName in General Guidelines to reference a specific article.
Native search: The runtime harness can pause Playbook execution to perform a Knowledge search when it detects the end user needs information, then resume where it left off. You can also add natural-language search instructions in General Guidelines to guide this behavior.

Articles cannot be referenced by URL. Knowledge references do not override availability rules.

Link a Playbook

Break large workflows into smaller, reusable components by linking Playbooks together.

How linking works

Linked Playbooks use call-and-return logic: the parent calls a child via a RUN step, the child runs to completion, then control automatically returns to the parent. The child does not branch — it always returns to the exact point in the parent where it was called.

Always end child Playbooks with an explicit Exit (RUN > Exit). Without an explicit Exit, the child may not return control to the parent reliably.

How to link

Use a RUN step with the linked Playbook option. The parent pauses while the child runs, then continues once the child exits.

You can link multiple Playbooks within a single parent with no limit on how many a parent may call.
Treat the top-level Playbook as the parent and all linked Playbooks as children.
Keep child Playbooks focused on a single, structured task to ensure they remain reusable.

Restrict child Playbooks

When a Playbook exists only to support another — meaning it should never trigger on its own — enable AI Agent can only use this Playbook within other Playbooks in the Playbook Details pane. This prevents accidental triggering and reduces misfires.