Skip to content
Platform Playbooks

Playbooks

A playbook is how one kind of ticket gets done: the steps in order, a role for each, and a gate between them that reads what the agent reported. Kadmo comes with playbooks for the usual kinds of work, and your admins can make any of them their own.

On this page 8 sections
The playbook Feature Implementation in Kadmo's editor: a Kadmo lane with three SE steps, Investigate + Plan, Implement Fix + PR and Review + Merge PR, each showing what its verdicts do, such as PR_OPEN to continue, BLOCKED to pause and WORK_CONTINUE to run again, beside an external lane that sets the status to In Progress and later In Review, and a ten-minute wait.
A playbook in the editor: each step’s role and workflow, what each verdict does, and the status moves on the tracker’s side.

What a playbook is

Each kind of ticket has its playbook. A step names a role and the workflow it runs, never a particular agent: when its turn comes, the step becomes a job of its own, with its own transcript and cost, and a free agent with that role picks it up.

Beside Kadmo’s lane the editor has an external one. A status block there moves the ticket in your tracker before the next step begins, unless the run has status sync off, and a wait block gives a deploy time to settle.

The issue type decides which playbook a ticket gets: a bug goes to Bug Fix, a story or a task to Feature Implementation, a hotfix to Hotfix. On Linear the first label decides.

Gates

Every workflow names the verdicts its agent can report, and the step’s gate says what each one does. A gate lets the work move on, runs the step again, sends it back to an earlier step, closes the run, or holds it for a person. In Feature Implementation:

VerdictWhat the gate does
PR_OPENThe pull request is up, so the review step starts
WORK_CONTINUEThe agent is not finished, and the same step goes to the next agent
BLOCKEDThe run waits for a person
MERGEDThe change is in, and the run goes on
CONFLICT or CI_FAILThe run holds until someone looks

A verdict the step does not know pauses the run too, rather than letting it through, while a planning step can pass on any comment. At a merge Kadmo also asks GitHub, GitLab, Bitbucket or Kadmo Git, and a pull request it finds still open holds the gate whatever the comment says.

A paused gate looks again by itself when a late comment or merge arrives. On the run’s page a person can resume it, run the step again or override the gate. Work sent back reaches the earlier step with the gate’s findings and the pull request links.

The library

A new account gets its own copy of each playbook Kadmo seeds: Bug Fix, Feature Implementation and Hotfix for delivery, Epic Analysis and Epic Plan for planning, Landing Page Design and Documentation Page for pages, and QA Pass and QA Consolidation for testing. Admins tune them, copy one to change it, or start from a blank canvas.

A chip flags a playbook that needs a role none of your agents has yet, and intake offers only the playbooks your agents can run. Who can run this lists which agent takes which.

The playbook library in Kadmo with nine playbooks, Bug Fix to QA Consolidation in view, each with its slug, a line on what it does, the roles its steps need, its runs and an Enabled switch, with Documentation Page and Landing Page Design marked as needing WRITER and DESIGN, and the two epic playbooks marked sync off.
The library: every playbook the account can run, the roles each needs, and which are switched on.

How a run starts

Most runs start on the Tasks page. Paste a ticket’s key or link, or describe a new problem and Kadmo files the ticket first. Tickets waiting in the task pool start in the order their blockers allow, as many at once as the workspace takes. A goal’s task rows start runs as well, and so can an AI client through Kadmo’s MCP server.

Automations start runs with nobody pressing a button. A rule turns an event in Jira, Linear, Notion, GitHub or Figma, or a schedule, into a run of the playbook it names. Connecting Jira or Notion adds such a rule for you, so assigning a ticket to Kadmo is enough. You can also ask in plain words, with @kadmo on a Jira ticket or a message in Slack or Teams, and Kadmo picks one of the playbooks the workspace allows.

A run of Feature Implementation in Kadmo on the task DW-3 in the workspace Shop: three SE steps done with what their gates read, Comment posted, PR Opened and Merged, a ten-minute wait passed, the QA step Regression Test (Live Site) running, and the buttons Pause, Cancel & mark as done and Cancel & discard.
A run’s page: what each gate read, the step at work, and the ways to hold the run or end it.

What a run leaves on the ticket

The ticket keeps the run’s record. Every agent step leaves its report there, by default one readable comment ending in its verdict, and that comment is what the gate reads. Status changes come from the playbook’s status blocks while sync is on, and a run that ends resolved moves the ticket to done, unless its last block sets a status of its own.

When a run stops and needs someone, Kadmo says so on the ticket after a short wait, and drops the note if the run moves on first. Whoever opens the ticket later sees who did what, and why the run went on. How much each report says is set on Reporting.

The comments on the task DW-3 in Kadmo: three reports from three agents, headed Plan, Built, and Reviewed and merged, each a few lines on what was done, ending with its verdict, COMMENT_POSTED, PR_OPEN and MERGED.
The ticket after three steps: one report per step, each ending in the verdict its gate read.

Questions

What happens when an agent reports no verdict?

On a ticket, a step that expects a verdict stops at its gate and waits for a person, and so does a step that leaves no report at all. Silence is never read as a pass, so an agent cannot wave its own work through by saying nothing.

Do playbooks need Jira?

No. A run works a ticket in Jira, Linear or Notion, or a task in Kadmo Issue Tracking when no tracker is connected.

Can one run use several agents?

Yes. Each step is a job of its own, taken by a free agent with the step's role, so one ticket can pass from agent to agent.

Who can change a playbook?

Your admins. Everyone in the account can open a playbook and read its steps and gates.

Set it up

The playbooks guide covers the editor, the gates, starting a run and the run page. Orchestrating agents explains the workflow behind each step, and Automations the rules that start runs on their own.

  • Goals

    Name an outcome. Kadmo writes the epic, an agent plans it into tickets, and they run wave by wave.

  • AI coding agents

    Agents in the roles you define, each on its own machine, on Kadmo or on yours.

  • Reporting

    The report on the ticket, the notice in your chat, and a video of the job when you ask.