Playbooks: the procedure, written down
Per-organization procedures stored as data and served to the agent as prompts, with confirmations it cannot walk past. Plus a discovery ladder in place of a 159k-token route dump, and sales-tax returns computed from billed work.
The Zeno operator, the agent that works your books from a terminal or from Claude, is good at the mechanics and bad at the parts nobody wrote down. Every organization has procedures that live in one bookkeeper’s head: how an insurance remittance gets recorded here, which account the shop’s overage goes to, what has to be true before a batch is posted. Told once in a chat, the agent follows them. Told never, it improvises.
So procedures are data now.
Playbooks
A playbook is a named, versioned procedure stored per organization, edited through an admin surface, and served to the agent as an MCP prompt. Ask the agent to record an insurance remittance and it loads your organization’s playbook for that, which specifies the steps, the accounts, and the confirmations it has to get from you before it proceeds.
/confirm has teeth: a confirmation step in a playbook is a gate the agent cannot walk past by deciding it already knows the answer.
The first playbook ported over is record-insurance, which we had been maintaining as code. Its first run against live books surfaced two wrong claims in the written procedure, which is the argument for keeping procedures somewhere they can be corrected. It now mails the open items after a remittance is recorded, which is what the person doing it always did next.
A discovery ladder instead of a firehose
The operator used to be handed the whole route table on connect: 159,000 tokens of API surface before it had been asked anything. It climbs a ladder now, starting with a module index, then the routes within a module, then the exact shape of one endpoint. The reach is the same and the aim is better, on a fraction of the context.
whois stopped dumping the entire chart of accounts to answer a question about one vendor.
The work log writes itself
Every operator session ends in a work-log entry: what was done, why, and against which records. An idle session gets an automatic stub, so no session ends silently. Every entry has a URL, the log is searchable, and it’s linked from the inbox, so six weeks later “why is this entry here” has an answer.
Sales tax, computed from the work
Sales-tax returns are computed from billed work instead of assembled by hand. The taxable and exempt bases come off the invoices, with the jobs behind each figure one click away. A return has a home page with status actions for computed, filed, and paid, and holds as many attachments as the filing needs. A filed return points at the payment that settled it.
Playbooks are configured per organization; ask us to set up your first one. [email protected].