Using Space Automate
Playbooks
A repeatable process, step by step. Fixed where it should be fixed, smart where it needs judgment, and approved by people where it matters.
A playbook is a process written down so it runs the same way every time. It is what Space calls a Managed Agent Graph: a workflow you define and keep, as opposed to the Dynamic Agent Graph Space generates for you on request. Where an agent decides what to do, a playbook follows the path you drew. You can mix the two: a fixed sequence with an agent step for the part that needs judgment, and a human approval before anything goes out.
When to use a playbook
| Use a playbook when… | Use an agent when… |
|---|---|
| The steps are known and must be followed | The path depends on the situation |
| You need approvals at fixed points | You want flexible problem-solving |
| It runs often, on a schedule, or from a trigger | It's a one-off or varied task |
| You need a clear record of every step | The outcome matters more than the route |
They work well together: a playbook can hand a step to an agent, and an agent can run a playbook when told to.
Two ways to look at one playbook
Every playbook can be viewed and edited two ways. Both change the same playbook.
- Sequence view: a simple top-to-bottom list of steps. Easiest for straightforward flows.
- Graph view: boxes and arrows, for branches, loops and jumps. An If step has an arrow for each branch plus “else”.
If a playbook has loops or jumps, the Sequence tab explains that it's available only in Graph view.
Building a playbook
Let the copilot draft it. Describe the process and the copilot proposes steps, variables and a test run. It shows you the result before saving, and won't offer one that can't work.
Try asking
Create a playbook that asks for an order ID, looks up its status in our orders table, and tells the customer. If the order is delayed, have a manager approve a discount first.
Or build it yourself in Playbook › New: add steps from the palette (Input, Output, Actions, Flow), fill in each step, and connect them.
Variables: the playbook's memory
A playbook keeps what it learns in named variables: ${order_id}, ${customer_email}. Every question the playbook asks fills a variable, and later steps can use it.
Variables have a type, and answers are checked against it. If a customer types something that isn't a real email address, the playbook asks again.
| Type | Holds |
|---|---|
| An email address, even picked out of a sentence | |
| Number | A quantity or price (1,250.50 works) |
| Yes/No | A confirmation |
| Date / Date and time | “Tomorrow” and “14 March” are understood |
| ID or code | Something with a known pattern, like P1-1234 |
| One of a list | A fixed set of choices |
| Custom | Something to understand, such as a reason or a name |
| Document | An uploaded file, read into fields |
| Any | Free text |
Secure variables
Mark a variable Secure for PINs, passwords and account numbers. Its value is hidden everywhere except the steps that use it: it's masked from the AI, shown as •••••• in chat, asked for in a password-style box, stored encrypted, and redacted in logs.
Starting values
If you already told the copilot something (“order 4821”), it passes it into the playbook and skips the question. Turn this off for a question you always want asked, such as a final confirmation.
Checking before you trust it
- Validation flags errors that block activating the playbook (a step that goes nowhere, a missing question) and gentle warnings (a step that can never be reached).
- Check runs a mock test down every path through the playbook, with placeholder results and no real actions. It reports each path, what a user would see, and problems like “this path ends without saying anything”.
- Test runs the saved version for real, and you answer its questions in the panel. Be careful: real actions happen.
Draft and active
New playbooks are active right away. A playbook with errors can only be saved as a draft. Each save bumps its version number.
Running one
- In chat: ask the copilot, or pick it from the + menu. It asks the playbook's questions in the chat, and your next messages are the answers.
- From a schedule or trigger: see Schedules and triggers. Because nobody is there to answer, give it its starting values up front.
- From a page button, or from another playbook.
When a run finishes with an end message, that message appears in chat exactly as written, so links and figures can't be reworded.
Every run is recorded
Each step is logged: what went in, what came out, what it said, how long it took, and any error. A failed step is all-or-nothing. The run goes back to where it was before that step.
Retry continues a failed run from the failed step with the current version of the playbook, without redoing earlier steps. Only failed runs can be retried. A completed run is final, because repeating it could repeat real-world actions, so start a new one.
You can watch runs live, and replay them, in Control Room.
Next
Playbook steps, one by one explains every kind of step.