Playbook Tools

Reusable orchestration templates. Define a process once, then run it against any customer to spin up a whole project of tasks and external actions.

Every founder has a handful of processes they run again and again: onboarding a new customer, kicking off a project, closing a deal. Playbooks let you define one of those processes once, then run it against any customer to create the whole set of tasks - and, when you have the right connectors, fire off external actions like creating a repo or posting to Slack.

See it in action: ask your AI to “run the playbooks demo” - a guided walkthrough on temporary data that cleans up after itself. More about demos.

What you can do

“Create a playbook for onboarding new customers.”

“Add a step: send the welcome email, due 2 days after start.”

“What does the new-deal playbook need before I can run it?”

“Run the customer-onboarding playbook for Acme, starting Monday.”

“Show me every run of the onboarding playbook.”

Tools

Define a playbook

Tool	What it does
`create_playbook`	Create a named, reusable playbook
`get_playbook`	View a playbook with all its steps
`update_playbook`	Rename or re-describe a playbook
`remove_playbook`	Delete a playbook (past runs are kept)
`list_playbooks`	See all your playbooks

Manage steps

Tool	What it does
`add_playbook_step`	Add a step - either a native task or an external action
`update_playbook_step`	Change a step’s content, timing, or order
`remove_playbook_step`	Remove a step

Run and review

Tool	What it does
`run_playbook`	Execute a playbook against a subject (e.g. a customer), creating tasks and firing actions
`get_playbook_run`	The full execution log for one run
`list_playbook_runs`	Run history for a playbook

Two kinds of steps

A playbook step is one of two types:

Native task - creates a regular FoundersOS task, linked to the subject of the run. These behave exactly like any other task: due dates, assignees, tags, dependencies.

External action - calls a connected MCP tool. A step carries a connector (like GitHub or Slack), an action, and a params object. If that connector is available when the playbook runs, the action fires for real - a repo gets created, a message gets posted, a calendar event gets scheduled. If the connector is not available, the step gracefully falls back to a tagged [manual] task so nothing silently drops. The playbook always completes.

Placeholders

Steps can reference the run’s context with placeholders that resolve at runtime:

{{customer.name}}, {{customer.slug}} - the subject of the run
{{contact.primary.name}} - the customer’s primary contact
{{playbook.start_date}} - the date you started the run
{{playbook.start_date+Nd}} - N days after start (e.g. +3d for a due date)
{{memory:key}} - a value pulled from your semantic memory

So a welcome-email step due {{playbook.start_date+2d}} lands two days after each run begins, no matter when you run it.

A run in practice

You: "Run the customer-onboarding playbook for Acme, starting today."

AI:   run_playbook({ playbook: "customer-onboarding", customer: "acme", start_date: "2026-06-01" })

      Onboarding Acme Corp  -  6 steps

      Created tasks:
        - Send welcome email to Sarah Chen      (due Jun 3)
        - Schedule kickoff call                 (due Jun 4)
        - Prepare onboarding doc                (due Jun 6)
      External actions:
        - Created #acme channel in Slack
        - Created acme-onboarding repo in GitHub
      Fell back to manual task:
        - [manual] Add Acme to billing system   (no connector)

      Run logged. View it anytime with the run history.

Check get_playbook_run for the detailed log of what fired, what fell back, and why.

Where playbooks fit

Playbooks are the orchestration layer over the rest of FoundersOS. They create Tasks, can anchor a whole Project by tagging their tasks consistently, and reach into your connected tools through MCP. Define the process once; run it on autopilot every time.

PreviousProject Tools NextTag Registry