Field Notes

Your Memory is Someone Else's Asset

Every app is becoming a tool your AI can use. Your assistant will know more about you and do more on your behalf. Who owns that memory, and who holds the approve button?

Jacob Rogelberg
October 19, 2026 · 5 min read

This post was written through an MCP server. I talk to Claude, and Claude drives my blog. I never open the editor.

It's a small change in how I publish, but it points to a much bigger change in who controls the software I use.

MCP gives assistants a common way to connect to tools and data. As more apps expose those connections, more work can start with a request instead of an app. Update the design. Find the document. Publish the post.

The apps become plumbing and the assistant is the front door.

Separate apps collapse into one front door: the assistant.

    And the more you work through that front door, the more expensive it becomes to leave.

    Your memory is someone else's asset

    An assistant gets more useful as it learns your projects, your people, and how you like to work. It knows what you mean when you say, “Make it sound like me.”

    That context takes work to build and much of the work is yours.

    Even if another model gets better, it still has to catch up to you, and switching costs are real.

    What owning your 'memory' would look like

    I want my memory to live somewhere I control, with assistants connecting to it on my terms.

    That shouldn't require running a server. It could be a service I pay for. Ownership should mean I can inspect it, correct it, move it, and choose who gets access.

    In practice:

    One memory, multiple assistants. Switching models doesn't mean starting over.

    Specific permissions. “Claude can read my work projects for 30 days.” My family history stays out of it.

    Traceable changes. I can see what an assistant added, where it came from, and undo it. An inference about me shouldn't quietly become a fact.

    A usable exit. I can take the memory and its history to another provider. Recovery works when I lose a device.

    Encryption and keys belong underneath that experience and most people shouldn't have to think about them.

    There is a limit: once a remote model receives information, revoking access can't make it unread that information. Control over future access matters, but it isn't a promise that every past copy disappears.

    The plumbing already works

    Pieces of this exist. Mem0's OpenMemory provides a local memory server for MCP clients. Basic Memory stores knowledge in editable Markdown files and offers local and hosted options. MacPaw's Portable Memory proposal describes an open format for moving memory across vendors.

    These are real steps. But connecting an external memory tool is different from making it the memory your assistant uses by default.

    A lab has a reason to help you bring context in: it makes switching to its assistant easier. It also has a reason to make its own memory indispensable once you arrive.

    That's the tension. The same context that makes the product better can make the customer harder to lose.

    The plumbing works. The incentives don't.

    Portability needs someone with a reason to make it happen

    Phone numbers offer a useful precedent. US wireless number portability began rolling out under FCC rules in November 2003. You could change carriers without making everyone learn a new number. The number stopped being such a powerful reason to stay.

    Memory is harder. It's messy, personal, and interpreted differently by different models. Moving the same file won't make two assistants behave identically. But keeping your history would give the next assistant a place to start.

    Regulation is one route. Another is a company that benefits when models become interchangeable. Apple could sell the device that holds your memory. An independent provider could charge to keep it available to whichever assistant you choose.

    Either could also become the next gatekeeper. So the test has to apply to the memory provider too: can I leave without rebuilding my life?

    Who holds the approve button?

    Memory is only half the relationship. The other half is permission.

    “I prefer morning flights” is a memory. “You may spend $600 booking one” is authority.

    An assistant needs the first to make a good recommendation. It needs an explicit grant for the second.

    I want a personal wallet that holds those grants: which agent can act, on what, within which limits, and until when. I should be able to change assistants without handing each one permanent access to everything.

    Imagine telling an agent to book a refundable morning flight for under $600. It finds one for $540. The wallet checks the actual booking against the rules I approved. A $720 ticket, a nonrefundable fare, or a different passenger requires a new decision.

    For that to work, the wallet needs something stronger than the agent's reassurance. It needs verifiable transaction details, and the service executing the purchase has to enforce the authorization.

    Otherwise, the approve button is decoration.

    AP2, the Agent Payments Protocol, provides part of that foundation through signed mandates that capture purchase and payment authorizations. Google contributed it to the FIDO Alliance in April 2026, putting further standards work into an industry body.

    That is encouraging. It doesn't settle who designs the screen, whose interests it serves, or whether the person tapping “approve” understands the commitment.

    Researchers have already demonstrated prompt injection against an AP2-based shopping agent, manipulating recommendations and extracting sensitive information. Signing a transaction doesn't establish that the agent made a sound decision before it asked for a signature.

    The interface has to earn the approval. Show the purchase, recipient, total, and consequences. Let people set narrow rules for routine actions. Ask again when those rules change. Treat access to sensitive information as a meaningful permission too.

    If everything asks for confirmation, confirmation becomes a reflex.

    The company building the assistant can propose an action. I want the authority to approve it held somewhere I can choose independently, with limits the assistant cannot rewrite for itself.

    In the future, I should be able to ask a different assistant to publish the next post. It should have access to my writing preferences, connect to the same blog, and follow the same permission rules.

    It might do a better job. It might do a worse one. That's what I should be choosing between.

    And I want an assistant that knows me well. I don't want it to be the reason I can't leave.