An AI-powered coding agent can now wake up with a clear picture of your repository, project conventions, and the state of yesterday’s refactor. But ask the same assistant about your health history or personal finances, and the tooling is far less developed. The gap has little to do with the capability of large language models and much more to do with architecture.
Over the past two years, context management for AI-assisted programming has matured into a crowded ecosystem. Convention files such as CLAUDE.md and AGENTS.md, repository maps, codebase indexes, memory banks, and general-purpose memory frameworks all compete to keep assistants grounded in a specific codebase. They track architecture, coding standards, known issues, and even flaky tests. A developer can move between coding agents without losing the project-level knowledge those agents maintain.
Conversational AI is different. When people ask a virtual assistant about their own life, their context usually lives in whatever proprietary memory feature the assistant vendor happens to offer. The memory is not portable. It cannot easily move from one chatbot to another. That creates artificial silos that limit the usefulness of text-based AI assistants just as they are moving beyond one-off queries.
Personal context is not solved
Vendor memory like the kind built into ChatGPT, Claude, and Gemini is practical for maintaining conversation continuity. Every individual technique is useful, but none of it is portable. The accumulated knowledge of a user’s preferences, past decisions, and ongoing plans is diffused across separate products that do not share a common store. Switching to a new assistant means starting over. Using several assistants simultaneously means fragments. For developers, open memory frameworks such as mem0, Letta, and Zep provide retrieval pipelines and temporal knowledge graphs, but these are designed as building blocks for agent products, not as a personal layer owned by an individual. Their memory remains in their own stores, which re-introduces the lock-in problem one layer lower. Replacing one vendor silo with another vendor silo does little to make long-term personal context portable.
This is why a growing number of privacy-conscious developers are asking a more reasoned question: why should a user’s personal context live inside an AI assistant at all? The separation of concerns that middleware has long applied to databases and front ends applies equally to this case. Personal context should be storage. Owned by the user. In a format any tool can read. The assistant should be a client of that storage, not its landlord.
An open protocol for your notes
One implementation of this idea works by putting personal context into a private Git repository of plain Markdown notes. The notes are structured as an Obsidian vault, which gives them linked relationships and visual navigation. What exposes that vault to every AI assistant is a single authenticated endpoint built on the Model Context Protocol, or MCP. The endpoint reads and writes the same set of notes from a web chat, desktop assistant, mobile app, or coding tool. MCP matters because it is an open protocol rather than a vendor-specific SDK. One server can serve all these surfaces at the same time, and the notes stay in the repo, independent of any single vendor. The project is open source, and available for any MCP-capable client to join.
No permissions are needed to create this neutrality. It falls out of the storage design. Because the corpus is plain text in a Git repository, leaving any assistant provider costs exactly the equivalent of a git clone. No one needs to file an export request. No one needs to wait for two companies to agree on an interoperability format. The context is also transparent by definition. The assistant knows a user because it can read a folder of Markdown files, and the user can open, edit, diff, and review those same files at will. Vendor memory features are only beginning to catch up to that standard of auditability.
GitHub and Markdown are only one possible choice. The article proposes that the principle is agnostic: if notes are stored in Google Docs, and a Google Docs MCP server is used, the same architecture remains. If someone keeps their notes in Notion and exposes them through Notion’s MCP server, that works too. The storage decisions change the trade-offs, but no vendor owns a protocol or a format that stands between the user and their context.
There are implementation details that carry the security posture. The server is designed to run on serverless edge infrastructure and uses GitHub’s API as its transport, which means no personal machine has to stay online and the system fits into free tiers. Writes are append-only. Assistants can create or override notes, but they cannot delete them. Every change lands as a Git commit, leaving an auditable history from which any write can be rolled back. Authentication splits who may connect from what the server may touch into two separately scoped credentials, bounding the blast radius.
There is also a subtler risk. Exposing a personal knowledge base to an AI assistant turns notes into an untrusted input channel. If an instruction is buried inside a note, the model may read it and act on it. Because the corpus is untrusted data, the server treats retrieved notes as data, not executable commands. The append-only rule and path restrictions are backstops. These conservative defaults are appropriate because the payload contains everything a person knows.
Edge infrastructure reveals a performance gap
The same architecture of running on edge infrastructure produced an unexpected problem for validation. An MCP server is a public-facing API. Every tool call performed by an assistant is untrusted input and must be validated before storage is touched. The standard TypeScript validation library is Zod, with nearly a hundred million weekly downloads. The official MCP SDK is built around it. Zod’s current version uses a just-in-time compiler under the hood. On first validation of each shape, it generates specialized JavaScript, and every later validation runs specialized code instead of interpreting the schema. This makes it fast, but it relies on runtime code generation.
Edge runtimes forbid that. Multi-tenant platforms such as Cloudflare Workers block runtime code generation for security reasons. Zod knows this and switches off its fast path on those platforms, falling back to slower interpretation. The entire vault system needs to run on the edge to keep free tier costs low and support instant, global requests. Yet the edge is exactly where the validation layer loses its speed advantage.
The author of the project decided to fix that at build time. If the schemas are static and written before deployment, they can be specialized during the build rather than on the first request. That led to an open-source ahead-of-time schema compiler, Zod AOT. It converts Zod schemas into plain, flat JavaScript validation functions during the build. No code is generated at runtime, so the compiled validators run in restricted environments. And because nothing is compiled on the first request, there is no cold-start penalty, an important consideration for serverless platforms that constantly create and destroy instances. Benchmarks from the project show compiled validators checking complex nested objects up to 60 times faster than Zod’s runtime fast path. On the edge, where the fast path never runs at all, the gap is even larger.
MCP becomes a front end to services
The argument for separating storage from the AI vendor grows stronger as MCP adoption spreads beyond personal notes. MCP is becoming an open standard way to connect LLMs to web services. When an online service exposes search, product listings, and purchase capabilities over MCP, a conversation becomes a place where tasks get completed. With shopping over MCP, a personal AI assistant can gather sizes, budgets, prior purchase history, and preferences from a vault to make an appropriate recommendation. It could even recommend against making a purchase, behavior that recommendation optimizers used by storefronts will never offer because they are built to maximize seller revenue. Tool access makes an assistant capable; owned context makes its advice personal.
Service providers may not all embrace this direction. Checkout over MCP reduces time on site and circumvents ads and merchandising. Some incumbents may resist becoming a headless backend to another company’s assistant, while others will decide that reaching customers where they already are beats defending a destination website. Whatever happens, users who own their context layer will be able to plug into the services that do open up.
Device independence is a second consequence of an open protocol. A remote vault does not assume laptop or mobile form factors. Any new category of device, from smart glasses and wearables to home devices and vehicles, can reach the same vault with the same protocol. There will be no need to migrate memory between device generations or start fresh with per-device memory.
Trade-offs
The architecture is not a replacement for every state-of-the-art memory framework. It lacks ranked retrieval and a temporal model that can answer precisely when a fact expired. Dedicated memory frameworks have better tooling for high-volume automated recall. For one person’s corpus of hundreds of notes, allowing the assistant to discover notes through its own tool use is often enough. That scale is exactly what this design is for.
Composing Markdown over MCP was not new. Git-backed vault servers also exist. The contribution is in the specific combination of user-owned storage, open-protocol access, no always-on host, conservative write semantics, and one clear principle. The assistant is replaceable; the context is not.
The work leads to a set of design lessons for the broader AI ecosystem. Coding context now has a rich ecosystem of solutions, while personal context is still dominated by silos. Convention files, repository maps, memory banks, and memory frameworks solve developer-centered problems well. The everyday conversational use case still lacks a vendor-neutral solution. Portability has to be designed; no vendor feature can be relied on. A plain-text repository that the user owns collapses cross-vendor migration to git clone. Open MCP lets one user-owned store serve every AI assistant interface. MCP-enabled services will add value to this setup by making assistants able to act, not just chat. Edge platforms, for their part, impose unexpected limitations. Runtime code generation restrictions disable fast paths for widely used libraries, but a build-time compiler restores performance without cold-start cost.
What any person chooses as a context layer should come with conservative defaults. Append-only writes, least-privilege credentials, and per-commit audit history do not burden daily use much. They bound what a malicious note or a compromised model can destroy. The trade-off must always be explicit. A user-owned vault gives up ranked retrieval and temporal fact modeling in exchange for ownership, legibility, and zero maintenance. For a person’s lifelong context, that is often the right trade. For high-volume agent memory, it would likely fail.
Ultimately, memory that matters for decades ought not to have a landlord. Health, money, decisions, relationships, and work benefit from persistent data that is portable, auditable, and independent. When every AI assistant only has client access, assistants become interchangeable views over a context that remains structurally user-owned.
Source:TNW | Contributed News