RK.
← Field Notes

August 2026 · 5 min

Using AI as institutional memory, not as a chat window

The default way teams use AI assistants throws away everything that mattered. That isn't a memory problem in the model. It's a missing ritual on your side.

You have a good conversation, you get a good answer, you close the tab. Next week you have the same conversation, get a slightly different answer, and neither version is written anywhere that outlives the session.

Here's the ritual I run across four linked projects: a design constitution, a component system, a pattern library and an internal studio. Each has its own AI project, and all of them have to stay consistent with each other.

Four files, per project

  • PROJECT: what this thing is, what it owns, and what it explicitly doesn't own.
  • MEMORY: current state. What's true right now, including what's unresolved.
  • DECISIONS: ratified decisions, with the decision, the reason, the impact and the status.
  • BACKLOG: what's next, and the open questions blocking it.

Nothing exotic. The value isn't in the files. It's in the two rituals that read and write them.

The session-start ritual

Read the Constitution, then PROJECT, then MEMORY, then DECISIONS, then BACKLOG. Then state the system boundary before proposing anything.

The order is deliberate: governing rules first, current state second, open work last. But the clause that does the work is the last one, state the boundary before proposing.

An assistant that opens with "this project owns patterns, not primitives; component changes belong one layer down" has just prevented the most common failure: a confident, well-argued suggestion that solves the problem in the wrong layer. You catch it in the first sentence instead of at the end of an hour.

The session-end ritual

Summarise what changed. Give me exact edits for MEMORY, DECISIONS and BACKLOG. Do not record proposals as accepted decisions.

That last sentence is the entire mechanism.

Without it, the archive fills with things that sound settled because they were written down confidently. Six weeks later nobody can tell which lines were ratified and which were a suggestion everyone forgot to reject. The document degrades from a record into a mood.

With it, there's a hard boundary between proposed and accepted, and crossing it requires a person. Which is the right place to require one.

The anti-drift ritual

Three projects, one shared constitution. They will drift. A decision gets ratified in one, and the other two carry on assuming the old rule. So there's a scheduled manual sync: compare the decision logs, find the contradictions, and either resolve them or record them as known deviations.

This one is manual on purpose. It's the point where a person reads what accumulated and decides what's still true, and automating it would remove exactly the judgement it exists for.

The weekly cadence

Update memory. Triage the backlog. Record decisions. Fifteen minutes, same slot, every week. Memory decays continuously, not in bursts. A quarterly clean-up is archaeology. A weekly one is bookkeeping.

Why this is worth writing down

The method isn't sophisticated. It's four markdown files and two prompts. What's interesting is that almost nobody does it, and the teams that don't are producing huge volumes of AI-assisted documentation with no way to tell a suggestion from a decision.

The cost nobody budgets forAI makes production cheap and review expensive. Any process that ignores the second half will spend its speed gains on adjudication and never notice where they went.

The rule that travels

If you use an AI assistant on anything that has to stay true for months, you need three things it doesn't give you by default:

  1. A read order that puts governing rules before current state.
  2. A write boundary between proposed and accepted, enforced by one sentence in the prompt.
  3. A reconciliation ritual that a person performs, on a schedule.

Everything else is preference.