Atlas puts two years of my AI chats on one map, and the export is the part I want gone

Atlas is a demo. Every number on screen comes from fixture data drawn from my own history (2,988 conversations across 26 months), and there is no backend; it is a React app served at /atlas from its own project, which this site proxies so the address bar never leaves jakelawrence.xyz.

The app has three stations along the top. Atlas is the map: an overview of fourteen topics with activity sparklines, a connections graph, and an evolution view of how my attention moved across phases. Curate is a five-screen review run, where every topic, link and decision the importer proposes waits for a yes, a no or an edit. Companion is where you ask questions of your own past: Ask Atlas answers with numbered citations back to the conversations, Belief Diffs shows where my view on something changed, and a monthly Digest summarizes what moved.

Two smaller pieces are worth a click. Decision archaeology traces one decision back through the conversations that led to it, from the first complaint to the settled default. Rewind replays the atlas month by month, so you can watch a topic arrive and fade. Both are what I actually wanted from my chat history: not a transcript search, but the reasons.

The fixtures come from real conversations, so they carry real names: companies, people, cities, and dollar amounts. Atlas loads with privacy mode on. Every identifying name becomes a typed, stable stand-in ("Employer A", "Company B", "Person 1"), counted per type in a fixed order so the same name gets the same stand-in on every load. Exact dollar figures become the band they fall in, so a specific budget reads as "between $500 and $1k". The band keeps the order of magnitude, which is all the map needs.

The swap runs over every text node and labeling attribute before the page paints, and the exports, the clipboard and the command palette's search run through the same function. You can turn it off with the half-moon button in the header or Alt+Shift+P. The MCP endpoint described below ignores that switch entirely: it is configured to answer with stand-ins whatever the query asks for.

Here is how you build an atlas today. Request a data export from ChatGPT, wait for the email, download the archive. Do the same for Claude. Drop both files on the first screen and work through the curation run.

Most people will do that once. And on the day they finish, the atlas starts going stale, because nothing they talk about afterward ever reaches it. A map of your thinking that stops on the day you downloaded a zip file is a snapshot, not a map.

MCP (the Model Context Protocol, a standard way to give a model tools) does not fix history. A server cannot read your past chats; only the providers' exports reach those. What it can do is cover everything from today on, in two directions.

The first is capture. A tool the model can call ("log this decision in Atlas") files decisions as you make them, so the export stops being the way in and becomes a one-time backfill. The second, and the bigger win, is reading. Tools that let Claude ask Atlas mid-conversation mean "what did I decide about serverless last fall?" gets answered inside the chat you are already in, with links back to the source.

The load-bearing choice is where captures land. Nothing a model writes goes into the atlas directly. Every capture arrives as a pending item in the same Curate screens the import uses, so the review run stops being a one-time setup wizard and becomes an inbox: the place you check what Claude filed this week. A model that over-captures costs you a click. A model that writes straight into your knowledge base costs you trust in all of it.

Toggle the diagram below between the demo as it ships and the plan.

The obvious objection is that capture depends on the model choosing to call a tool nobody asked it to call. So I measured it before designing around it. I built a stub of the server that stores nothing and logs every call, then played twelve scripted two-turn conversations through it: six where the user reaches a decision and never mentions Atlas, three trivial ones (a unit conversion, a grammar question, trivia), and three where the user explicitly asks for the save. Two models, three versions of the tool descriptions, four runs each: 288 conversations, $15.60 in API spend.

The result was cleaner than I expected. With one-line descriptions, Sonnet 5 filed a third of the stated decisions on its own and Opus 5.5 under half. With descriptions that say when to call the tool ("call it when the user commits to a choice"), both filed all 24, and neither filed any of the trivial chats. Adding server-level instructions on top changed nothing measurable. Every unprompted capture also happened on the turn right after the user stated the decision, never while they were still asking.

The capture side is a plan. The read side is running. Four read-only tools, atlas_search, atlas_topic, atlas_decisions and atlas_drift, answer over the demo data at a public endpoint, stateless and with no sign-in. Their descriptions follow the eval's lesson and say when to call them. Every result links back to the page in Atlas it came from, and every name in it is a stand-in.

You can try it without installing anything. The console below sends real requests to that endpoint from your browser, the same calls Claude makes, and prints what comes back. The questions are fixed rather than free text, and the console holds back career and work topics, because this is a public page.

If you use Claude Code, one command adds it to your own sessions:

Two more questions had to be answered before the plan made sense. The first was reach. Every consumer chat app that supports MCP (Claude on the web and phone, ChatGPT, Gemini, Le Chat) connects from the vendor's cloud over HTTPS, and none can start a process on your machine. A local-only server would reach Claude Desktop and developer tools and nothing else, so a real Atlas needs a hosted endpoint, which is why the read tools already have one.

The second was cost. Enriching a backlog means sending every old conversation through a model once. For a heavy user with about 460 conversations, a one-time backfill with Haiku 4.5 through the Batch API comes to about $1.20. Ten thousand conversations comes to about $25. The money was never the obstacle; the export was.

If you rarely go back to a decision, you do not need a map of them. The memory built into the chat apps already covers "remember that I prefer TypeScript," and it costs nothing to set up. Atlas earns its keep when you work across more than one assistant, when you want the reasons and not just the preference, and when you want to see a view change over time instead of being silently overwritten.

The eval also has edges I have not tested. The decisions in it were stated plainly. People often decide things implicitly, by dropping an option and never mentioning it again, and I have no data on whether a model notices that. Twenty-four conversations per cell is enough to say the described tools work far better than the bare ones; it is not enough to promise they never miss. And until storage is settled, Atlas stays a demo of my own data rather than a place to put yours.