Playbooks

A task written down by a strong model so a cheaper one can follow it, and the record of which models pass it.

What a Playbook is

A Playbook is a task your best model did once, written down so a cheaper model can do it again without that model's judgement. It holds numbered steps, the rules behind every decision, worked examples with the exact input and the correct output, a done check, and the pitfalls. Every time an agent runs it, Sirro records which agent and which model ran it and whether it passed.

That record answers one question for you: what is the cheapest model that still does this job?

Playbooks are live in the coding library today. They are different from the planned personal-agent Playbooks, which are still in development.

Why

The strongest model is the most expensive one. Most recurring work does not need it: classifying invoices, checking a supplier's details against their documents, triaging tickets, applying a style guide. It needs the strongest model once, to work out how the task is done well. After that the method is the valuable part, and a method is cheap to carry.

Sirro's thesis is that the best teams will not be the ones with the best prompts, but the ones with the best library of proven work. A Playbook is proven work for a task rather than a piece of code: the steps are the asset, and the run log is the proof. The strong model writes the Playbook. Cheaper models follow it. The log tells you how far down the price list you can go before quality drops.

How it works

Do the task once with a strong model. Nothing changes about how you work.
Say “save this as a playbook”. The agent asks Sirro for the capture guide, which tells it to write for a model weaker than itself: one decision per step, every judgement call as an explicit rule with an example, at least two worked examples from the task, and how to know it is done. It states which model it is. Then it saves the Playbook by name.
Run it with a cheaper model. Say “run the invoice-classification playbook from Sirro on this” to any connected agent. The agent fetches the steps, opens a run, and follows them exactly. If the Playbook has examples, the agent works those through the steps too.
Close the run. The agent reports the result of the done check, the checks it ran, its answers to the examples, and its model. Then it asks you one question: did this succeed?
Read the ladder. Your library lists the models that tried, cheapest first, with how many judged runs each passed. The first one that passes is the cheapest model that does the job.
Tighten when a cheaper model fails. Ask a strong model to rewrite the steps the cheaper one got wrong. That makes a new version, and the ladder starts again for it. Runs stay attached to the version they followed, so old results never mix into a new method.

What counts

An agent's own report is shown but never counted. A weak model claiming success is exactly the case the ladder exists to catch. A run counts in one of two ways:

You confirmed it. In chat, when the agent asks whether the task succeeded, or later with a tick or a cross in the library. Your word beats everything else.
Sirro graded it. When a Playbook has worked examples and the agent answered all of them, Sirro compares the answers with the correct outputs. A fully graded run counts without anyone being asked.

A model passes when it has more judged passes than fails. The cheapest pass is the first such model on the price ladder. Models Sirro does not recognise stay out of the ladder, so an unknown name can never be reported as the cheapest option.

What it saves

Model cost. Recurring work moves to the cheapest model that passes, and you have the evidence for that choice rather than a guess.
Re-explaining. The method is written once, by the model that worked it out, in the form a weaker model needs. Nobody re-describes the task in every session.
Silent regressions. Every run is logged against a Playbook version, so a change in model or method shows up as a change in the pass rate, not as a surprise weeks later.
Review time. Worked examples let Sirro grade a run on its own. People confirm only what the examples cannot cover.

The net saving depends on the work avoided and the cost of running and checking the Playbook. The run log gives you the numbers for your own tasks; read Compute and reuse for how to measure a whole task.

What the agent uses

sirro_playbook_guide
The versioned capture guide. Called before a save, so the Playbook is written for a weaker model.
sirro_save_playbook
Saves the steps, rules, examples, done check and pitfalls under a name. Saving the name again makes a new version.
sirro_playbook_start
Returns the Playbook, opens a run, and says which model is already known to pass.
sirro_playbook_finish
Closes the run with the agent's report, its evidence, its example answers, its model, and your answer.

Connected agents get these tools and the routing rules for them automatically. You can also upload an existing written procedure from your library with the plus button; it runs the same way, with no author model recorded.

An example

A finance team classifies invoices every month. The first batch is done with the strongest model available and saved as invoice-classification: seven steps, three rules such as “no line items means Other”, and four worked examples. The next batch is run with a mid-priced model, which passes. The one after that is run with the cheapest model, which fails two of the examples. A strong model tightens the step that caused it. Version 2 passes on the cheapest model, and that is the model the team runs from then on, with the ladder as the receipt.

Limits

Sirro cannot see which model a coding agent is running. The agent reports it, and you can correct it on any run.
A run without a finish call reads as no report after a day. It is never counted.
Grading compares answers with the stored correct outputs after normalising case and spacing. Open-ended outputs still need your confirmation.
A Playbook improves the saved method. It does not change the models themselves.