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. None of this depends on the specific stack. The point is that a personal context layer deserves conservative defaults, because the payload is everything you know.

What the edge took away, and what it took to get it back

Running on edge infrastructure was the right call for a system that should cost nothing and depend on no personal machine. But the choice exacted a price in an unexpected layer: input validation.

An MCP server is a public-facing API. Every tool call an assistant makes (read this note, write that one, search for this term) arrives as untrusted input and must be validated before it touches storage.

In the TypeScript world the standard tool for this is Zod, a validation library approaching a hundred million weekly downloads, and the official MCP SDK is built around it. vault-mcp is no exception: every request passes through a Zod schema before anything else happens.

Zod’s current version is fast, and the reason is buried in its internals. The first time it validates a given object shape, it generates specialized JavaScript for that exact shape at runtime and compiles it on the spot; every later validation runs the specialized code instead of interpreting the schema. It is a just-in-time compiler in miniature.

Edge runtimes forbid exactly this. Runtime code generation is a security hazard in a multi-tenant environment, so platforms like Cloudflare Workers block it outright.

Zod knows: it detects Workers by name and switches its fast path off, falling back to the slow interpreted route. So the environment this whole system lives in turns out to be the one environment where the ecosystem’s fastest validator cannot run at full speed.

That constraint is not unique to a personal knowledge base. It applies to anyone validating input on the edge, and the edge is where more and more of the web’s request handling now lives.

The fix follows from the same observation that motivated Zod’s JIT in the first place: schemas are static. They are written once, at development time, and never change while the server runs. If specializing at first use is illegal on the edge, specialize earlier, at build time, where no restrictions exist. I built Zod AOT, an open-source compiler that turns Zod schemas into plain, flat JavaScript validation functions during the build. Because no code is generated at runtime, the compiled validators run anywhere, including environments where Zod’s own fast path is disabled. Because nothing compiles on the first request, there is no cold-start penalty, which matters on serverless platforms that create and destroy instances constantly. In benchmarks, the compiled validators check complex nested objects up to 60 times faster than Zod’s runtime fast path, and the gap widens further on the edge, where that fast path never runs at all. Schemas that embed arbitrary functions and cannot be fully compiled are compiled partially, with the remainder falling back to Zod unchanged.

vault-mcp now validates every tool call through these precompiled validators. The speed is welcome, but the more useful outcome is the general one: a constraint met while building a personal tool produced a fix that applies to the whole class of systems, and both halves are open source.

Where this is heading: chat as the front end to everything

The case for separating storage from vendor gets stronger as MCP adoption spreads beyond personal tooling. MCP is emerging as the standard way to connect LLMs to services as well as to context, and every external service that exposes an MCP interface turns conversation into a place where things get done.

E-commerce is the obvious example. If a shopping platform exposes product search and checkout over MCP, an assistant can find, compare, and purchase in a single conversation. This is where a personal context layer changes the quality of the transaction. An assistant that can read your notes knows your sizes, your budget, what you bought last year and whether you regretted it, and what you already own. It can propose the right product, or advise you not to buy at all, which is something no storefront recommendation engine will ever do, since those engines optimize for the seller. Tool access makes an assistant capable. Your context is what makes its advice personal.

Whether service providers embrace this is an open question. An MCP checkout shortens time on site and routes around merchandising, advertising, and upsell, the machinery that e-commerce revenue is built on. Some platforms will resist becoming a headless backend to someone else’s assistant; others may decide that being reachable where the customer already is beats defending a destination website. Whichever way that goes, the user loses nothing by owning the context layer: it plugs into whatever services do open up.

The second consequence of standardizing on MCP is device independence. Nothing about a remote context vault assumes a laptop or a phone; those are just today’s surfaces. The link between assistant and context is a protocol, so it does not depend on any particular platform. When the next device category arrives (smart glasses, wearables, home devices, the car), any assistant it hosts reaches the same vault the same way desktop and mobile clients do now. There is nothing to migrate or re-import, and no per-device memory that starts from zero. A context layer built on an open protocol outlives vendor choices and device generations alike.

What this trades away

The design has real costs. There is no ranked retrieval and no temporal model that knows when a fact expired; dedicated memory frameworks are better at high-volume automated recall. For one person’s corpus of hundreds of notes, delegating retrieval to the assistant’s own tool use works well, and that is the scale this design is for.

Nor is the composition unprecedented. Markdown-over-MCP servers exist, and so do git-backed vault servers. What I can claim is the specific combination: user-owned storage, open-protocol access, no always-on host, and conservative write semantics, assembled around one principle. The assistant is replaceable; the context is not.

Takeaways

Coding context has an ecosystem. Personal context has silos. Convention files, repo maps, memory banks, and memory frameworks serve the coding use case well. Nothing equivalent and vendor-neutral serves everyday conversational use.

Portability has to be designed in; no vendor feature provides it. Put personal context in a plain-text repository you own and cross-vendor migration collapses to git clone.

Open protocols make the storage/vendor separation practical. MCP lets one user-owned store serve many assistant surfaces (laptop, phone, terminal) without any vendor’s permission.

MCP-enabled services will compound the value of owned context. As commerce and other services expose MCP interfaces, assistants become able to act, and personal context turns a generic action into personalized advice. Whether incumbents embrace or resist disintermediation, an owned context layer plugs into whatever opens up.

An open protocol keeps the context layer independent of any device. New device categories such as wearables, glasses, and home devices inherit the same vault through the same protocol as desktop and mobile, with nothing to migrate and no per-device memory starting over.

Edge constraints ripple into unexpected layers. Platforms that forbid runtime code generation silently disable the fast paths of common libraries; Zod’s hidden JIT is one. Compiling that specialization at build time instead, which is what Zod AOT does, restores the speed in any runtime and costs nothing at cold start.

A personal context layer deserves conservative defaults. Append-only writes, least-privilege credentials, and per-commit audit history cost little in daily use, and they bound what any failure (including prompt injection via your own notes) can destroy.

Know what you are giving up. A user-owned vault trades ranked retrieval and temporal fact modeling for ownership, legibility, and zero maintenance. For one person’s lifelong context that is the right trade; for high-volume agent memory it is not.

Conclusion

The industry has answered “how should an LLM remember?” with ever-better memory systems, each attached to a vendor or a platform. For the personal, everyday half of LLM use, that is the wrong shape of answer.

Memory that matters for decades (health, money, decisions, relationships, work) should not have a landlord. Separate the storage from the vendor, give every assistant a client’s access and nothing more, and the assistants become what they should have been all along: interchangeable views over a context that is permanently, structurally yours.

As MCP spreads through external services and onto whatever devices come next, that separation pays growing dividends. Assistants, services, and hardware will keep changing; the context underneath them no longer has to.

Tetsuya Wakita is Vice President of Engineering at AnyMind Group in Thailand, where he leads a global engineering organization and builds LLM-powered products and developer tooling. He designs and operates vault-mcp, an open-source portable context layer for LLM assistants, and is the author of Zod AOT an ahead-of-time compiler for Zod schemas.