On Persistent MemoryHelping AI Remember You · Working Memory Across Sessions

Work with AI long enough, and you will notice something particularly annoying: it has no memory.

Every time you start a new session, the last argument, the last decision, the last mistake all go back to zero. You either explain everything again or quietly accept that it will make the same mistake again.

At first I thought this meant “AI isn't capable enough yet.” Later I came to see that having no memory has little to do with how capable AI is. It comes down to the boundary of a session. Each conversation is a separate process. When it exits, everything resets, which is as reasonable as restarting your browser.

So the question is not “how do we give AI a memory?” It is how to make memory an external protocol that every new session can pick up from.

Memory Is Not a Chat Log

The simplest idea is to save every conversation and feed it back in when the next session starts.

I tried this. It doesn't work, for three reasons:

First, conversations are too wordy. In a chat log of 10000 characters, perhaps only 200 characters are actually useful. The other 9800 are things said along the way: “Okay, let me try” / “Wait, let me look” / “Could you explain that bit again?” Feed it all back in, and it is mostly noise.

Second, conversations depend on their sequence, but memory needs to stand apart from it. References like “you just said” mean nothing in a new session.

Third, conversations contain plenty of information that was correct at the time but is now out of date. “We decided to use option B.” Later, we switched to C. If you feed the conversation back unchanged, the “facts” AI sees may already be wrong.

So memory cannot be a chat log. It has to be an external brain that is structured, independent of conversational sequence, and regularly updated.

Four Types of Memory, Each Written Differently

The memory system I use now has four types. Each has a different purpose and is written differently.

① user — who you are. The user's role, goals, background knowledge, and preferences. For example: “Han is the CTO of GGBOYS, communicates in Chinese, and usually goes through test before prod.” This type of memory stays stable once written and rarely changes.

② feedback — what you have corrected me on. The user's instructions, rules, and ways of working. For example: “Deployments must be verified in test before going to prod.” This type of memory is central to the discipline of working together.

③ project — who is doing what, and why. The current project's status, decisions, and context. For example: “We are working on the unified order system v3 because the 7 little tables from 2024 can no longer cope.” This type of memory goes stale and needs regular cleanup.

④ reference — where external systems are. Not the knowledge itself, but pointers to it. For example: “The bug list is in ggboys-sheets MCP, sheet ID = xxx.”

Each of the four types has its own job. They stay separate.

The Discipline of Writing Feedback Memory

Of the four types, feedback is the most important and the easiest to get wrong.

A typical “good enough” version looks like this:

feedback: deployments must go through test before prod

It looks fine. But when I read it again six months later, I have forgotten why. Is prod too fragile? Does the test environment have a particular validation process? Or did something go wrong once?

Once I forget “why,” this feedback starts to lose its force. The next time a deployment looks “simple enough that nothing could go wrong,” I might skip test and go straight to prod.

Good feedback memory therefore needs three parts:

· The rule itself: one line saying clearly what to do or what not to do.

· Why: where the rule came from — a particular mistake, a user preference, or a specific situation.

· How to apply: its scope — when it applies and when it does not.

A real example:

Rule:  The initiator of a cross-service saga must actively advance it inline to COMMITTED.
       The reconcile cron only verifies; it does not actively acquire locks.

Why:   On 2026-04-15, the main execution path of a cross-service saga crashed. The cron's fallback
       lock collided with a retry on the main path. The state machine advanced twice, and the user
       was charged twice, then refunded once. The experience was worse than getting stuck.

How:   Applies to all cross-service sagas (admin_service ↔ steam_auth).
       Does not apply to state machines within a single service (a cron fallback is fine there).

Written this way, the memory lets me (or another agent) judge two things immediately when we read it six months later:

· Does this rule still hold? (The Why section: check whether the cron fallback is still there.)

· Does it apply to the change I am making? (The How section: is this a cross-service saga?)

Feedback without Why and How is a lifeless rule. It will be followed indiscriminately for a while, then ignored indiscriminately, then quietly forgotten.

Project Memory Goes Stale. We Have to Admit It.

Of the four types of memory, project memory decays the fastest.

“We are working on X.” Three months later, X may already be done. Six months later, the entire direction may have changed.

So project memory needs regular review. These are the rules I follow now:

· Run /memory before each session ends to tidy things up (add entries, update them, and mark stale ones).

· Actively update project memory when a user message says “it is now month X” / “we did Y last week.”

· Always convert relative times (“Thursday,” “next week”) to absolute dates (“2026-04-30”) before writing them down. Otherwise, the memory will be unreadable a week later.

There is a deeper point here: stale project memory is worse than no memory. It lets an agent run further on false assumptions.

Memory Is a Protocol Layer Across Sessions

By this point, you may have noticed that memory and the handoff document discussed in the previous article (№ 007) are two forms of the same thing.

A handoff document: a one-time protocol across sessions and agents. “I write now; you read later.”

Memory: an ongoing protocol across many sessions, possibly involving many agents. “From now on, everyone reads from here.”

Both put state on disk so that an agent at a later moment can pick it up. The only difference is the time scale.

This way of looking at it made me realize that the core skill in working with AI is not really prompt engineering. It is the ability to write documentation for your future self. Every handoff, every piece of feedback memory, is a note left for some agent at some future moment. That agent might be AI, or it might be me a few months later, having forgotten the details.

One Bad Example and One Good One

A bad example: Early on, when I was working with Claude, I piled everything “important” into one enormous CLAUDE.md. After a year, it had more than 4000 lines. Reading it used up a lot of the agent's context each time, and the agent often could not find what it needed. It only became usable after I split it into an index and separate files, with reading directed by task type.

A good example: A 60-character piece of feedback memory once prevented an incident. The rule was: “For code changes written by AI, any git commit must be made by AI itself. Do not wrap AI changes in a manual commit, or audit traceability will be lost.” Six months later, during an urgent fix, the agent was about to run a commit for me. On seeing this memory, it immediately switched to “the patch is ready; please commit it yourself,” avoiding a commit with unclear responsibility.

This is the real value of memory: it does not make AI “smart.” It automatically reestablishes the boundaries of working together in every session.

Closing — The Real Asset Is the Incident Archive

I increasingly believe that a team's real asset, whether the team consists of people or people + AI, is its incident archive, not its codebase.

Code will be rewritten, frameworks replaced, and colleagues will come and go. But the notes saying “we ran into this problem back then, so we no longer do X” are what actually accumulate across time and across people.

Memory is an incident archive for AI. A handoff document is an engineer's notebook for AI. Both are doing the same thing: turning short-term, fleeting insights from the present into lasting, stable knowledge that can be read in the future.

This has nothing to do with AI, LLMs, or prompt engineering. It is a discipline anyone who takes their work seriously needs. AI has simply amplified its effect, because AI really does act on the memory you write, and its “goldfish memory” forces you to do this properly.

Seen this way, AI makes us better engineers, not because it writes code for us, but because it forces us to put on paper what used to be jumbled together in our heads.

Translation log: translated from the Chinese original by Codex on 2026-11-03, 17:51–17:53 (US Eastern). Main thread GPT-6 Astra (gpt-6-astra), reasoning effort ultra; it spawned 1 sub-thread: 1 on GPT-6 Astra (effort ultra). Together they read 334,461 tokens (306,432 of them from cache) and wrote 6,908 (1,449 of them reasoning).