Skip to main content
A month of bookkeeping on a client file is mostly repetition, and an agent that starts from nothing every session makes you re-explain the same things. Four things persist between sessions, each holding a different kind of fact. All of it is stored on your workstation, scoped to a company file.

Coding rules

When you correct a coding decision, make it stick: “Remember that AMZN MKTP always goes to Shop Supplies for this company.” A rule fills in coding that was left empty on future batches. It never overrides a value the agent worked out from an actual receipt. Rules are scoped to one company file. Charts of accounts differ between clients, and a rule that crossed files would post to a plausibly-named wrong account in the other file — an error that reconciles cleanly and gets found months later, if at all.

Suggestions and auto rules

A rule is one of two kinds, and the difference is how much coding happens without anyone reading it:
  • Auto fills an empty account or class during planning and notes that it did.
  • Suggest is offered to the agent and can be ignored.
The console’s Coding rules page shows which kind each rule is and lets you move it between them. Promoting a rule to Auto is a decision to let it code unattended, so treat the move as an approval. A rule that’s never been used points at a pattern that doesn’t match what actually arrives. Check it.

Knowledge

Knowledge holds what a coding rule can’t express: a vendor that bills two months in arrears, a customer whose remittances arrive net of a credit, a look-twice cue on an account someone keeps miscoding. “Remember that Coastal Supply invoices two months behind — a March bill is usually January work.” Each entry is anchored to the parties it’s about and surfaces on its own when they come up. A note about Acme Fast Fuel appears when a bank feed line reads ACME FAST FUEL #4417 BROOKLYN NY, because anchors match on normalized names. Nobody has to remember to look anything up. An entry can be marked always relevant instead. Then it’s delivered once at the start of every session, whoever comes up. Use that for standing facts about the client, not for anything a vendor name would find. Results carrying knowledge label it as knowledge. It’s a colleague’s note about the books rather than something read out of the company file, and the agent is told to say so if it acts on one.

Playbooks

A playbook is a procedure written down so it runs the same way every time and can be handed to someone else — a month-end close, a recurring reconciliation. Use {{named}} slots in the body for values supplied when it runs, and declare each one. Running a playbook returns its steps with the values filled in. It changes nothing by itself; the agent carries the steps out with the ordinary tools, so every posting still goes through plan and approve. A playbook with no company applies to every client on the workstation. That’s the common case — a practice runs one close, not seventeen.

Drafts

Knowledge entries and playbooks land as drafts. A draft does nothing — it’s visible, but it never surfaces on its own, and a draft playbook can’t be run.
If something the agent wrote down about a client’s books could apply itself to future work without a person ever reading it, a misunderstanding would become policy. So confirmation is a human step, and the agent is instructed to offer entries for confirmation rather than confirm its own. Editing the body of a confirmed entry returns it to draft. Renaming it doesn’t. Approval covers the content, and it stops the moment the content changes. Confirm entries in the console’s Knowledge and Playbooks pages, or ask the agent to confirm one you’ve read.

The work log

Knowledge needs guarding against entries nobody read. The work log has the opposite risk: entries that never get written. The run journal records what posted and how to reverse it. It can’t say which document a batch came from, why an account was chosen over the obvious one, or what’s still open — and a month later, those are the questions people ask. “Log that I finished March for Ridgeline: bank feed through the 31st, two vendor bills still waiting on approval from Dana.” Two things push the log toward getting written. A session that changes a lot without logging starts seeing a reminder on its results. A session that ends without logging gets a skeleton entry at the next startup, built from what it changed and labelled as machine-written, so it reads as the placeholder it is. Read the log in the console’s Work log page, filtered by company and period, and add entries there by hand.

Where it’s stored

All four live in %LOCALAPPDATA%\Zeno\qb-mcp\qb-mcp.db, alongside the run journal. Point DataDirectory at a network path and a whole practice shares one set — see installing across a firm.