Chapter 8. Context, Memory, Knowledge and State

The point

After this chapter you can tell where an AI Worker's answer came from. It can come from five places:

• context: what the worker saw in this conversation
• memory: what the AI product remembered about you from earlier chats
• SSoR, the State System of Record: the record of one piece of work, such as one invoice. It is the work's case file: where it stands, and how it got there.
• KSoR, the Knowledge System of Record: what the company has approved as true, such as its policy
• DSoR, the Data System of Record: what the company's systems say is true right now, such as whether an invoice is paid

You will also be able to:

• decide what to do with a long conversation: restart it, summarize it, or persist what matters. To persist is to move it out of the chat to a place that lasts.
• set up a project, the workspace in Claude or ChatGPT where a worker gets its instructions, its files and its connectors, which link it to other apps
• own a small body of approved knowledge, and keep every copy of it current
• keep an SSoR record of one piece of work by hand, so its history does not depend on any chat

Why it matters

Brightline Wholesale Supply, the book's example company, pays its suppliers' bills once a week, on Friday. The payment run is the list of bills to pay that day. Brightline's AP Worker is the AI Worker that handles the bills Brightline owes. AP means accounts payable. Maria is the office manager. Dave is the controller, who runs Brightline's accounting.

The AP Worker works in the shared project Dave set up in September. The project holds three files:

• AP policy version 3, Brightline's rules for paying bills, which Dave approved on September 1
• a former AP clerk's onboarding notes for new staff
• the payment status list from October 23

One long conversation has run in the project since September 8.

On Tuesday, November 3, 2026, Maria asked the AP Worker four questions. Every answer came back fast and in the right tone. But no answer named its source.

"Has Tri-County's invoice 5149 been paid?" It answered: "No. It is on hold under policy 5.3." Tri-County Freight is a supplier. Section 5.3 of the policy holds every payment to a supplier until a change to its bank details is verified. The worker read its answer from the October 23 status list in the project's files. But 5149 was paid in the October 30 payment run. Dave approved that run. The file was a snapshot, a copy of how things stood on October 23, and nobody had replaced it.

The real history of 5149 was in separate places:

• October 22: Maria's callback note. She had called Tri-County on the number in its vendor record about a request to change its bank details.
• October 23: a hold in that day's payment run
• October 30: payment in that day's payment run

No single place told the whole story.

"Does Buckeye's invoice BO-23104 for $6,150 need Dave's approval?" It answered: "No. Approval is needed only over $10,000." Buckeye is another supplier. On October 12, Maria had briefly mentioned that Dave was "thinking of raising the limit to $10,000 next year." That was saved to memory as Brightline's threshold, the amount above which an invoice needs Dave's approval. But section 4.1 of the policy still says $5,000, so the right answer was yes.

"What do we do when a vendor emails new bank details?" It answered: "Confirm by replying to the vendor's email, then update the record." A vendor is a supplier Brightline pays. The answer came from the onboarding notes, written in 2025. But section 5.1 of the policy says never change a vendor's bank details because of an email. Both files were in the project, and nothing told the worker which one was approved.

"Anything unusual in this week's invoices?" It listed two unusual invoices. It missed a new invoice from Northern Maple, a supplier, in Canadian dollars. In the first week of the conversation, Maria had told the worker to "always flag Northern Maple to Dave." That instruction, to point out Northern Maple's invoices to Dave, was only in the chat. The worker can use only so much of a conversation at once. By November, the early messages had been condensed into a shorter summary to make room. After that, the worker no longer followed the instruction. Memory did not keep it either, because the AI product chooses what memory keeps.

Four wrong answers, four causes:

• an old file nobody replaced
• a remark saved to memory as a rule
• unapproved notes beside the policy
• an instruction lost in a long chat

Asking in better words would not fix them. Each answer came from the wrong place.