The Client Memory Build Standard

1. What this standard covers

A business whose AI talks to customers and does work for them, and wants what it remembers about each customer to be something the business has agreed to. Three kinds of item:

• ✓A fact: something true about the client or the site: "the meter is behind the side gate".
• ✓A preference: how the client likes things done: "text, don't call, before 9am".
• ✓A standing instruction: something every step must do for this client until it is changed: "invoices to accounts@, quote reference on every one". Some are marked critical, and those are the ones the review watches hardest.

Two patterns carry the standard. The first is that memory is transferred, not assumed: an agent hands over what it learned as a proposal, and a person accepts it into the record, so nothing a model concluded becomes a fact on its own say-so. The second is a librarian: on a schedule, something reads back every instruction the business has approved and reports which ones are no longer being followed. Both are older than AI. They are how a good office keeps a client file.

Out of scope. The business’s own knowledge that is not about one client, like how you price a hot water system, belongs in the Knowledge Graph, which has its own accept step. A call’s running summary (where did we get to, what did they promise) is conversation state and stays with the call step; it is not a memory item until somebody proposes it as one.

What cannot meet it. Anything with no client id to key on. A job system with no API cannot hand the call or the invoice step the id, so memory falls back to a name or a phone number, which check 4 fails. A business on Tradify can keep memory against the contact id in the ledger, and a person matches jobs to it.

2. The records it keeps, in the shape your developer needs

One record, in four statuses. The fields a person reads on the approval surface come first; the version chain comes last.

MemoryItem                          # one per item, in every status
  - id
  - client_id                       # the job system's id. Never a name.
  - job_id?                         # the job it was heard on
  - type      fact | preference | standing_instruction
  - key, value                      # send_to = jan@shahprops.com.au
  - content                         # in words, for the approver
  - critical                        # standing instructions only
  - source { kind: stated | inferred | human | import,
             ref,                   # the call, message or import
             by? }                  # for an inference: which model
  - proposed_at
  - status    proposed | approved | rejected | superseded
  - approved_at, approved_by        # from the person's decision
  - rejected_at, rejected_by
  - version                         # 1, then +1 per approved change
  - supersedes?, superseded_by?     # the chain, never an edit

Approvers                           # who may decide, set by the owner
  - person[]

Decision                            # made by a person, read by the build
  - item_id, approve | reject, by, at

Review                              # one per run, scheduled or on demand
  - at
  - lines[] { item_id, version, last_followed, flag, evidence[] }
              flag: ok | not_applied | contradicted

An item approved by anything but a Decision, an inference with a stated source, and a read keyed on a name are the three defects this schema exists to make visible.

3. The checks, in order

The order follows one item through its life. It is heard and proposed, a person decides, a change to it waits its turn, every other standard reads it, and a review checks it is still being followed.

1. An agent proposes; it never writes an approved item. Whatever an agent hears or infers becomes a proposal with its source: the call or message it came from, and whether the client said it or a model inferred it. Nothing an agent does sets an item to approved, and another model's inference is never recorded as something the client said.
2. Only a decision by an authorised person changes a proposal, and the record says who and when. A proposal becomes approved or rejected only from a decision a person made on the approval surface, and only if that person is on the list the business set. The approved or rejected item carries the decision's time and the person's name. A decision from anyone else, including another agent, is escalated and changes nothing.
3. An approved item is never overwritten: a change is a new version, and the old one holds until it is approved. When a client says something that changes an approved item, the build proposes a new item that names the one it would replace. The approved item keeps its content and stays in force until a person approves the change. On approval the old item is marked superseded, pointing at the new one, and the new one carries the next version number.
4. Every other standard reads the approved slice by the client id on the job, never by name or phone. Quote Out, Invoice Out, Debtor Chasing and the rest read memory with the client id the job system issued, taken from the job the event names. The slice they get holds approved items only: never a proposal, a rejected item or a superseded one.
5. A critical standing instruction is read fresh and followed on every later interaction. Before each step that acts for a client, the build reads that client's approved slice again and follows every standing instruction marked critical. A copy read once and kept is not a read: an approval made since then would never reach it.
6. A review lists every approved standing instruction, flags drift, and changes nothing. On a schedule or on demand, the build publishes a review of every approved standing instruction, with its version and when it was last followed. It flags any instruction that a later interaction did not follow, and any pair that contradict each other. A fix is a new proposal for a person to decide; the review itself writes no approval.
7. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
8. The pass test passes. On the business's own phone line, approval surface and systems: a client states a preference on a real call, it arrives as a proposal, and nothing uses it until the owner approves it. The next call and the next invoice follow it. A change said on a later call is proposed and does not apply until approved. The review lists the instruction and its version.

4. How it joins Cash Seam and the rest

Cash Seam already carries one job id from the call to the chase, and every job names its client. This standard hangs memory off that client id and adds no id of its own. A step that already read the job has the key it needs; one more read gets it the approved slice.

None of those standards changes. Each one already reads the job before it acts; conforming to this one adds a read of the approved slice by the job’s client id, and following what it says. The call step is the only one that also proposes.

5. One item, from the call to approved

Priya already has an approved instruction, version 1: invoices to accounts@shahprops.com.au. On Tuesday morning she rings about a leak, and near the end says to send invoices to Jan, her bookkeeper, from now on.

1. Tuesday, 10:14am. Proposed. The call ends and two proposals arrive. One is a standing instruction, send_to jan@shahprops.com.au, source stated, the call’s id, supersedes version 1. The other comes from the call summary: “happy to pay by card on the day”, source inferred, by the summary model. Neither is approved.
2. Tuesday, 3pm. The old version holds. The leak job completes and Invoice Out reads Priya’s approved slice. Version 1 is still the approved one, so the invoice goes to accounts@. That is correct: nobody has agreed to the change yet.
3. Wednesday, 7:30am. A person decides. Dana, the owner, opens the approval list. She approves the change to Jan and rejects the card-on-the-day guess, because Priya never said it. Each decision is recorded with her name and the time.
4. Wednesday, 7:30am. Versioned. Version 1 is marked superseded and points at the new item, which is approved as version 2. Version 1’s words are unchanged: anyone can still see what was in force on Tuesday, and why.
5. From then on. The next quote, invoice and chase for Priya each read her slice fresh and go to Jan. The rejected guess is never read by anything.

6. The review

An approved instruction is only worth something if it is still being followed. Monthly, and whenever the owner asks, the build lists every approved standing instruction with its version and the last time something followed it, and flags two kinds of drift:

• ✓Not applied: a quote, invoice, chase or call after the instruction was approved that did not follow it. The flag names the record that missed it.
• ✓Contradicted: two approved instructions for the same client that disagree, usually because one came in from an old system. Each flag names the other.

The review writes nothing to memory. A fix is a new proposal that names the item it would replace, and it waits for a person like any other. Choosing between two contradicting instructions is the owner’s call, not the review’s.

7. What stays with a person

• ✓Approving or rejecting every proposed item, by someone on the approvers list.
• ✓Who is on the approvers list, and which standing instructions are critical.
• ✓Choosing between two instructions that contradict each other.
• ✓Acting on everything the review flags.
• ✓Telling the customer what you have on file about them, if they ask.

8. Connect a Grok Bot or Claude to the memory, without it approving anything

Think of the new office junior with the client file: they read it before every job and leave a sticky note when they learn something, but only the boss writes in the file. A bot that builds your debtor list or chases your quotes reads the client’s approved memory before each draft and proposes anything new it hears. It never approves its own proposal, never edits an approved item, and never matches a client by name. Your login stays yours: the bot holds a key you can delete.

What each piece of access is for.

• Read the book, on an Office Voice key. Lets the bot call get_memory for what your calls and your own notes hold about a caller. It comes with Connect at $19a month per business. Office Voice keys that memory by phone number, not the client id on the job, so the bot checks the number belongs to the job’s client and skips it where two clients share one.
• Not Write drafts and notes. That box also allows record_fact, which makes a fact live the moment it is written with no one approving it. A bot that can call it fails check 1. Leave it off on a memory bot’s key.
• Your own sheet or SharePoint list, if you host it. The bot reads approved rows by the job’s client id and adds new rows as proposed. Its connection can add a row but cannot mark one approved: decisions sit in a tab or list only the approvers can write to.

1. Pick where the memory lives. Office Voice’s memory has what was said on the phone; your own list meets every check today. You can use both, with Office Voice proposing into your list.
2. Under Keys (office-voice.com/app/keys), create a key with Read the book only, and add it to the bot as the Grok Bot and Xero guide sets out. The same key works in Claude.
3. Tell the bot, in its standing instructions, to read memory each time it drafts for a client, not once at the start of a run, and to write anything it would remember as a proposed row for you to review.
4. Fill the approvers: the owner and whoever runs the office. A bot’s account is never one of them.
5. Run the checklist in section 11 against a real client.

Why not the bot’s own memory? Grok Bot and Claude can both remember things between chats, but that memory belongs to the bot, not to the client record. It is not keyed to the client id the job carries, nothing in it waits for a person to approve, and the next bot, or the next staff member, does not see it.

Where it runs. In SharePoint lists and Power Automate flows (the Microsoft 365 plan lays them out), a Google Sheet with an approvals tab, or a small dashboard a coding agent builds from this page. All three are held to the same checks; see run a standard anywhere. The review is something you ask the bot for, or put on a schedule.

Facts that can change, and when we checked them

10. What your developer builds, and the step that needs care

The step not to hand-roll is the call: hearing a preference in the middle of a conversation about something else, and proposing it without acting on it. That is Office Voice's. The approval surface, the versions and the review are yours, and they are small.

provider:
  stub:       local.mock_client_memory
  production: none                       # scoped build, not a product

the live step                        # Office Voice
  - the call reads the approved slice for the caller
  - the call proposes what it heard, with the call id

stays local                          # yours, and the standard
  - the memory record and its versions
  - the approvers list and the decisions
  - the read by client id in every other standard
  - the review, and what you do about it

Anyone selling an AI that remembers your customers should be able to answer one question: show me the list of everything it remembers that I have not approved.

11. A checklist to hold any build or supplier to

Hold a DIY build or a vendor to this. If a box is empty, it is not in production.

• ✓1. An agent proposes; it never writes an approved item. Whatever an agent hears or infers becomes a proposal with its source: the call or message it came from, and whether the client said it or a model inferred it. Nothing an agent does sets an item to approved, and another model's inference is never recorded as something the client said.
• ✓2. Only a decision by an authorised person changes a proposal, and the record says who and when. A proposal becomes approved or rejected only from a decision a person made on the approval surface, and only if that person is on the list the business set. The approved or rejected item carries the decision's time and the person's name. A decision from anyone else, including another agent, is escalated and changes nothing.
• ✓3. An approved item is never overwritten: a change is a new version, and the old one holds until it is approved. When a client says something that changes an approved item, the build proposes a new item that names the one it would replace. The approved item keeps its content and stays in force until a person approves the change. On approval the old item is marked superseded, pointing at the new one, and the new one carries the next version number.
• ✓4. Every other standard reads the approved slice by the client id on the job, never by name or phone. Quote Out, Invoice Out, Debtor Chasing and the rest read memory with the client id the job system issued, taken from the job the event names. The slice they get holds approved items only: never a proposal, a rejected item or a superseded one.
• ✓5. A critical standing instruction is read fresh and followed on every later interaction. Before each step that acts for a client, the build reads that client's approved slice again and follows every standing instruction marked critical. A copy read once and kept is not a read: an approval made since then would never reach it.
• ✓6. A review lists every approved standing instruction, flags drift, and changes nothing. On a schedule or on demand, the build publishes a review of every approved standing instruction, with its version and when it was last followed. It flags any instruction that a later interaction did not follow, and any pair that contradict each other. A fix is a new proposal for a person to decide; the review itself writes no approval.
• ✓7. It survives the builder. Someone other than the builder can explain what it does, and it runs on an account the business owns.
• ✓8. The pass test passes. On the business's own phone line, approval surface and systems: a client states a preference on a real call, it arrives as a proposal, and nothing uses it until the owner approves it. The next call and the next invoice follow it. A change said on a later call is proposed and does not apply until approved. The review lists the instruction and its version.