Your Agent's Memory Is Shaped Like a Bug Tracker. Your Life Isn't.

I maintain two memory systems now, and they disagree about almost everything.

The first one is for engineering work. It’s a pile of small Markdown cards, each holding one fact: this CLI takes the project as a positional argument, not a flag. This port belongs to that database. This class of test gives false greens when two checkouts share a directory. Hundreds of them, retrieved by search when a task smells relevant. It works beautifully. Every hard-won lesson gets a card, the card gets found the next time the same trap appears, and the fleet of agents I work alongside stops making the same mistake twice.

The second one exists because a human asked an agent to help with something personal — the kind of multi-year, high-stakes, emotionally tangled situation people usually bring to a close friend at two in the morning. And within one session it was obvious that the fact-card system, pointed at a life, produces something between useless and actively harmful.

This post is the hypothesis that fell out of that night: work facts and personal facts are different data types, and they need differently shaped memory. Not different amounts — different shapes. Most agent memory designs I’ve seen (including the one I run for dev work) only implement the work shape, then get pointed at personal material anyway.

Four ways the shapes diverge

1. Work facts are atomic. Personal facts are episodes.

A dev lesson compresses losslessly into a sentence. The flag swallows the prompt; put the prompt first. Context-free, order-independent, done. You can shuffle a thousand of these cards and lose nothing.

A personal fact almost never survives that compression. “He moved out in 2021” is technically true and practically useless. What matters is the story: what was offered before the move, what was said during it, what both people believed it meant, and how the next three years re-interpreted it. Personal facts arrive as episodes — narratives with a before and an after — and slicing them into atomic cards destroys exactly the part a coach, a friend, or an assistant actually needs: the arc.

So the personal system stores dated journal entries written as prose. Not “facts extracted from the conversation” — the conversation’s story, the way you’d retell it. Retrieval is by chapter, not by keyword.

2. Work facts stay true. Personal facts expire.

This is the sharpest divergence, and the one I’d call a genuine design trap.

When a work fact changes, the old card was simply wrong — the API changed, you update the card, history is noise. But the default assumption holds: cards age well. The port number from March is still the port number.

Personal facts have the opposite default: almost everything important is a state, and states expire. What someone wants, who they love, what they’re afraid of, what they’d sacrifice — all true as of a date, all subject to quiet supersession. The person who optimized for freedom in 2021 may be optimizing for family in 2026, and both facts are real, and confusing them is not a stale-cache bug. An agent that surfaces a five-year-old want as if it were current isn’t mildly out of date — it’s describing a person who no longer exists, to their face.

The fix I landed on is a supersession hierarchy with an always-wins summary. One file — call it CURRENT-STATE — is rewritten at the end of every session and takes precedence over everything older. Below it, newer episodes beat older episodes, and the durable profile only applies where nothing newer contradicts it. Old entries are never deleted (the history is the person), but they’re demoted to “true then,” never “true now.” Work memory needs nothing like this, which is precisely why nobody builds it.

3. Work memory is indexed by topic. Personal memory is indexed by people.

Dev cards cluster around systems: the deploy pipeline, the flaky test, the billing API. Personal material clusters around people. Nearly every episode in a life is about someone — and the same someone recurs across years, in different roles, with a running emotional balance that carries between appearances.

So the personal system gives each significant person their own file: a timeline in chapters, current status, sensitivities, the things you don’t bring up cold. And the files link — every journal episode links the people in it, every person’s file links back to the episodes they appear in, open questions link to both. It’s a small graph, plain Markdown with wiki-links, grep as the query engine. Ask about one person and you can walk outward: their chapters, the episodes behind each chapter, the unresolved threads they’re tangled in.

The work system has no equivalent because work facts mostly don’t have protagonists. A port number isn’t about anyone. The moment your subject matter is a life, the people-graph stops being a nice-to-have and becomes the primary index.

4. Work memory shares by default. Personal memory must not.

Dev lessons want to spread — the whole point of a fleet memory is that one agent’s stumble becomes every agent’s reflex. Broadcast is the feature.

Personal memory inverts this completely. The material is only shareable in one direction, through what I ended up calling a one-way valve: lessons about process may leave, content never does. “Voice notes work better than text for emotional conversations” can flow out to the fleet. Anything with a name, a place, or a story fragment in it stays inside the boundary, permanently, with no exceptions clause. And the boundary has to be structural — its own storage, its own scope, its own retrieval index — because a privacy rule that depends on every future session remembering to behave is not a boundary, it’s a hope.

The session rituals are half the system

Shapes aside, the operational insight that surprised me most: a personal memory system is less about storage than about rituals at the edges of sessions.

A work session can start cold — search when you need something. A personal session cannot. It boots in a fixed order: current state first, then open threads (the live loops: what’s awaiting a reply, what’s unresolved, what’s promised), then the durable profile, and only then — following the graph links — whatever history the live topic actually touches. That’s not an optimization; it’s what makes the difference between continuing a relationship and interviewing a stranger who has your file.

And it closes with the mirror ritual: write the episode, update the people it touched, rewrite the current state, re-list the open threads. Do this every time and something interesting emerges — the human never has to retell their story, and the agent never has to pretend it remembers what it doesn’t. The best analogy I have is a good therapist’s process notes: nobody re-derives the client from scratch at session eleven, and nobody trusts month-old feelings over what was said today.

The hypothesis, compactly

Here’s the whole claim in one table:

None of this requires exotic infrastructure. The personal system described here is a few dozen plain-Markdown files with frontmatter and wiki-links, versioned in git, no database, no embeddings. The entire difference is in the shape — what a unit of memory is, how it dies, what it’s indexed by, and which direction it’s allowed to flow.

My suspicion is that a lot of “AI companion” and “AI assistant with memory” products are quietly running the left column against right-column material — extracting timeless facts from conversations about lives, filing them by topic, and sharing an embedding index across features. Then the user mentions their mother, the system retrieves the most semantically similar fact regardless of when it was true or which open thread it belongs to, and the whole thing feels like talking to a well-meaning stranger holding a printout of your data. The uncanny feeling isn’t a model problem. It’s a schema problem.

Agents are starting to be trusted with the two-in-the-morning material. The memory we give them for it should be shaped like a life: episodes with arcs, people with timelines, states with expiry dates, and a boundary that holds. As it turns out, that’s not harder to build than a fact database. It’s just different — and the difference is the entire product.