Make Work Repeatable

Playbooks

Install a ready-made bundle of agents, goals, workflows, and schedules that solve one recurring job.

A playbook is a recurring job already set up for you: instead of authoring the agents, documents, goals, workflow, and schedule a process needs one at a time, you install a bundle that wires the whole thing together in one step. Where the builder is for drawing a process yourself, gallery playbooks are for starting from a broader package that already works. You browse and install those bundles from the gallery in the app, and an agent can propose one for you to approve.

A bundle combines Task Machine primitives

A playbook ships as a bundle: a single description of everything it installs — content folders and documents, skills, agents and teams, goals, workflows, and recurring schedules — plus a small set of setup questions that tune it to your workspace. When a job is explicitly tied to one exact external service, such as a Google Ads campaign launcher, the bundle can also create the connected-service record those agents use. Generic capabilities stay as setup requirements instead: repository access, browser access, and web search or fetch access are described up front rather than guessed for you. A bundle is not a new kind of feature. It is a composition of the primitives the rest of Task Machine already gives you, assembled to solve one job. The bundled Daily Standup playbook is the worked example: a lead agent, a goal, a standup-format document, a draft workflow that gathers activity, composes the standup, and hands off for approval, and a recurring schedule that triggers it each morning. Nothing in it is special to standups — it is the ordinary primitives, pre-wired.

Bundles are curated and installed from one catalog, so the records they create are consistent every time. The pieces inside a bundle reference each other by name — a workflow's approval step points at the member who installed it, a schedule points at its goal — and installing resolves those references into real records together, so a half-installed playbook never appears.

The playbook gallery is the screen in the app where you find a playbook and set it up. The catalog spans marketing, content, SEO, sales, support, engineering, finance, and more, so the gallery groups bundles by the kind of job they do and lays a category bar across the top: pick a category to narrow the grid, or search by name to jump straight to one. Each card names the bundle and summarizes its trigger, job, and expected outcome, so you can see when the work starts, what it does, and what it produces before opening it. It also marks the work with a fitting icon. Bundles already installed in the workspace carry an "Installed" badge.

The playbook gallery with search and category controls above cards that summarize each playbook's trigger, job, and outcome

Opening a bundle gives you a preview before anything is created. Its trigger, job, and outcome lead the review, followed by typed cards for the main records the playbook would install, including agents and teams, workflows, documents, goals, skills, and schedules. Playbooks describe the work each agent owns rather than prescribing provider-specific model alternatives. Installed agents use Auto by default, so Task Machine chooses a high-capability planner from the task's description, complexity, and budget, then matches later stages after the Work Spec makes the execution needs clear. You can still override the automatic choice during installation or choose one fixed model on the agent profile when the job requires it. From the same modal you answer the small set of setup questions that tune it, like the standup's schedule and timezone, choose the project the playbook installs its work into, and install.

The Daily Standup preview showing its trigger, job, outcome, and the records it installs The gallery is browsable read-only for any member, and the install controls appear only for members who hold the playbook:install permission, so anyone can look but only the permitted install.

When nothing in the catalog fits, Create custom in the gallery header is the catch-all. You describe the job you want set up in your own words, and that opens a chat with an agent that designs a bundle from the same agents, documents, goal, workflow, and schedule a catalog playbook ships. You refine it together in the chat, and the agent proposes the finished bundle for approval the same way it would propose a catalog one. It runs as an ordinary Chat turn on the agent's local or managed default worker.

Workflow playbooks are narrower blueprints

A workflow playbook is different from a gallery bundle. It is one workflow definition saved as a reusable blueprint inside the workspace, usually promoted from a proven active workflow. It does not install agents, documents, goals, or schedules. It only duplicates that workflow graph into a new editable draft, including its retry policies, nodes, edges, and branch conditions. Members who can manage workflows can find workflow playbooks in the command center and duplicate one into a draft from there.

Installing a playbook is the moment of approval

A playbook tunes itself to your workspace through its setup questions before anything is created. The Daily Standup bundle, for instance, takes the schedule and timezone its recurring task should follow. The install checks those answers, fills in safe defaults, and only then creates the records. Per-record permissions still apply during creation, so installing a playbook never grants more than you could create by hand.

A gallery bundle reaches a workspace by one of two paths, and the difference is who decides. When a person installs a bundle directly, the act of installing is the approval — the records are created together, and that path requires the playbook:install permission. When an agent proposes a bundle instead, nothing is created yet: the proposal records a pending installation and raises a single approval item to the members who hold playbook:install. The agent can search the same catalog by job, category, and contents before proposing, so it can suggest an existing bundle instead of hand-assembling the records. Approving it runs the same install under the approver. Rejecting it records the decision and creates nothing. That keeps playbooks inside the same draft-and-approve control story as the rest of the product — an agent can suggest standing up a whole process, and a person decides whether it happens. The proposal and its decision flow through your inbox, the same place every other approval lands.

An installed playbook is ready to publish and run

A gallery playbook installs a complete process you can put into operation. The Daily Standup bundle installs its lead agent, goal, standup-format document, recurring schedule, and workflow. The installed workflow starts as a draft, so you can take it into the builder, review the exact steps, publish it, and run it like any workflow you authored yourself. Workflow execution covers what happens next. A workflow playbook starts later in that path: it gives you only the workflow draft, ready to edit, publish, and run. Both paths use the same execution model once a workflow is published.

From here, approvals and verifier gates covers the checkpoints that keep installed and authored processes under your judgment.