Playbooks for AI coding agents

A prompt is not a process

You can ask a coding agent to plan, build, review and test in that order. It reads the request anew on every run, and over a long task it drifts: a check gets skipped, the agent reviews its own change, or something lands that nobody looked at.

A playbook lives outside the model. Its steps, roles and gates are configuration, so an agent cannot skip a step or merge on a step that does not allow it. The process holds on the hundredth ticket as it did on the first.

What is inside a playbook

Each kind of work has its playbook: a bug, a feature, a hotfix, a documentation page. A step names a role and the job it does. When the step’s turn comes, a free agent with that role takes it on its own machine, works the ticket and reports a verdict, and the verdict decides what happens next.

Playbook · Feature implementation

Ticketyou PlanPM BuildSE Reviewsenior Your turn Approveyou TestQA Merged

Agents with a role, like a team

Every step names a role, and the role sets what an agent may do there. The step that builds opens the pull request and cannot merge it; the merge belongs to the review step, a job of its own; the step that tests reports what it found and merges nothing. Keeping building and checking apart is what catches problems early, as it does in a good scrum team.

Skills and context: what each agent knows

An agent on a step brings three things with it, and together they decide how good the work is, far more than the choice of model.

Agents do not talk to each other. Each step writes down on the ticket what it did and why, and the next step starts from that record. Skill Discovery reads your repositories and your product and writes the pack’s modules for you, each with a confidence figure, so an agent knows the codebase before it touches it.

A gate after every step

Every step ends in a verdict, and the gate decides what it means. A problem stops where it appears instead of travelling to the end of the run, and a gate can send the work back to an earlier step together with its findings and the pull request links.

Silence never counts as a pass: a step with no verdict, or with one the gate does not know, holds the run for a person. At a merge the gate also asks your git host, and a pull request that is still open holds it whatever the comment says.

Every step leaves its report on the ticket

Open the ticket a week later and the run is still there: who did what, which verdict each gate read, and why the work moved on. Because the steps are fixed, you can measure each one, and an improvement written into the playbook applies to every run after it.

• Plan · PM agentPlan written, 5 subtasksPassed
• Build · SE agent6 files changed, 14 tests addedPR open
• Review · senior agentMissing test for an expired cardBack to build
• Approve · youApproved, ready to mergeYour turn
• Test · QA agentPassed on the live sitePassed

A model for each step and a known cost per ticket

Planning and review can run on a strong model while routine steps take a fast one, so the cost follows the difficulty. A step names an effort tier, you decide which model stands behind each tier, and the run’s page shows what the whole ticket cost. Kadmo serves Claude and GPT models and takes your own keys where your plan allows them, and the agents run on Kadmo’s machines, in your cloud account or on your own server.

Ready playbooks for the usual work

Every account starts with its own copy of the playbooks Kadmo ships. Your admins tune them in the editor, duplicate one to change it, or build a new one on a blank canvas.

Which playbook a ticket gets follows from its issue type, so a bug and a story take different routes without anyone choosing. Assign a ticket to Kadmo in Jira, Linear or Notion, write @kadmo on it, or start a run from Slack or Teams, and the right playbook picks it up.

How it starts

It starts with a call. In 30 minutes we go through how your team gets a ticket done today and pick the one process a playbook takes first. The pilot runs on your own tickets, and its numbers decide what comes next. The plans that include agents and playbooks are on the pricing page.

• Call · you and KadmoOne process of your team, walked through and scoped30 minutes
• Pilot · the agentsA playbook works real tickets from your backlogTwo weeks
• Decide · youTickets done, review verdicts and cost per ticket, side by sideYour call
• Rollout · your teamMore processes, your own playbooks, agents where you want themRunning

Set it up

Open the library under Settings, duplicate a seed or build one on the canvas, route each verdict at its gate, map your issue types with issue type routing, and start a run from the Tasks page. A rule under Automations starts a run on its own, from a tracker event or a schedule.

Questions