Memory and standing context
Memory is a small folder of working lessons, one per file, with one index the agent reads at the start of every session. Standing context is three short files about the owner: what never changes, what matters this quarter, and how today is going.
Where you see it
The owner never opens a memory screen. They notice memory when the agent does not repeat an old mistake. For example, it remembers "always check the calendar before saying a meeting did not happen."
Standing context shows up in tone and judgment. The one place the owner fills part of it in is the morning check-in.
What happens, step by step
- In a session, the owner corrects the agent: "Never send a draft to a client on a Friday afternoon."
- The agent writes one new small file with that one lesson.
- It adds a single short line to
MEMORY.md, the index, pointing at the new file. - Next session, on either machine, the index loads first. The agent sees the line and follows it.
- If one topic grows to 10 or 15 lessons, they get grouped behind one "hub" file. The index still spends only one line on the whole topic.
What powers it
| Part | What it does |
|---|---|
Resources/Memory/ | One flat folder. One lesson per file. |
MEMORY.md | The index. The only memory file that loads every session. Kept short on purpose. |
| A link on each machine | Points the agent's built-in memory spot at the shared vault folder. |
vault-lint rule R6 | Flags the index if its lines or sections get too long. |
dream | A skill that audits memory, proposes cuts, and waits for the owner's yes. |
slow.md, medium.md, today.md | The three layers of standing context. |
Memory is for working lessons and preferences only. Real facts about the company live elsewhere in the vault, filed once.
Why it works this way
The agent's software has a built-in memory feature. It saves memories to a private folder on whatever machine it runs on. It knows nothing about the vault.
That caused a quiet failure. One machine wrote memories that no other machine ever saw. Nothing looked broken. The lessons just never reached anywhere else.
The fix is a link (a folder shortcut). On each machine, the private memory folder is really a pointer into the shared vault folder. So a memory saved "the normal way" lands in the vault and in git. One rule keeps it working:
- Never "repair" the link back into a real folder. It looks odd, and it is on purpose.
A job that runs with nobody watching, like a night job on the box, may only propose a memory. The next session with a person in it decides whether to keep it.
When unsure, memories go in the shared folder. A wrong shared note is visible in git and easy to undo. A wrong private note is invisible, and that is the exact failure this design exists to stop.
When memory gets cleaned up, old files are moved to an archive folder, never deleted.
Standing context: three layers
Before any judgment call about the owner's time, energy, or "should I," the agent reads three files together:
- Permanent (
slow.md): values and who the owner is. - This quarter (
medium.md): current priorities. - Today (
today.md): how the day is going, filled in by the morning check-in. If the owner skipped the check-in, the agent does not guess at their mood.
These are defaults, not walls. Say the owner has a rule like "home by five" because of how things are now. If they are weighing a change that would alter how things are, that rule is something to rethink, not a reason to say no.
Connected to
- One vault, many machines: why both machines must share one folder.
- Housekeeping (vault-lint): the check that keeps the index short.
- The memory guard: what stops bad lessons from being saved.
- Morning prep: where today's layer gets filled in.