Stop babysitting agents. Start writing playbooks.
Sumn runs teams of repeatable agents for your whole company: deterministic where it has to be, creative where the models shine, and there's a receipt for every run.
Free to start, no card. Bring your own keys and you'll pay us nothing for tokens. Your definitions are just data, so you can export them and walk whenever you want.
file 3 incidents and post the summary to #eng. Nothing gets filed until you say so.waiting since 02:11Write the job down once.
A playbook is a document, not a script. You describe the work, name the stages it runs through, and say what has to be true before anything ships. This one writes the release notes every Friday.
You write a stage once and reuse it anywhere. The reviewer you built for code changes can review your blog posts tomorrow, and every playbook you add makes the next one cheaper to build.
Prompts disappear. Playbooks compound.
From a checklist to a running system, in four moves.
This one's a content pipeline. The four moves don't change with the work.
Do I have to learn a new language? No. You write the instructions in plain English, then name what goes in and what comes back.
What can start a run? A schedule, a message, a merge, a call to the API. Anything that can send a request.
Four machines, six minutes, nothing left running.
Where does it run? Each stage gets its own isolated VM with its own kernel, and it's destroyed the moment the stage ends.
- ✓Reads like us, not like ad copy.
- ✓Every claim has a source.
Passes, on the second try. The first draft had a claim with no source.
What stops it doing something stupid? Two gates. A model checks the work against your criteria, and a person holds anything on its way out.
See what ran, what it cost, and what needs you.
The missing layer is inbuilt observability and oversight.
file 3 incidents and post the summary to #eng. Nothing gets filed until a person releases it.waiting since 02:11File 3 incidents from nightly-log-triage and post the summary to #eng?
Raise the cap on change-review-panel? It stopped at the cap and kept the work.
Take inclusters and write one incident per cluster. Say what broke, when it started, and which deploy it followed. Hold to @incident-criteria.
Every incident needs steps a person can follow to reproduce it. If you can't produce them, say so plainly and hand the cluster back instead of guessing.
Return outincidents as a list the gate can show to a person, one card each.
Six you could get running today.
Clear the queue that lives in your head. These six are the ones people write first.
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.
cancellationWant one built for your team? We'll write your first playbook with you.
What you're actually trusting.
You're not trusting the agent. You're trusting what's underneath it: the part that holds when the agent has a bad night.
Durable
A run outlives the machines it runs on. They can die halfway through. It picks up at the stage it stopped at, and nothing's lost.
Inspectable
Every turn the agent took, every call it made, what it spent, and who's on the hook for it. Readable any time, and yours to export whenever you want.
Recoverable
Work pauses instead of dying. When a run hits a limit, or reaches something a person should decide, it stops warm and keeps what it's done. You pick it up exactly where it stands.
Reliable
The same playbook gives you the same shaped result on run 1 and on run 400. Deterministic where it has to be, and model judgment only where you asked for it.
Sumn enforces, agents request, and an agent can't get around a limit by being clever about it. Teams with platform engineers have been building this in house all year. You shouldn't need a platform team. Read the rest of the guarantees →
This is what we mean by confidence: not that the agent is sandboxed, but that you can see what it did, cap what it spends, and hold what it ships.
Screenshot this one for your CTO. It's the conversation you're about to have.
Match every stage to the right model.
One playbook, many models. Frontier models do the thinking, cheap open source does the sweep, and you swap any of them in the definition the day something better ships. This one researches a new lead.
When gemini-3-pro shipped, it took over the usage stage from a model twice its price. That was one line in the definition, and the next run picked it up.
Multi-model background agents with real rigour are how you keep price, speed, and your own process in your hands.
Triggered from anywhere. Delivered to anywhere.
Keep GitHub, Slack and your issue tracker. Nothing migrates.
If it can send a request, it can start a run. Every trigger →
Stages run. A model judges the work, and a gate holds it until you say go.
Gates hold the artifact until you release it. And many more →
Reach all of it from the API, the CLI, the SDK, or an MCP server.
Know what the work actually costs.
Know what a task, a playbook, or an agent costs your business, so you know where to optimise. Here's what one lead-enrichment run costs, stage by stage.
That's the same run the table above explains. Once you can see which stage spends the money, you can see which one is worth a cheaper model, and which one you should never touch.