The standard approach to building a personal AI feature is: collect user data, store it in your database, run your AI over it, return a result. This architecture is familiar. It is also increasingly expensive to defend.
Every user whose email history or message thread or calendar you store is a data subject with rights under GDPR, CCPA, and a growing set of state laws. Every breach of that data is your liability. Every subpoena reaches your servers first. You are not building a product; you are also building a data custodian operation that runs in parallel to it.
There is a different architecture. You do not store the context. You read it.
What the swappable brain proved at WWDC
Apple's Extensions Framework announced at WWDC made explicit what the architecture implied: the reasoning engine is a commodity. Gemini by default, Claude and ChatGPT as user choices. Apple spent a reported billion dollars a year licensing a rival's model because building the brain is not the durable problem.
If the brain is a commodity, then building AI products on top of that commodity layer is building on someone else's infrastructure. The question for product builders is not which reasoning engine to use. It is where the context lives and who owns it.
The durable layer is the context: the user's history, resolved entity graph, and accumulated inferences. It is durable because it compounds and because it cannot be replicated by switching providers. It is also the layer that carries the most regulatory weight.
You do not need to hold your users' context to build useful products on top of it.
The read-not-store architecture
MCP (Model Context Protocol) is the interface that makes this possible. Your AI renderer connects to the user's context store via MCP and reads what it needs. The user authorizes each connection. The context lives on a server the user controls, not yours.
From your AI's perspective, this looks like a function call:
The result comes back with a confidence score, a disclosure flag confirming policy ran, and rendered text your AI can use directly. You do not store it. You read it at query time, use it to inform the response, and discard it when the session ends.
The user retains full ownership of the underlying data. If they revoke your authorization, your AI stops seeing their context immediately. No deletion workflow. No data portability request. Nothing left on your servers to audit.
What the disclosure layer does for you
The second benefit of the read-not-store architecture is that the disclosure policy runs before the data reaches you.
When you store user data, you are responsible for what your AI does with it: whether it surfaces health information to an unauthorized caller, whether it leaks financial context into a context window shared with an employer-class recipient. These are failure modes you design against, test against, and get audited for.
In the read architecture, the disclosure engine runs upstream of your AI. The Mandaire response includes a disclosure_applied field confirming that per-recipient policy was evaluated before the result was composed. You receive only what the user has authorized the current caller to see. You do not re-filter; the filtering is already done.
Your AI gets accurate, pre-filtered context. The user gets a system that enforces their disclosure preferences. You avoid the compliance surface that comes with storing the raw data.
What this is not
This architecture does not eliminate your responsibility for the outputs your AI generates. If your AI produces a response based on Mandaire context, that response is yours. The data provenance is clean; the AI judgment still requires your product to get right.
It also does not mean you build nothing. You build the AI layer: the prompt engineering, the response formatting, the product experience, the features your users care about. You do not build the context infrastructure. That is the part you read.
The practical implication
If you are building a personal AI feature today, you have two choices. You can collect, store, and maintain user history yourself. Or you can read it from a context store the user already owns and controls, connect via MCP, and focus your engineering on the product layer rather than the data custody layer.
The second architecture is available now. The endpoint is https://mcp.mandaire.com/mcp. OAuth runs on first connect. The context is ready.
Mandaire exposes a single MCP server. One connection gives your AI access to the user's full context: entity graph, communications history, calendar, AI conversation history, and disclosure-filtered responses. No data stored on your end.
Read the developer docs