The case of the amnesiac assistant

The question that started it

Here's the question that started this whole mess: why was I explaining the same thing to an AI in August that I'd already explained to it in March?

Not once. Not twice. On a loop. Every new chat started from absolute zero: no memory of the job search pipeline I'd built, no memory of which CV claims were verified, no memory of the fifteen decisions I'd already made and justified and moved past. I was the only continuity the system had, and I am, demonstrably, not a reliable filing cabinet.

So I went looking for one. What followed was less "quick weekend project" and more an actual investigation into where information should live, how AI tools quietly corrupt the things they're supposed to protect, and why a folder structure I sketched on day one lasted about a day. Claude.ai did the planning and governance thinking with me; Claude Code did the actual building. Both, it turns out, needed the same second brain to stop forgetting who they were talking to.

Where does information even go?

First question, and it turns out to be the load-bearing one: WHERE does a "second brain" actually live, if it needs to survive across multiple AI tools and not just one chat thread?

The tempting answer is "wherever the AI tool wants it": inside its own memory feature, locked to that one product. I rejected that almost immediately. Lock your knowledge into one vendor's memory system and you've just built a very elaborate trap for yourself.

Landed on Google Drive. Boring, unglamorous, and exactly right for the job: any AI tool can read it, I own it, and it doesn't vanish if I switch which assistant I'm talking to this month. Not the most secure option on the table, since Google holds the keys rather than me, but security and portability turned out to be two different problems, and I wasn't going to solve both before building anything at all.

Who decided folders should work like this?

Confession: my first folder structure was completely made up. README, Decision Journal, UX Knowledge, Career, Reference. A taxonomy invented in an afternoon, before a single real piece of work had passed through it.

It lasted ONE DAY.

Turns out there's a whole existing methodology for this: PARA (Projects, Areas, Resources, Archive). The moment real work started flowing through my system, my bespoke folders buckled and PARA's shape fit almost immediately. The "Decision Journal" idea didn't die, it just got demoted, filed inside Areas instead of sitting up top pretending to be the main event.

Lesson buried in there: a taxonomy you invent before you've used it is a guess wearing a folder icon. You don't find out if it's right until something real tries to live in it.

The mystery of the shrinking decisions

Here's where it gets genuinely alarming. Sometime in mid-2026, I noticed something was off in my Decision Log. Three entries, decisions I knew I'd written with full reasoning, had lost their reasoning. Just... gone. Outcome still there. The "why" behind it, missing.

WHO did this? Turns out: I did, sort of, by accident, via the AI itself.

The culprit was file size. Past a certain point (somewhere around 20KB, it turns out), an AI asked to edit a big document doesn't always edit it. It silently rewrites the whole thing, and rewriting is exactly when compression creeps in. Older entries get quietly summarised to save space. Nobody asks permission. Nobody flags it. It just... shrinks.

The fix, once I understood the disease: never let one file hold the whole history. I split the Decision Log into three roles: a tiny STATE file for current facts (rewritten in full each time, and small enough that rewriting it is safe), an append-only LOG that never gets rewritten wholesale, just added to, and a stable REFERENCE file for detail that barely changes. A small index on top says which chunk has what. Nothing gets summarised into oblivion again, because nothing ever gets fully rewritten unless it's already tiny.

Attack of the duplicate IDs

Splitting the log into chunks solved the shrinking-decisions mystery. It promptly created a new one.

Google Drive sorts files alphabetically. My freshly-created "Decision Log Index", the file meant to be read FIRST, always, was sorting AFTER "Decision Log 001." The map was hiding behind the territory.

Fix: number every chunk with a leading digit, so alphabetical order and reading order finally agree. Simple enough. Except mid-project, renaming that numbered cluster once went sideways. A rename operation created a blank chunk instead of carrying the old content forward, and for one uncomfortable stretch, a real decision was sitting in a file marked for deletion as "superseded." Two decisions briefly claimed the same ID before anyone caught it.

Nobody lost data, in the end. But it was close enough that it became its own rule: touch one file in a numbered set, and you rename the WHOLE set, and update every pointer to it, in the same edit. Never as a "quick follow-up."

So what actually works?

If you're building something like this, for a job search, a portfolio, a body of client work, anything an AI needs to read back reliably, here's what survived contact with reality:

1. Pick a home you own, not one the tool owns. Portability beats convenience if you're using more than one AI tool.
2. Don't design the folder structure before you've used it. Let real work tell you the shape. PARA (or something like it) is a reasonable starting skeleton, not a finished building.
3. Record why, not just what. The outcome of a decision fades in value. The reasoning behind it is what actually saves you from repeating a mistake.
4. Cap your file sizes. If an AI can rewrite a whole document in one move, it eventually will, and compression is the silent failure mode nobody warns you about.
5. Never touch one file in a numbered set alone. Rename, re-point, and verify together, or don't do it at all.
6. Read before you write, every time. Assuming a gap is new, instead of checking the live file first, is exactly how stale information gets copied forward as fact.

An open question

I still don't know if this scales past a few thousand entries, or whether the chunking trick that saved me once becomes its own bottleneck eventually. If you've built something like this and hit a wall I haven't yet, I'd genuinely like to know what it looked like. What's the failure mode nobody warned you about?