Playbooks

A playbook is the reusable process definition behind a workflow.

It answers questions like:

• what outcome are we trying to reach?
• what stages or work items should exist?
• which specialists are involved?
• what should the orchestrator pay attention to?
• where can operators approve, redirect, or request changes?

What A Playbook Contains

In practice, a playbook combines several layers:

• the outcome and workflow shape
• prose instructions that explain how the work should be driven
• role and specialist expectations
• launch-time parameters and input packet structure
• lifecycle defaults for planned or ongoing work
• advanced control settings when a workflow truly needs them

The important part is that the core governance lives in authored process prose, not in a brittle lattice of hidden rules.

Why Playbooks Matter

Without a playbook, a workflow launch is mostly “prompt and hope.” With a playbook, the platform has a real process definition to execute against.

That gives you:

• repeatable workflow launches
• clearer operator expectations
• reusable patterns across similar work
• a better boundary between authored process intent and runtime execution

Community Catalog

Agirunner also ships a shared public catalog in agirunner-playbooks.

That repository is the source of truth for curated community playbooks, specialists, and skills that operators can import from the dashboard. The import model is deliberately simple:

• operators choose one playbook at a time
• the platform fetches that playbook and its referenced specialists and skills
• imported artifacts become normal tenant-local copies
• the platform keeps quiet provenance metadata instead of forcing a new community concept into everyday workflow use

That means the catalog is a starting point, not a lock-in mechanism. A team can import a strong workflow package, then adapt it locally as its own operating process.

Planned vs Ongoing

The dashboard authoring flow supports both:

• planned work for a bounded run toward a specific outcome
• ongoing work for boards or recurring operational processes that stay alive over time

That distinction matters because the operator experience, launch flow, and lifecycle expectations differ.

Where To Work With Playbooks

• use Work Design -> Playbooks in the dashboard to browse and author them
• use the platform API when you want to create, update, archive, or launch them programmatically
• use the runtime only after the platform has already turned the playbook into explicit task contracts