Every agent I use builds a model of me. Claude has learned how I like my prose; ChatGPT remembers what I’m working on. I don’t mind that other people and companies carry a picture of me. But an agent plays a different role: it learns my writing style, preferences, and the shape of my work and life to assist me. When I switch products, though, I often have to start over—each agent rebuilds what others already know, and everything an agent learns typically stays with its vendor.
It doesn’t have to be that way. What if everyone had a canonical, user-controlled repository of context that any agent could request permission to use? What if my context lived not only with the company providing the agent but also in a home I control? What if an observation captured by one agent could be proposed to that repository and, once accepted, made available to every other agent I choose?
By user-controlled I don’t necessarily mean self-hosted. I mean I can inspect the repository, decide who can read or change it, understand where each piece came from, and export the whole thing in a form I can take elsewhere. Storage, identity, and synchronization may be provided by someone else. Control does not require me to operate the infrastructure; it requires that no agent or platform be the only way in—or the only way out.
The repository wouldn’t be a portable copy of any agent’s internal model of me. It would be a legible record of things I have written, facts and preferences I have chosen to keep, and observations agents have proposed and I have accepted, each with provenance, scope, and history. Agents could consult or add to that record according to their permissions; their private inferences would remain their own.
This idea is not new. Tim Berners-Lee’s Solid project has argued for years that personal data should live in pods people control, and Doc Searls’s VRM project has promoted user-driven vendor relationships for decades. What those efforts lacked was mainstream demand. Agents are supplying it: an assistant needs rich personal context to be useful, and each vendor is building that context inside its own walls. Ordinary people now have a reason to want a personal data store, even if they wouldn’t call it that.
The hard problem isn’t syncing or storing data. It’s negotiation. Who can read a given part of my context? Who can add to it, change it, or remove it? Which parts of my life can a particular agent instance see? How do I make those decisions in a policy-driven way and manage them from wherever I happen to be?
Before I could work on negotiation I had to decide where my context should live. That’s the question I spent the past year exploring, and I tried three answers.
First answer: the laptop
Right after I gained access to Claude Code at the start of 2025, I pointed it at an Obsidian vault—a folder of Markdown files used as a personal wiki. This wasn’t especially novel; many people I know did the same, and the pattern has spread. A well-known recent example is Karpathy’s LLM Wiki: you give a description to your agent and it builds a version tailored to you.
A year of using a pile of Markdown files with agents taught me five things a personal context system must get right.
-
Local-first foundations matter. Text files are legible, portable, and easy to store where I control them. Git moves them between machines and records every change. But this approach centers on a laptop or desktop and assumes comfort with plain text and version control. Most annoyingly, the context isn’t readily available on my phone, the device I carry everywhere, nor can remote agents reach it unless I make it reachable.
-
Provenance matters, and so do proposals. Karpathy’s Wiki is largely written and rewritten by an LLM. In my setup I write most things and rely on agents to edit or contribute observations. I want to know which thoughts are mine, which were captured by an agent, and which we developed together. An agent’s observation should default to a proposal I—or a policy I control—can accept, revise, or reject. Direct write access should be something a trusted agent earns.
-
Chronology matters. Wiki links aren’t the only structure in life. Much of what I record and what agents observe is anchored in time. Thoughts build on earlier thoughts; observations about people collect meeting by meeting; some facts fade. Time should be a primary axis, not a thing reconstructed from file histories and metadata after the fact.
-
Scopes matter. My context spans work, personal, family, and public life. I want one unified view; no single agent should have it all. An agent connected through my work account should see work and public context—but nothing about my family. Completely separate silos would protect boundaries but would also shred the single history I want to build over decades.
-
Identity and type matter. LLMs can extract meaning from plain text, but people, companies, and places deserve typed records rather than mentions in prose. Persistent identities give observations, relationships, and history an anchor; they help resolve nicknames and follow role changes. An agent can then act on who someone is without reconstructing them from prose each time.
I augmented my Markdown-based repository with tooling and conventions; it’s surprising how far a directory of Markdown files can go. Each additional affordance, however, specialized the folder into something that only works for geeks. My family, who use agents daily, won’t want to manage Markdown files in a Git repo. They want their personal context with them, easy to use and transparent in daily life.
In short, those five lessons define what a context system must do, but they don’t dictate where it should live if /home/$USER isn’t the center of your computing life.
Second answer: the web
My next move was to make context available when I wasn’t at my laptop—to me and, importantly, to my agents. The obvious solution for someone who’s built on the web since the mid‑1990s: put it on a server behind a URL. I deployed a Cloudflare Worker, uploaded my context, and stood up a REST API and an MCP server. The improvement was immediate: my context was reachable from my phone and grantable to any agent I chose.
New problems arrived just as fast. I had created a new trust boundary with its own access control and appointed myself its security team. I became the operator of a small SaaS with exactly one customer, responsible for uptime and backups. And I’d traded away local-first, offline editing to get there.
These are solvable problems—our industry has decades of experience hosting services, and CRDTs could likely restore offline editing. But as agents gain access to more sensitive data and more power to act on our behalf, the cost of getting a boundary wrong rises.
And even if those issues are solved, a deeper problem remains: a standalone service sits outside my personal computing home, apart from contacts, calendars, messages, files, and system-level agents already inside it. Apple’s Siri AI announcements and Google’s Gemini integration make this separation clear. An agent embedded in an ecosystem works with everything within that trust boundary; my worker would have to rebuild each of those connections from outside.
Third answer: my pocket
As I experimented, I kept returning to a simple mental image: my context living on the device in my pocket that goes with me everywhere. Not literally every byte, but within the personal computing ecosystem that phone centers—the one that already establishes my identity, synchronizes my devices, stores much of my personal data, and mediates what apps can access. In this sense, a home is a trust boundary rather than a physical location.
Living inside the boundary doesn’t mean every app inside gets my context, or that agents outside are shut out. The boundary supplies identity, secure storage, synchronization, and native integration; the context layer still decides what each connection may read, propose, change, or delete. Native agents participate through the platform’s capabilities; agents from other companies connect through explicit, revocable permissions.
For me that home in my pocket is Apple’s ecosystem, with iCloud at its center; for others it may be Google or Microsoft. The point isn’t that any one ecosystem is right for everyone. It’s that most people already have a primary digital home, and that home is the most practical default for their personal context. We shouldn’t need a separate service with its own identity; agents should have a common, permissioned interface to the context where it already lives.
There’s an obvious risk: a vendor-rooted home invites lock-in. The mitigation is straightforward: the whole repository—entities, provenance, and history included—must be exportable at any time as a directory of plain text files that can be taken elsewhere. A pile of files in a folder may not be the best live context experience, but it makes a perfect escape hatch.
I’ve started testing this idea in a SwiftUI app; early prototypes suggest the architecture is workable: iCloud handles synchronization, and I can expose selected context to authenticated agents through MCP. Working in the Apple developer ecosystem is more inconvenient than deploying a web app, but the remaining work is clear. Choosing a home for context is one problem; negotiation—permissions that remain understandable as a repository grows, proposals from multiple agents reviewed and reconciled—is another. That negotiation is the hard problem and deserves its own deep dive.
One pattern, many homes
Others are converging on this pattern from different directions. The note-taking app Bear stores notes locally on Apple devices and synchronizes via iCloud, and now exposes them to local agents through MCP; its latest release lets users include or exclude notes by tag when granting access. Craft’s MCP connections let users select which documents or spaces an agent can access and whether it can read or write them. Reflect is building an open-source client using Markdown files that will have an iOS companion app.
I haven’t yet seen the attribution and provenance of items an agent contributes or edits become widespread—something I think a durable personal context requires.
Principles any system should follow
Here are the principles I believe are necessary, wherever a system makes its home:
- Context shouldn’t be captive to any particular agent. People should be able to change or combine agents without starting over.
- Context should be reachable by local and remote agents alike, with appropriate authentication and authorization.
- Permissions should be scoped and revocable. Access should be granted to a specific agent connection, limited to a defined subset of context, and distinguish between reading, proposing, changing, and deleting.
- Provenance should persist. Every item should record where it came from, who or what created it, and how it has changed. The distinction between human-written, agent-captured, and collaborative work should outlive the conversation that produced it.
- Time should be part of the context. The system should preserve when something was observed, when it was true, and how it changed—rather than continually overwriting the past with the present (a bitemporality concept).
- Entities should be first-class. People, companies, places, and recurring concepts should remain recognizable as names, roles, and relationships change.
- Interoperability should not require uniformity. Different people and companies can build different context systems for different ecosystems and trust boundaries; what is needed is agreement on identity, permissions, provenance, and exchange. For exchange, plain text files with structured metadata are a strong candidate.
Using these principles, personal context can be something a person owns: inspectable, grantable, revocable, traceable, and exportable. Every agent may still develop its own private understanding of you, but you’ll be able to bring a durable context of your own to the relationship—one that participates in the agentic ecosystem without being subordinate to any vendor.
Karpathy’s LLM Wiki is a description, not a tool; it’s meant to be implemented in whatever form fits. I offer this essay in the same spirit. It’s less important whether the app I’m tinkering with ever ships beyond my devices than the conversation it helps start: how everyone can have personal context that works for them, in their ecosystem and with the agents they want. If we get the pattern right, changing agents won’t mean changing homes. The context they help us build will remain ours.
