Most AI features start by not knowing who the user is. You build the feature. The user types context into a chat window or fills a profile. The feature gives a generic answer dressed up as a personal one.
Mandaire starts from the opposite position. The personal knowledge graph is already built: resolved entity graph across every communication channel, 20-plus years of correspondence, calendar history, AI session write-back, cross-source synthesis. Your AI connects once via MCP and can read it. The verb shape is the same for every call. The personal context is already there.
These are three patterns that become straightforward when that is true, and complicated or impossible without it.
All three patterns use the same MCP endpoint. Connect Claude Desktop, ChatGPT, Gemini, or any MCP-compatible AI to https://mcp.mandaire.com/mcp. Full verb documentation at mandaire.dev/for-developers/.
Pre-event context enrichment
The person has a meeting in 30 minutes. Who are they meeting? What is the last thing they discussed with that person? What did they commit to since the last time they saw them? Is there anything unresolved between them?
Without a personal knowledge graph, you cannot answer any of these questions. Your AI does not know who these people are, what the history is, or what is currently open. You either skip the context entirely or build a manual note-taking system and hope the person fills it in.
With Mandaire, one call pulls all of it.
The response includes: relationship context (how they know the person, how strong the connection is), recent communications (last contact, thread summaries, tone), open commitments in both directions, and any active situations that involve them. The disclosure engine has already run. The response is pre-filtered for the caller's viewer relationship to the person whose graph is being read.
Where this fits in a product: a calendar integration that fires 30 minutes before any event with named attendees. A meeting preparation app. A CRM that surfaces relationship context before a sales call. An executive assistant feature that prepares a person for who they are about to see.
Context that answers differently for different people
An owner and a viewer ask the same question. They should not get the same answer.
The owner asks: "What should I know about my health this week?" The response surfaces recent check-in data, medication cadence, and anything that warrants attention. The owner's manager asks the same question. The disclosure engine blocks health-class data for employer-category recipients before the response is composed. The query runs. The data is in the graph. The response is structurally indistinguishable from an empty result. The employer sees: "I don't have information on that."
This is not a prompt instruction. It is not a system message telling the AI to be careful. It is a deterministic policy engine that runs upstream of the model, before the model sees the context. The model cannot accidentally surface what the policy has blocked. There is nothing to hallucinate around.
From your side as a developer, the behavior is automatic. Your AI calls Mandaire. The response it receives has already been filtered by the disclosure engine for the viewer relationship of the authenticated caller. You do not implement the policy. You consume the result.
The disclosure_applied field in every response tells you what happened. filtered: false means the full context was returned. filtered: true means the disclosure engine held something. The absent_knowledge_caveats field tells you which topic categories were restricted, so your AI can acknowledge the limitation rather than inventing an answer.
Where this fits in a product: any personal AI feature with multiple viewer types. A family coordination app where the shared AI knows which details each family member should see. A professional tool where the AI knows what the owner has made available to colleagues. An assistant that a person has configured to answer questions on their behalf, with controls over what gets answered and for whom.
Read what you need, store nothing
Traditional personal AI architecture: collect user data, store it on your end, query it on demand. This works, but it creates a compliance surface you now have to maintain. Every piece of user context you store is a GDPR Article 17 deletion obligation, a breach liability, and a reason for the user to distrust you before they have tried your product.
The alternative: read at query time, discard after session. Your AI connects to the user's personal knowledge graph, reads the context your feature needs, composes a response, and discards everything. Nothing is stored on your end. The user's data never touches your database.
The read-not-store architecture also means your feature is always current. You are not maintaining a stale copy of user context that requires a sync strategy. You are reading the canonical personal knowledge graph at the moment the user needs something from it. The data is as fresh as the user's most recent email, calendar event, or AI session write-back.
The compliance consequence is structural, not just architectural. You have no context to delete, because you never stored any. Data access requests become answers about your own system: "We do not hold personal data about you. Your data lives in your Mandaire personal knowledge graph." You become a reader of a resource the user owns, not a holder of data about them.
Where this fits: any personal AI feature. The pattern applies to meeting preparation, email drafting, calendar context, relationship history queries, or any feature that benefits from knowing who the user is dealing with and what the history is. The Mandaire read verb is designed to be called at render time. The endpoint is stateless from your side. The context lives in the user's graph, not in your infrastructure.
The common thread
All three patterns share the same property: they require knowing the person, not just the query. Without a personal knowledge graph, each pattern requires either significant infrastructure to approximate or falls back to a prompt-based approximation that is inaccurate by design.
The MCP verb shape is the same for all three. Connect once. Authenticate once. The specific from_kind and from_match parameters select what you need. The disclosure engine runs before the response is composed. The response arrives pre-filtered.
Full verb documentation, response field descriptions, the five tools, INSERT patterns, and common anti-patterns are at mandaire.dev/for-developers/. Developer FAQ at mandaire.dev/faq/.
Mandaire is in private beta. If you are building something that would benefit from a personal knowledge graph as a read-time context layer, request a seat.
Request a developer seat