Skip to content

Personal Memory as a Service (Discussion)

Status: discussion — explicitly deferred, not a commitment. This is a vision/exploration document, not a spec and not a roadmap item. It records why the option is attractive, how it would relate to Thinklio architecturally, and what would have to be true before it is worth building — so the architectural seams are preserved cheaply while the product bet is postponed. It depends on, and would reuse, the Memory as a Service proposal. Do not run the docs index/changelog maintainer against this file.

Precis

Imagine memory that belongs to a person, not to an app or an organisation — durable, portable, and consumable by any AI tool the person authorises. Claude, ChatGPT, Cursor, Thinklio: each reads from and writes to the same persistent memory of you, under your control, with per-app grants you can inspect and revoke. This is the core idea of Nate B. Jones's Open Brain ("one brain, every AI plugs in"), and it is the one durable insight worth carrying out of that project: memory as a portable, user-owned service.

The thesis of this document is a sequencing one. Do not build this as a product now. Build Thinklio's memory well first — boundaried, governed, efficient (per the Memory as a Service proposal) — and a personal-memory product becomes largely a copy of that service pointed at its own Convex database(s) under a different tenancy model. You de-risk the hard product by building it as a feature, then graduate it. This mirrors how ADR-022 treats tenancy: prove the pooled default, design the seam, graduate on demand.

1. What Open Brain is, and what we take from it

Open Brain's core is deliberately tiny: a single Supabase thoughts table (content + vector + jsonb metadata), a semantic-search RPC, and one MCP server exposing a handful of tools (search, capture, list, stats). Around that core sits a large community layer (extensions, recipes, skills, schemas, integrations). The pitch is memory portability across every AI client via MCP, deployed remote-only.

What we take is the product posture, not the code (Open Brain is FSL-1.1-MIT — no commercial derivatives; ideas and patterns only):

  • Memory as a service other tools consume over a stable protocol (MCP/HTTP).
  • The user as the owner and the boundary — the memory follows the person, not the app.
  • Governed agent-memory — their instruction-vs-evidence use-policy, already adopted into Thinklio's memory service (Memory as a Service proposal §6).

What we do not take: Open Brain is single-user-first on Postgres with one shared key; Thinklio's memory is reactive, governed, multi-tenant on Convex, and (per the wiki proposal) goes far beyond a flat thoughts table. Our memory model is the more capable substrate.

2. The leverage thesis

Phase A (now):   Build Thinklio memory as a boundaried, governed Convex service.
Phase B (later): Same service code → own Convex deployment(s) → personal-memory product.
                 The deployment + tenancy model is configuration, not a rewrite.

Everything hard about a personal-memory product — retrieval quality, the use-policy/governance model, extraction and the compiled wiki, the MCP/HTTP contract, GDPR export/delete — is already required for Thinklio's own memory. Solving it once, behind a clean boundary, means the personal product inherits a proven engine. The net-new work for the product is the tenancy model and the grant surface, discussed next.

3. The second tenancy domain

This is the crux, and the part that must not pollute Thinklio's existing isolation. Thinklio's entire tenancy security rests on one non-negotiable invariant (doc 15 §2.2): every tenant row carries accountId, and isolation rides on the org claim in the verified JWT. Personal memory breaks that by definition — it belongs to a person and spans multiple accounts and apps.

So personal memory is not "a fifth value on the four-layer knowledge scope." It is a separate isolation root keyed on the global user identity (the Clerk user already is global and may belong to many accounts — doc 15 §1.1). Two tenancy domains over one substrate (the memory service code):

Account-domain (Thinklio today)          Person-domain (the product)
  isolation root: accountId                isolation root: userId (global)
  boundary: org claim in JWT               boundary: the user's own identity
  data: chats, tasks, KB, wiki, agents     data: personal facts, profile, ingested docs

Keeping these as distinct domains, not one merged hierarchy, is what preserves Thinklio's account-isolation invariant intact. Note the existing knowledge model already holds user-scoped knowledge back from the shared corporate wiki (wiki proposal §8: entity scope is "never user — this is a shared KB"). A personal wiki/memory is therefore a parallel structure with the same machinery and a different isolation root — not an extension of the corporate KB. Do not fuse them.

4. The capability-grant model ("Clerk/Plaid for personal AI memory")

The connection between the two domains is not the account JWT. It is an explicit, user-granted, scoped capability:

  • A service (Thinklio, or any outside tool) accesses only the slice of a user's personal memory the user has granted it — an OAuth-style grant / scoped MCP token.
  • The user accesses all their personal memory plus the per-service slices that relate to them.
                 ┌─────────────────────────────────────┐
                 │   Person-domain memory (userId)      │
                 │   profile · facts · ingested docs    │
                 └───────────────┬─────────────────────┘
        grant: read profile,           grant: read+write
        write decisions                 work notes
                 │                          │
          ┌──────▼──────┐            ┌──────▼──────┐
          │  Thinklio   │            │  ChatGPT /  │
          │  (an app)   │            │  Cursor /   │
          └─────────────┘            │  any MCP    │
                                     └─────────────┘

The grant graph is the genuinely new primitive. It composes with Thinklio's polymorphic-principal identity (ADR-025) — a tool acting "on behalf of" a user is a principal whose reach is bounded by the grants the user issued. Every access is still a governed principal through the memory service's harness (Memory as a Service proposal §5).

5. What personal memory holds

The distilled-not-raw boundary (Memory as a Service §2) matters even more here, because this is the user's most personal data:

  • Profile / preferences / the "about me" — how I write, my standing decisions, my goals, my people-graph. This is the highest-value, most-portable category and the thing that makes a connected tool feel like it knows you.
  • Distilled facts and curated documents the user chose to keep.
  • A personal compiled wiki (optional) — the same compiler, user-rooted.

Explicitly not in personal memory: raw transcripts and logs (sources, not memory — and a privacy liability at rest), and credentials (a separate vault; a memory product that also custodies secrets is a far larger liability surface — keep them apart).

6. Ingestion and consumption surfaces

The product's reach comes from how easily a person can feed and use it:

  • Ingestion: a share sheet ("add to my memory" from anywhere), a watch folder, and connectors to Drive / OneDrive / Dropbox / Notion — many of which Thinklio is building as services anyway (the service library, ADR-028). Each ingest path runs the same extraction/distillation pipeline.
  • Consumption: any tool connected via MCP/API can search and capture, under its grant. This is the Open Brain "every AI plugs in" promise, with governance and per-app scoping added.

7. GDPR and portability as native properties

Counter-intuitively, the personal store makes some compliance easier than the account store:

  • The user is both the data subject and the controller of grants; export and delete are per-userId, not the painful per-accountId cascade doc 15 §6 describes.
  • Recall traces (Memory as a Service §7) answer "what did this connected tool actually see about me" directly.
  • Portability is the product, not a feature bolted on — the user can take their memory elsewhere by definition.

But the custodial burden is real: see risks below.

8. The honest risks

This is a second company, not a Thinklio feature, and should be judged as one:

  1. Custody liability. You become the keeper of users' most personal data across all their tools. That is a moat if flawless and an existential liability if breached. The trust and security burden exceeds Thinklio's own.
  2. Compliance surface. Cross-app personal data raises thorny controller/processor questions that a single-tenant SaaS does not.
  3. GTM is different. Personal/prosumer distribution and pricing differ entirely from Thinklio's B2B motion.
  4. Focus cost. Thinklio does not yet execute agents (Phase 1→2). Building a personal-memory product now would be a serious detour from the primary bet.

The mitigation is exactly the sequencing thesis: don't build it now. Build the engine inside Thinklio, keep credentials out of memory, design the boundary and the two-domain seam, and revisit when (a) Thinklio's memory is genuinely good and (b) there is evidence of pull for a standalone product.

9. What to preserve now (cheap), what to defer (the build)

Preserve now — already covered by the Memory as a Service proposal:

  • The memory service boundary (all access via the contract).
  • Memory addressable by principal (ADR-025), so a user-rooted domain is not a foreign concept.
  • The use-policy and recall-trace primitives.
  • Keeping the personal/parallel KB conceptually distinct from the corporate wiki.

Defer — the product itself:

  • The Person-domain tenancy model and the capability-grant surface.
  • The dedicated Convex deployment(s) and provisioning.
  • Ingestion connectors as personal (vs Thinklio-account) sources.
  • Prosumer GTM, pricing, and the standalone trust/compliance programme.

10. Open questions

  1. Is the personal product Thinklio-branded or separate? Brand, identity (shared Clerk vs its own), and how a Thinklio user's account-memory relates to their personal-memory.
  2. Grant model mechanics — token format, scopes, revocation, and whether it reuses the Integration API registration/approval model (doc 09 §1.3).
  3. Profile/people-graph schema — shared with the Memory as a Service §11 Q3; the personal product leans hardest on it.
  4. Cross-domain reference — if a Thinklio agent is granted access to a user's personal memory, how that grant is represented and audited across two deployments.
  5. Trigger conditions — the concrete signals (Thinklio memory maturity; demonstrated pull) that would move this from discussion to proposal.

11. Revision history

Date Change
2026-06-15 Initial discussion document, arising from the Open Brain / Nate B. Jones design conversation.