Stopped Re-Explaining Myself to Every AI — Shared Memory for ChatGPT, Claude, and Codex (Part 1)

Every new chat started the same way: I would explain my job, my goals, what had been bothering me lately, and everything I had already tried. I built Personal Memory so ChatGPT, Claude, Codex, and Claude Code could consult the same long-term memory instead. This first part covers why I needed it, what deserves to become a memory, and how it changed the advice I receive. The implementation is covered in Part 2: MCP, OAuth, PostgreSQL, and pgvector for cross-AI long-term memory.

0. I was not trying to build a profile card

The first version of the question sounded simple:

“Can I share my personality, strengths, problems, and accomplishments across local Claude Code, Claude on the web, and ChatGPT?”

If all I needed were a static profile, I could paste the same paragraph into every product's Custom Instructions. But the context I wanted to carry forward was not static:

• what I had asked for help with before
• what I was worried about at the time
• which constraints shaped the decision
• which options I compared, and why I chose one
• what worked, what failed, and what I learned
• how my situation and thinking changed afterward

“I am a software engineer” is almost useless in a serious career conversation. Useful advice only emerges when that fact is connected to past projects, anxiety about evaluation, tradeoffs between speed and quality, and even my reluctance to transfer knowledge because it might make me less valuable.

1. The simpler approaches I considered first

I did not begin by deciding to run PostgreSQL. I wanted the simplest thing that could work.

An index plus Markdown files is still a good solution at small scale. But I did not want a notebook where I had to remember which file to open. I wanted the AI to find relevant memories before a conversation and return durable changes to the same place afterward.

That led me to use MCP as the common read/write interface and keep one source of truth behind it.

2. Full transcripts are too long; short summaries are too thin

The hardest design question was not where to store the data. It was what to preserve, and at what level of detail.

Keeping every transcript avoids information loss, but sending all of it to a model on every turn is impossible. When I loaded the first 100 records together, the response was about 535 KB, or roughly 260,000 characters. Worse, the “summary” and detailed body were effectively identical, so the summary layer was doing no work.

At the other extreme, a line such as “I was thinking about changing jobs” or “I made an image” removes the causal chain that makes the memory useful later.

The compromise became a detailed case record.

It is neither a transcript nor a conventional summary. The goal is the smallest record from which the next AI can reconstruct why I reached the decision, without reopening the original conversation.

Concrete example: why I moved from Markdown in Google Drive to PostgreSQL

My first working version used INDEX.md, topic files, and monthly logs in Google Drive. That was enough for several AIs to read the same information.

Compressed into one line, the resulting memory would be:

I chose PostgreSQL plus pgvector for Personal Memory.

That line does not explain why I introduced a database when the Drive version already worked. A case record preserves the path to the decision:

Later, when someone asks why a folder of Markdown was not enough, the AI can explain what worked first, where it stopped working, which alternatives I considered, and why the tradeoff was acceptable. That is the practical difference between a one-line note and a detailed case record.

3. People change, so I do not overwrite the past with the present

Another problem was that the subject of this database—me—keeps changing.

“I want to become a Staff Engineer,” “I am worried about my current job,” and “I prefer this approach” are not eternal truths. If I only overwrite the current state, I lose the reason an earlier decision made sense. But if I treat every old state as current, the advice becomes misleading.

I separated memories into three broad kinds:

The current synthesis can change, while old revisions and evidence remain immutable. I borrowed the idea of evolving memory from people, but not the part where recalling something rewrites the only copy. Interpretation stays flexible; history stays firm.

4. Progressive retrieval instead of loading everything

I replaced “read hundreds of records every time” with three levels of retrieval:

1. index — titles, categories, tags, and compact index summaries
2. summary — detailed case records for the likely matches
3. full — verbatim evidence only when exact wording matters

It works more like a library: search the catalog, choose a few books, then open the relevant pages. You do not stack the entire collection on the desk.

5. How the advice changed

The clearest test was a career question.

I asked Claude to assess my strengths and the missing evidence for becoming a Staff Engineer at a Big Tech company, using my work history, my speed-versus-quality tradeoffs, and the anxieties I had raised before. I also asked it to separate facts from inference and reduce the next 90 days to three actions.

Instead of reading one profile, it crossed ten records: previous roles, quantified results, development speed, worries about quality investment, vague promotion criteria, and my fear that teaching others would reduce my own value.

It recommended three things:

1. Create a one-page Platform Layer architecture document that explains several systems together
2. Turn promotion language into an explicit evidence list and decision date in a 1:1
3. Complete one named knowledge-transfer artifact or session

What mattered was that this was not a generic Staff Engineer checklist. It inferred that my strength was concentrated in individual execution speed, while the missing evidence was proof that I could make my judgment reproducible through other people.

That was the moment Personal Memory stopped feeling like a search demo and started feeling like a system that could use past experience to produce new advice.

6. What “automatic updates” really means

This part is easy to misunderstand. The server does not secretly watch and save every conversation.

Supported clients are instructed to consult the index before personal advice and to create a memory proposal when a conversation contains a durable new detail or change. Ordinary private additions and state transitions can move from proposal to commit under standing approval I granted in advance.

The following operations are never committed automatically:

• disputed corrections to existing facts
• merging multiple memories
• deletion
• publishing or unpublishing

Nor does the server push new context into an already-open chat. A client sees the latest revision the next time it retrieves memory.

7. I store personal detail, but separate secrets from private facts—and private facts from public ones

The system is meant to support advice that is not abstracted into uselessness. Names, companies, compensation, managers, work, relationships, and concerns can therefore be stored in private memory when the detail matters.

It always rejects:

• government identifiers such as SSNs
• passwords
• API keys
• recovery codes
• private keys

I also separated private memory from the blog at the data-path level. The blog can only read public projections that were reviewed individually and redacted where necessary. Private source text and evidence never flow directly to the frontend.

Encryption and authentication matter, but once an authorized AI retrieves a memory, that information is being sent to the AI service. Encryption cannot solve that boundary. I still have to decide which clients I trust with which memories.

8. Where it stands now

Personal Memory is usable today in the ways that matter most to me:

• Claude, ChatGPT, Codex, and Claude Code can connect to the same source of truth
• records containing both Japanese and English remain searchable
• answers can distinguish retrieved facts from model inference
• a changing situation can be updated without erasing its history
• private memory and blog-ready public data follow separate paths

It is not a perfect “second brain”:

• poor queries or aliases can still miss an existing record
• whether a client consistently invokes the right tools also depends on its configuration
• merging similar memories can lose information and still needs human review
• large conversation imports involve model usage, rate limits, and difficult deduplication
• retrieving a number correctly does not make the original number verified

Even so, I do not want to go back to introducing myself from zero in every chat. I would not say “the AI knows me.” A more accurate description is that it can investigate the relevant parts of my past and reason from evidence when needed. That distance is healthier—and, to me, more trustworthy.

Part 2 goes inside the implementation: MCP, OAuth with PKCE, PostgreSQL plus pgvector, hybrid FTS/trigram/vector retrieval, immutable revisions, historical backfill, and the failures that forced the design to improve.

→ Part 2: MCP, OAuth, PostgreSQL, and pgvector for cross-AI long-term memory