Playbooks
Write the job down. Sumn holds the run to it.
A playbook is a short document that describes a recurring job: the stages it runs through, the models each stage may use, what the run may spend, and who signs off before anything ships. Sumn runs that document as a background agent, every time the trigger fires. If the work comes back every week and you could explain it to a capable person in an afternoon, it fits.
Six parts, all of them yours to set.
Every playbook declares the same six things. You write and version them in one place, and the platform enforces them on every run.
The work, in order. Each stage does one job in a fresh isolated VM that exists only for that stage, then hands what it made to the next.
Each stage names the model it may use: a frontier model where the stage has to reason, a cheaper open-source one where it sweeps. Changing the model is one line in the definition.
Checkpoints between stages, judged or held. A judged gate is a model applying criteria you wrote. A held gate waits for a person. Either way, nothing moves until it says go.
A number the platform holds the run to while it happens. At the cap the run pauses warm and asks, or stops. You choose which when you write it.
How a run reaches the world: inputs, outputs and the data sources it loads. Each stage gets the access it needs for its job and nothing wider.
Every run ends in an itemised record: what ran, what it read and wrote, what each stage spent, and who released the result.
The platform treats these six declarations as limits, and it holds them while the run happens. An agent can't overspend the budget, nothing ships until the gates clear it, and the connectors decide exactly what it can reach.
It reads like a checklist, and that's the point.
A playbook describes the job the way you'd brief a capable person on their first day.
The person who owns the process can review the playbook without learning a framework, and a change shows up as a plain before-and-after a reviewer can approve. The process stops living in one person's head.
A stage rolls prompts, skills, tools, inputs and outputs into one definition. Build a review stage once and it works on anything shaped like a review: you point it at new inputs instead of rebuilding it.
The playbook doesn't depend on one model. When a better or cheaper one ships, you change the model in the definition and the next run uses it.
Six playbooks you can start from.
Six examples from six different corners of a company, all made of the same six parts.
Read three incidents over coffee instead of three thousand log lines.
cron 02:00Seven models review the change, disagree, and hand you one verdict.
on a pull requestThe notes write themselves from what shipped, and wait for your edit.
cron fri 16:00Every new lead researched and written up, held before anything reaches them.
new CRM recordAn agent uses the app like a customer, then leaves the tests and the replay videos behind.
on deployEvery cancellation gets an autopsy before your standup, and the save offer waits at a gate.
cancellationThe library is a starting point. Tell us about your process and we'll help you shape it into your first playbook.
Early access
Tell us about your first playbook.
Sumn works today. We're onboarding a small number of teams while we finish the edges, and we order the queue by fit. Tell us the process you'd hand to a background agent and we'll come back to you with what a first run looks like.
A person reads every request and replies; we use your email for nothing else.