Your ChatGPT writes to the same brain Claude reads
Every chat starts at zero and you become the assistant's memory. Two write paths, one brain — how two-way MCP write-back actually works.
Your ChatGPT writes to the same brain Claude reads — as you, with your exact permissions, reversible.
You know the drill. You open a new chat, and before you can ask anything useful you re-explain the whole project: the stack, the weird constraint from last week, the decision you and the model already made twice. You paste it in, get your answer, close the tab. Tomorrow you do it again.
That re-explaining is the filing tax wearing an AI costume. The filing tax is the cost of deciding where a thought goes before you're allowed to keep it — and in an AI workflow it shows up as you being the long-term memory. You're the human clipboard, hauling context from chat to chat, deciding every time what's worth re-pasting and what you'll let evaporate. It's the same reason every second brain you've started is now a dead vault: the tool made you the librarian, so one busy week you stopped showing up. That's the part you quit.
Built-in memory was supposed to fix this. It half does. "Memory updated," it says — genuinely nice for your name, your tone, that you prefer TypeScript. If all you want is for chats to feel personal, that's the right (free) tool; keep it. But it's a flat list of facts with no shape and no sources, and it lives inside one assistant — so what Claude learned about your project on Tuesday means nothing to ChatGPT on Wednesday. You're still the clipboard.
The wedge: your assistant writes back, not just reads
Here's the line I'd lead with even if you skim the rest: your ChatGPT writes to the same brain Claude reads — as you, reversible. Tell ChatGPT something today; Claude knows it tomorrow, because they're both reading and writing one graph.
Most "AI memory" integrations are read-only. The model can look something up; it can't write anything back. So the memory only grows if you go update it — the filing tax again, just relocated. Naumu is two-way over MCP: when the model learns something worth keeping, it writes the entity into the graph itself, typed and linked to the thing it came from — and any write is one-tap reversible, so it's a benefit you can check, not a leap of faith.
I've looked hard at the tools that overlap us — Mem, Reflect, Tana, Saga, Notion AI — and each one either has an assistant that lives inside its own app, or lets an external LLM read its content as context. I haven't seen another tool in the category let your existing Claude or ChatGPT write back into a structured graph, as you. That flips the framing: Naumu isn't another second brain you have to tend — it's the read/write memory layer the assistant you already use plugs into.
The write model, said once and precisely
When someone says "your AI can write to your data," ask exactly what happens. There are two paths into a Naumu graph, and they behave differently on purpose — I'll state both once and never blur them into one absolute:
- MCP writes are direct + reversible. When your external assistant (Claude, ChatGPT) writes through MCP, the change lands immediately — no in-app popup mid-conversation. The assistant connects as you, with your exact permissions, nothing more, revocable anytime. Every write has per-row undo, so "direct" never means "destructive" — if the model writes something wrong, you roll that row back.
- In-app writes are approve-before. The agent inside the app works the opposite way: it proposes the change as a plain-language before/after, and nothing lands until you confirm. There, you're the editor of record.
So: hands-off write-back from your assistant and a clean undo path, without a confirmation prompt interrupting every exchange — plus a fully gated editor when you're working inside the app yourself. Since the whole pitch is an assistant writing into your memory: your space is private to you; the AI connects as you and sees only what you can. Where your data lives and how it's handled: /docs.
A real typed graph out of a mess, zero schema
Two-way MCP is the moat. The second defensible thing is the artifact your assistant writes into — and the fact that you never had to build it. Say you're deep in a build, and over a couple of weeks you dump in raw working notes, three pastes that never mention each other:
"decided we're going self-host-first for the enterprise tier. cloud stays default. my note: 'this is what the two SOC2 asks were really about — they want it in their VPC.'
spike: rate-limiter has to move to Redis before the self-host story works, in-memory won't survive multi-node. note: 'this is now load-bearing, not a nice-to-have.'
random thing from a sales call: that fintech lead said they'll only sign if we can prove no customer data leaves their network. didn't log which deal. felt connected to the self-host thing somehow."
You didn't tag anything or pick a project. From those blobs the agent pulls out and types the entities — self-host-first (a decision), the Redis rate-limiter move (a blocker), the fintech "no data leaves their network" ask (a requirement, deal flagged missing), your "this is load-bearing" margin note (a claim) — and draws the edges: the Redis move blocks self-host-first; the fintech requirement shares-intent with self-host-first; your claim is attached-to the Redis move. That's a first pass you fix in a glance — note it's honest about the gap: the sales note is captured with its deal flagged as unidentified, not invented. You never defined a schema, a template, or a field to get here.
A week later, sketching the roadmap, you ask:
"Where does that fintech ask I heard on a call fit in what I'm building?"
A keyword search loses this — the sales note never contains "self-host," "VPC," "Redis," or "rate-limiter," so a full-text search for "self-host" misses it entirely. Naumu answers from the edges, not the strings:
It's the same need as your self-host-first decision — both are really "keep customer data inside the customer's network," which is also what the two SOC2 asks were about. And it gives you the move you hadn't made: that requirement can't ship until the Redis rate-limiter move lands, because self-host is what unblocks it and self-host is gated on Redis — so the fintech deal is silently waiting on an infra spike you filed as a side quest. Source: your own sales note, captured 2026-05-30; the self-host decision, captured 2026-05-30.
The surprise is the hop you hadn't taken: the orphan sales ask becomes a blocker on an infra task you'd deprioritized. None of the three pasted notes says that; it falls out of the edges.
That's the combination I haven't seen both halves of anywhere else. Tana has a real typed graph too — but only after you build the supertags and fields yourself. Mem, Reflect, and Saga are genuinely effortless — but there's no real connected map to open and no way to ask a question that needs the connections. Naumu claims both: zero schema effort, and a real graph you can open and traverse.
This is a real run, illustrative. On the live page you do this yourself in a pre-loaded paste box — drop your own messy notes in and watch the map build.
Why a graph and not a longer memory file
Couldn't you just keep a big CONTEXT.md and paste it into every chat? You could — it's the clipboard with extra steps. No structure, so the model re-reads the whole wall every time and re-infers the relationships from scratch, and it grows until it blows the context window.
A typed graph carries the relationships as data. The fintech-ask note above isn't an orphan line in a doc; it's a node wired by real edges to the decision it shares an intent with, the blocker that gates it, and the claim you attached. So "where does this fit, and what else connects to it?" answers by traversing those edges — across everything you've ever dumped in, not just what fit in this session's window.
What you can actually trust about a fact
When your memory writes itself — and an external assistant is writing into it autonomously — the obvious worry is: how do I know where any of this came from?
The honest, complete answer is source-traceability. Every fact traces back to its source — you can see where it came from, its createdAt, and its updatedAt. That's the extent of it. I'm not going to tell you the graph scores how confident it is, flags which facts have gone stale, or catches two notes that contradict each other — it does none of those. What it does is keep a real provenance trail: this node, from this source, captured then, touched last on this date. Notion AI cites sources too, so this isn't the wedge — it's the reassurance that makes a self-writing memory safe to rely on.
And the staying-power claim is narrow and true: you never have to re-file it — it stays organized without upkeep. The reason the others rotted is that they needed grooming; this one doesn't, because the structure builds and updates itself as you and your assistant work. (Wire in a tool that actually feeds it — Slack, Linear, a connected source — and that one keeps syncing on its own too. Absent a connected integration there's nothing to sync; the win is simply that there's nothing to maintain.)
How to wire it up
The setup should be boring, and it is. You point your MCP client — Claude or ChatGPT — at Naumu, authorize it as yourself, and from then on it reads and writes your graph within the exact permissions you gave it, revocable whenever. Full, current setup steps live in our docs; I'm not pasting a URL that'll rot the day we change the endpoint.
Once it's connected, the loop changes shape. You stop opening each chat by re-explaining your project. You stop being the part of the system that remembers. The model reads what it needs and writes back what it learns — directly, reversibly — and your graph keeps the shape of your work, sources and all, whether you're in Claude today or ChatGPT tomorrow.
You don't have a worse assistant. You have an assistant with amnesia, and you've been its memory. Hand that job to the machine.
Drop your pile. Or start with a sentence → — no signup to try.
What are you working on?
Whatever it is, Naumu takes what you describe and turns it into structured, connected knowledge.