Personal context sits in a store the user owns; the open protocol in the middle keeps store, assistant and device independent choices. Credit: Tetsuya Wakita Summary Context management for AI-assisted coding has matured into a rich ecosystem: convention files, repository maps, memory banks, and full-blown memory frameworks all compete to keep a coding agent grounded in your codebase. But step outside the terminal and ask an assistant about your health or your finances, and the tooling nearly vanishes. Your personal context lives in one vendor’s memory feature, locked to that vendor, or it lives nowhere.
This article argues that the missing piece is not a smarter memory system but a separation of concerns: put personal context in storage the user owns, independent of any AI vendor, and let every assistant connect to it. It describes a working open source implementation of that principle, a Git-hosted Markdown vault served to multiple LLM surfaces through a single remote MCP endpoint, along with the trade-offs that design accepts. Running that system on edge infrastructure also surfaced a problem that reaches well beyond it: edge platforms forbid runtime code generation, which silently disables the fast path of the TypeScript ecosystem’s standard validation library. The article covers the fix, an open-source ahead-of-time schema compiler that grew out of this project and now validates every request the system serves.
It then looks at where this is heading. As external services expose MCP interfaces, chat becomes a place where real-world tasks get done. A user-owned context layer, tied to no particular device, is what makes those actions personal. For coding, context management is nearly a solved problem If you write code with an LLM today, you are spoiled for choice in how to feed it context.
The simplest layer is convention files: CLAUDE.md for Claude Code, AGENTS.md as a cross-tool standard, Cursor rules, GitHub Copilot’s custom instructions. Every serious coding agent now reads a project-level file that tells it how the codebase works and how to behave. One level up sit the structural tools: repository maps that compress a codebase’s shape into the context window, plus codebase indexers and code-search integrations that let the agent retrieve the right file instead of guessing. Then come the persistence layers.
Cline’s Memory Bank pattern keeps structured progress notes across sessions, Cursor ships session memories, and Claude Code maintains its own memory directory. For teams building custom agents, general-purpose memory frameworks such as mem0, Letta, and Zep offer retrieval pipelines, ranking, and even temporal knowledge graphs that track when a fact stopped being true. The result: a coding agent can wake up in the morning knowing your architecture, your conventions, yesterday’s refactoring state, and which tests are flaky. The ecosystem is crowded because the problem is well shaped.
Code lives in repositories, is versioned, and has structure that tools can exploit. Everything else is an afterthought Now leave the terminal. The other half of LLM use, arguably the bigger half, is conversational: you throw a question or a problem at a chat interface and want an answer grounded in your situation. What did my bloodwork trend look like before I changed my diet?
Given my actual portfolio, what does this market move mean for me? What did I decide last time I evaluated this vendor? Draft this email knowing who I am and what I’ve already promised. For this mode of use, the tooling is thin.
What exists is vendor memory: ChatGPT remembers things about you inside ChatGPT, Claude inside Claude, Gemini inside Gemini. Each one is useful, and each one is a silo. The memory does not travel; portability, where it exists at all, is a one-directional import feature controlled by the destination vendor. Switch assistants, or simply use two, and your accumulated context splits into inconsistent fragments.
The memory frameworks that serve coding agents so well do not really fill this gap either. mem0, Letta, and Zep are developer infrastructure: they are what you reach for when you are building an agent product, not when you are a person who wants their own context to follow them from a laptop chat to a phone chat to a coding session. And they keep the memory inside their own stores, which re-creates the vendor lock-in problem one layer down: you have escaped ChatGPT’s silo into a startup’s silo. So the question worth asking is not “which memory feature is best?” but: Why does my context live inside the assistant at all? Separate the storage from the vendor The answer this article proposes is old-fashioned: separation of concerns.
Personal context should be storage, owned by the user, in a format any tool can read. Assistants should be clients of that storage, never its landlord. My implementation of this principle is a private GitHub repository of plain Markdown notes, organized as an Obsidian vault so the notes form a linked, browsable graph. It is exposed to every LLM surface I use through a single authenticated endpoint speaking the Model Context Protocol(MCP).
MCP matters here because it is an open protocol rather than a vendor SDK: one server, and claude.ai on the web, the desktop app, the phone, and Claude Code in the terminal all read and write the same notes. In principle, any MCP-capable client from any vendor can join. The system, vault-mcp, is open source, and I run it daily for project notes, work context, and personal logs. Nobody grants this neutrality.
It falls out of the storage itself: the corpus is plain text in a Git repository, so leaving any vendor, or all of them, costs exactly git clone. You never file an export request or wait for two companies to agree on a migration format. The same property makes the context legible: what my assistants know about me is a folder of files I can open, read, edit, and diff. Vendor memory is only now catching up to that standard of transparency.
GitHub and Markdown are just my choices, and the principle does not depend on them. It only asks that the context live outside the assistant, in a store the user controls, reachable over MCP. Keep your context in Google Docs and expose it through a Docs MCP server, and the same architecture holds. If your notes already live in Notion, connect its MCP server and use that.
Each choice shifts the trade-offs (a Git repository of plain text maximizes portability and auditability, while a hosted workspace trades some of that for familiarity and built-in editing), but the separation is what does the work. The format helps too: as long as the notes themselves are plain Markdown, the store is replaceable, because migrating is just copying files. You can start on GitHub today and take the same corpus to whatever store you prefer tomorrow. Whichever one you pick, every assistant becomes a client of it instead of keeping a private copy of you.
A few implementation choices are worth naming briefly, because they carry the security posture rather than the plumbing. The server runs on serverless edge infrastructure and uses GitHub’s API as its transport, so no personal machine has to stay running and the whole system fits in free tiers. Writes are append-only: an assistant can create or overwrite a note but never delete one. Every change lands as a Git commit, so the history is auditable and any write can be rolled back.
Authentication splits “who may connect” from “what the server may touch” into two separately scoped credentials, which bounds the blast radius if either one leaks. There is also a subtler risk. Exposing your entire personal knowledge base to LLMs turns your own notes into an untrusted input channel, because a buried instruction in a note can become a prompt injection the moment the model reads it. The server therefore treats retrieved notes as data rather than instructions, with the append-only and path-restriction rules as backstops.
