Anthropic now ships at least three different memory models inside the Claude product family, and they don't behave the same way. Claude.ai has the model writes to itself, both loaded at session start. The API ships frames the wrapper as everything in an AI agent except the model itself: the tool definitions, the context compaction, the feedback sensors, the system prompt, the memory between sessions. Anthropic's own engineering team makes the case that agent memory creates switching costs that data portability rules cannot fix. For example, even if a vendor lets you export your memory directory tomorrow, the operational understanding the agent built — your team's terminology, your exceptions, your shorthand — does not round-trip cleanly into another vendor's surface. Eight months of accumulated context turns into a re-onboarding tax the moment you switch. Parallels' 2026 cloud survey put vendor lock-in concern at 94% across 540 IT leaders; agent memory is exactly the layer where that concern compounds.
What I do instead
My memory lives in a NAS-backed directory called nexus/, in plain markdown, under git. It has a top-level CLAUDE.md that gets auto-loaded into every Claude Code session because it sits at the project root. It has a MEMORY.md for long-term curated state, a SESSION-STATE.md for active context, per-domain context files at agents/<domain>-context.md for finance, health, content, and so on, and daily logs at memory/YYYY-MM-DD.md. Cross-references between entities use [[double brackets]] so they're grep-searchable and Obsidian-renderable. Search across the corpus runs through an Ollama embedding pipeline using nomic-embed-text at 768 dimensions, indexed locally — no vendor API call required to ask "what did I decide about that account fee in February?"
This stack does three things the vendor surfaces cannot.
First, it survives the surface split. The same files load into Claude Code, can be pasted into Claude.ai, and can be served to an API agent through the memory tool's file ops. The format is universal because the format is just files.
Second, it survives the vendor switch. If I move to a different model provider tomorrow, the markdown still parses, the embeddings still resolve, and the wikilinks still work. There is no proprietary memory schema to migrate.
Third, it gives me audit. I can grep my own context. I can diff what changed last week. I can trash something I don't want anymore and recover it if I was wrong. None of those operations exist on the chat memory surface, and they only partially exist on the auto-memory surface.
The general pattern
The vendor's wrapper is not your wrapper. It's theirs, designed around their product roadmap and their retention model and their billing surfaces. When that wrapper includes a memory layer, putting your context in it means putting your operational knowledge in someone else's container. Fine for ephemeral chat. Not fine for the accumulated state of a year of work.
The fix is not to pick the right vendor surface. The fix is to keep your memory outside any vendor surface, in a format you own, with search you control, and let the vendor surfaces read from it as needed. Claude Code already does this for free with CLAUDE.md. The other surfaces will eventually catch up, or they won't, and either way your context survives.
Last week's post argued that the wrapper around the model is what matters. This one finishes the sentence: don't trust theirs with your context.
SOCIAL SHARE CARD GENERATOR