> ## Documentation Index
> Fetch the complete documentation index at: https://zenofirm.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# What it remembers

> Coding rules, client knowledge, written procedures, and the log of what was done and why

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.

|                  | For                                | Applies                                     |
| ---------------- | ---------------------------------- | ------------------------------------------- |
| **Coding rules** | This descriptor means that account | By itself, during planning                  |
| **Knowledge**    | Anything needing judgement         | Surfaces when the party it's about comes up |
| **Playbooks**    | Procedures — the month-end close   | When someone runs it                        |
| **Work log**     | What was done, and why             | Read by people, not applied                 |

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

<Note>
  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.
</Note>

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](/docs/quickbooks-desktop/install#installing-across-a-firm).