The assumption worth poking at is that a memory file gets more accurate the more often it is updated. The tidy version of AI updating project memory follows directly from it: end the session, ask the assistant to append what it learned to decisions.md, and the record stays current without anyone having to write prose at 18:30. Nothing rots. Nobody forgets.
Then someone opens that file to settle an argument about why the queue worker retries three times instead of five, finds a dated line that reads exactly like a decision, and nobody in the room remembers making it. The assistant wrote it after a session where retries came up and no conclusion was reached. It sounded plausible, so nobody objected, and now two people have built a week of work on top of it.
The interesting part is that the entry was not wrong. It was mostly right, which is precisely why it went unchallenged.
The pitch: let it keep its own notes
The appeal is real, and it is not laziness. Memory files decay because writing them is the last thing you do when you are already finished thinking. The assistant was present for the whole session, it has the reasoning in its window, and it will summarise six turns of back-and-forth into four lines faster and more neutrally than you will tomorrow. If you have read project memory for AI coding and tried to keep a decisions file current by hand, you already know the drop-off: week one is disciplined, week five is three stale entries and a TODO.
So the pitch stands up as far as drafting goes. An assistant is a good stenographer. The mistake is in what happens next, which is usually nothing.
Where AI updating project memory goes wrong
A memory entry has a strange property: it changes behaviour without being read carefully. The assistant reads the decisions file at the start of the next session and treats every line in it as settled fact about your project. Your teammate skims it during onboarding and does the same. Neither of them re-derives the reasoning, because the whole point of the file is that someone already did.
That makes the file an authority structure, not a notebook. And when the writer is the same party that later cites the entry as a constraint, the loop closes with nobody in it. The assistant inferred a rule in September, wrote it down, read it back in October, and defended it in a code review. At no point did a person agree.
Three specific failure shapes show up:
- Inference promoted to decision. You discussed two options and picked neither. The entry says you picked one.
- Side effect recorded as intent. The migration ran in a particular order because of a bug you were working around that afternoon. The entry says it is the designed order.
- Volume. An entry after every session produces a file that nobody prunes, and the honest entries get buried with the guessed ones. That is the mechanism behind project memory bloat, except now the bloat has the authority of a dated record.
Is "the assistant wrote it" the same as "the team decided it"?
No, and the distinction is worth stating plainly because CLAUDE.md automation tends to collapse it. Drafting and deciding are separate acts. Drafting is summarising what happened. Deciding is committing the project to a position, with someone who will answer for it in three months when the position turns out to be expensive.
An assistant can do the first act well. It cannot do the second at all, because it has no standing to commit anyone to anything and no memory of the constraint it will violate next week. A decision record without an accountable human behind it is a confident sentence, nothing more.
This is the same split that makes instruction files and memory files different objects, which the piece on splitting rules from facts works through in more detail. Here it lands on authorship: the assistant may propose, a person commits.
The review step that costs one line
You do not need a process for this. You need a status marker and a habit.
Let the assistant write AI session drafts into a holding area instead of the record itself:
.prjcontext/memory/
decisions.md # reviewed, committed, citable
drafts.md # proposed by the assistant, nobody has looked
With a standing instruction in CLAUDE.md or AGENTS.md along the lines of: append session notes to memory/drafts.md only. Never edit memory/decisions.md. A draft entry then looks like this:
### 2026-10-08 — Queue worker retry count (PROPOSED)
Claim: retries capped at 3 because the upstream API rate-limits bursts.
From: session "queue worker timeouts", 2026-10-08.
Status: proposed, unreviewed.
Promoting it is a thirty-second job: delete it, or fix the "why" and move it across with Status: Active and your initials. Most drafts get deleted, and that is the step doing the work. The format in lightweight decision records gives you the target shape once an entry survives. Running this decision records review in a batch on Friday is fine; the entries just have to carry the PROPOSED marker until someone looks, so that an unreviewed line never reads like a settled one.
What is safe to automate, and what never is
| Act | Assistant | Human |
|---|---|---|
| Summarise a session into five bullets | Yes | Skim |
| Draft a decision entry with a proposed reason | Yes, as a draft | Commits or deletes |
| Record "we tried X and dropped it" | Draft | Confirms it was actually dropped |
| Mark an existing decision superseded | Never | Only |
| Delete or rewrite a committed entry | Never | Only |
| Record the consequence a decision imposes | Draft | Owns it |
The bottom three rows matter most. An assistant editing history is worse than an assistant adding to it, because the version that disappears is the one that had a reason attached.
Keeping memory in versioned files is what makes the split enforceable rather than aspirational. In PrjLab, .prjcontext/memory/ travels with the code, prj status shows you what a push would capture before it goes anywhere, and every push becomes an immutable version with a line diff, so you can see exactly when a line entered the record and whether anyone touched it on the way in. A drafted entry you disagree with stays a diff you declined, not a silent overwrite of something a person wrote. If you want the file layout and the commands, the getting-started guide has them.
Let the assistant write everything down. Just do not let it be the one who decides what counts.
