# 8.3 Restart, summarize or persist (/managing-ai-workers/context-memory-knowledge-and-state/restart-summarize-persist)

---
type: Document
title: "8.3 Restart, summarize or persist"
description: "Three ways to handle a long conversation with an AI Worker, chosen by what you need to keep, and where each kind of information belongs."
status: stable
order: 208.3
ksor:
  owner: team:panaversity
  audience: [ public ]
  approval:
    by: process:panaversity
    at: 2026-10-07T18:30:04Z
chapter: "08"
part: II
expert_status: required
concepts: [ "8.3" ]
last_verified: 2026-10-07
generated:
  at: 2026-10-07T18:30:04Z
  by: esl-rewrite/1.2.0+ksor.1
trust_tier: unverified
build_id: sha256:c93b28093c2f70c60faae2645a693d881b657ff94d00f7dd9f8c06427ff61c87
dirty: true
ksor_version: 0.0.60
---

**In everyday life.** Think of moving a long group chat into a new one. You can just start the new one (restart), post a short summary first (summarize), or pin the group's rules where everyone sees them (persist).

**What you will learn.** What to do when a conversation grows long: start again, carry a checked summary forward, or move what must last to its right place. You practice it in step 1 of the build step.

**Why it matters.** If you do not choose, the product condenses the chat for you, and you cannot tell which details it drops.

When a conversation with an AI Worker grows long, you have three moves, or choices. Choose by what you need to keep. In the table, a **project** is a workspace in an AI product that holds a worker's instructions and files. **Memory** is what the AI product remembers about you from past chats. A project can keep its own memory, called project memory.

| Move | When | How |
| --- | --- | --- |
| *Restart* | The task is done, or none of the history is needed | Start a new conversation in the same project. The project's instructions and knowledge come with it. The old chat's turns, its messages and replies, do not come with it. But project memory may still carry what it learned from them |
| *Summarize* | The task continues, but the history is long | Ask the worker for a handover note, a short summary for the next conversation: decisions made, open items (work not yet finished), files in use, rules agreed. Read the note and correct it. Start the next conversation from it |
| *Persist* | Something must last beyond this conversation | Move it out of the chat, into the place where that kind of information belongs (see the list below) |

To summarize, you can ask: "Write a handover note for a new conversation, with the decisions made, the open items, the files in use and the rules we agreed."

Where to persist each kind of information:

- A standing rule, one meant for every conversation, goes into the project instructions. Maria's rule below is one.
- Approved knowledge goes into KSoR, the Knowledge System of Record, where the company keeps what it has approved as true.
- A preference, such as "reply in plain English," can go into memory.
- The history of one matter, one piece of work such as an invoice, goes into SSoR, the State System of Record. It is the matter's case file.

Current state, where things stand now, is not persisted. It stays in the system that holds it, such as the accounting system. A dated snapshot, a copy of the state with its date, is evidence of what was true then. Recheck the system before a decision.

Two warnings.

1. A summary is the worker's output. Review the summary as you review any other output, because a rule the summary drops, or leaves out, stays dropped.
2. A restart may not cut the new conversation off from old ones, because project memory may still carry what it learned from them. If a detour, an old side topic, keeps coming back in a new conversation:
   - Find the earlier chat that carries it.
   - Delete that chat, or move it out of the project.
   - Then delete any memory saved from it, if the product shows it.

For a matter that runs for days, its SSoR record makes a better handover than a summary. It is not kept in any chat.

At Brightline, the book's example company, the AP Worker is the AI Worker that handles the bills Brightline owes. Early in a long conversation, Maria, the office manager, told it to "always flag Northern Maple to Dave." That meant pointing out Northern Maple's invoices to Dave, the controller. After the conversation was condensed, the worker stopped following that instruction.

The fix is to persist. Maria wanted Northern Maple, a supplier, flagged because its invoices come in Canadian dollars. So she writes the rule she meant: "Flag every invoice not in USD to Dave." USD means US dollars. It goes into the project instructions, where it loads with every conversation. Maria also asks Dave whether the rule should become policy.

![The title reads "Restart, summarize or persist." The line below it reads "Choose by what must survive the current conversation." A dark box asks "What do you need to keep?" Three arrows lead to three panels. No task history needed: restart. Start a new conversation in the same project. Project instructions and knowledge remain available. The panel's foot reads "A fresh chat is not isolation: project memory may still influence it." The unfinished task: summarize. Capture decisions, open items, files and standing rules. Review and correct the handover note. Start a new conversation with the checked note. Its foot reads "A summary is AI output. Check what it leaves out." Information needed beyond this chat: persist. Keep it in the right durable home: a working rule in project instructions, approved policy in KSoR, a preference in memory, case history in SSoR, and current business status in the authoritative system. Its foot reads "Recheck current status before a decision." A banner at the foot reads "You can combine these moves: persist key records, review a summary, then restart."](img/restart-summarize-persist.png)

*Figure 8.4. Restart, summarize or persist. You can also combine them: persist what must last, review a summary, then restart.*