Unified Personal Intelligence Infrastructure

A research note on the missing substrate between users and their agents.

DataFrontier Team — Ongoing research — ~12 minute read

Personal context is a primitive, not a feature. Today's AI stack has models, agents, and connectors, but it has no user-side memory and identity substrate that outlives any single app and that the user actually controls. We call the missing layer Unified Personal Intelligence Infrastructure. This note states the thesis, names eight primitives that compose the substrate, describes a near-term wedge that tests the thesis with a single sitting of user experience, and lays out six open research questions whose answers determine whether the substrate is real. The contribution is not better agent memory. It is moving memory out of the agent.

1. Motivation

The failure of today's personal AI is not that the models are dumb. The memory of you is in the wrong place.

Eight failure modes are visible to anyone who uses ChatGPT, Claude, Gemini, and Copilot in the same week. Seven are structural; one is partly product immaturity but inherits a structural problem the moment the obvious next question is asked.

Context resets at the session boundary. A user spends forty minutes in Claude explaining a codebase, constraints, and a taste in API design. The next day, a new chat starts from zero. Projects and "memory" features paper over this with auto-summaries, but the summary is the model's lossy compression of the user, not the source of truth. A better model does not fix this; the substrate is in the wrong place.

Each assistant holds a private profile, and none of them agree. ChatGPT classifies the user as a Python developer because that is what has been pasted into it. Claude classifies them as a strategy consultant because that is the use case at work. Gemini infers location from a Google account. Copilot assumes Go. All four are partially right, none of them can be reconciled, and there is no single page where the user can correct them.

Switching costs are paid in context, not dollars. The reason a user does not move from ChatGPT to Claude is not price or capability. It is that every preference, project, and prior conversation the incumbent has accumulated would be lost in the move. This is lock-in by memory hoarding. It is load-bearing for the vendors' business model, which is why the vendors will not fix it.

Agent handoffs lose most of the context that made the previous step useful.¹ An agent researches vendors; a second agent (or the same agent in a new tool-use chain) drafts an email to the top candidate. The email agent has no idea what "top" meant, what tradeoffs were weighed, or what tone the user uses with this kind of recipient. The workaround — stuffing the prior conversation into the next prompt — is brittle, lossy, and breaks the moment the chain involves a different vendor.

"Personalization" is surveillance with a friendlier UI. The vendor sees everything the user tells the assistant; the user sees a checkbox labeled Memory: on. The user cannot inspect the full representation held of them, cannot diff it against reality, cannot grant a specific agent read access to a specific slice ("you can see my work projects but not my health notes"), and cannot revoke.

Cross-app context is manual copy-paste. A long email is read in one tab, pasted into the assistant in another, a reply is generated, copied back. The assistant has no native handle on inbox, calendar, files, or browser history unless a connector is wired up per vendor per app — and even then, the connector is read-only at query time, not a durable representation. This is the one failure mode that is partly product immaturity: connectors are improving. The structural problem returns the moment the obvious next question is asked: whose connector, into whose memory?

There is no "you" the assistants can converge on. Ask three assistants what the user's goals for the quarter are. Three different answers come back, all hallucinated from thin context, because there is no canonical, user-owned place where the user's goals live such that any model can read them with permission. The user is forced to be the integration layer.

Failures compound silently in long-horizon agent work. A chat mistake is visible — the user reads the bad answer and corrects it. An agent mistake on step 3 of an 11-step plan, made because the agent did not know a constraint mentioned to a different agent last week, surfaces as a wrong outcome with no obvious cause. The longer the horizon and the more tools involved, the more the missing shared-context substrate shows up as inexplicable failure rather than wrong text.

The pattern: the memory of the user is scattered, vendor-owned, non-portable, non-inspectable, and rebuilt from scratch at every boundary. That is the gap UPII names.

2. The UPII Thesis

Unified Personal Intelligence Infrastructure is the claim that an individual should have a single, persistent, user-owned substrate — a personal context graph — that sits underneath every model, agent, and application they use, and that today's stack has no such layer.

The load-bearing claim is that personal context is a primitive, not a feature. A typed, addressable, permissioned store of who the user is, what they have done, what they know, who they know, and what they are working on, with a stable identity and an interface (read / write / subscribe / revoke) that any model or agent can bind to with the user's consent, the same way filesystems and DNS are primitives that applications bind to rather than reinvent.

For "Unified Personal Intelligence Infrastructure" to be the correct name, three things have to be true about the world.

Intelligence is becoming plural and ambient. Work routes across many models and agents per day, so context cannot live inside any one of them.

The bottleneck on usefulness is shifting from model capability to context quality. Whoever holds the richest, freshest representation of the user produces the best output, which makes the location and ownership of that representation a first-class design question.

The natural owner of that representation is the person, not the platform. For alignment reasons — the model serves the user better when their context is not filtered through a vendor's business model. And for portability — the user should be able to fire a model without losing themselves.

If those three hold, then infrastructure is the correct framing rather than app or feature, personal is the correct scope rather than enterprise or team, and unified is the load-bearing adjective. The whole thesis collapses the moment the context re-fragments.

The analogy that holds the thesis together is DNS and the operating system: DNS works because there is a protocol and a root; filesystems work because the OS mediates between applications and the underlying storage. UPII's equivalent of "the root" is the Identity Root described in § 3. Its equivalent of "the OS" is the Retrieval Interface and the Capability Ledger, which together mediate between agents and the substrate. The remaining primitives are what makes the whole thing a substrate rather than a database.

3. Architecture

Eight primitives compose UPII. The layering matters: identity is the floor, retrieval is the ceiling, and the middle six are what makes the substrate work as a substrate rather than as a database with a schema.

graph TB
  subgraph Interface ["Interface Layer"]
    RI["Retrieval Interface<br/>query · search · traverse · explain"]
  end
 
  subgraph Reasoning ["Reasoning Layer"]
    RS["Record Store<br/>typed · graph · semantic"]
    CU["Curator<br/>propose · accept · supersede · decay"]
  end
 
  subgraph Ingestion ["Ingestion Layer"]
    IB["Ingestion Bus<br/>append-only event log"]
  end
 
  subgraph Floor ["Identity Floor"]
    ID["Identity Root<br/>user-controlled keypair"]
  end
 
  subgraph CrossCutting ["Cross-cutting"]
    CL["Capability Ledger<br/>scoped · time-bound · revocable"]
    AT["Audit Trail<br/>tamper-evident log"]
    EX["Export Format<br/>portability primitive"]
  end
 
  IB --> CU
  CU --> RS
  RS --> RI
  ID -.authorizes.-> CL
  CL -.gates.-> RI
  CL -.gates.-> IB
  RI -.records to.-> AT
  IB -.records to.-> AT
  CL -.records to.-> AT
  RS -.serializes via.-> EX
  ID -.signs.-> EX
 
  classDef floor fill:#18181C,stroke:#C9A876,color:#F4F4F5
  classDef cross fill:#111114,stroke:#2A2A30,color:#A1A1AA
  class ID floor
  class CL,AT,EX cross

The Identity Root

A user-controlled keypair (or recoverable equivalent) that is the canonical who any agent or model resolves to. Not an account on a vendor's server — a cryptographic principal the user holds and can rotate without losing continuity. Exposes: sign, verify, rotate-with-continuity, prove-equivalence-across-hosts. This is the floor; everything above only works because there is a stable, portable answer to whose context is this?

The Record Store

Typed records with relations, free-form attached content, and embeddings derived from both. Not a knowledge graph (too rigid), not a document store (too unstructured), not a vector index (loses relations) — all three composed, because personal context is genuinely heterogeneous. "My brother's name is Anand" is a typed fact. "The email Anand sent me last Tuesday" is a document. "Things I have said that sound like this" is a similarity query. Exposes: put(record, source), get(id), query(typed-predicate + semantic + graph-traversal), subscribe(filter). Multi-host sync is a property of the store (event-sourced and CRDT-shaped under the hood), not a separate primitive.

The Ingestion Bus

An append-only event log fed by many writers: conversations, app connectors, device captures, manual entry, agent outputs. Every event carries source attribution and a writer signature, so provenance survives all the way to retrieval — when a model later reads "the user lives in Bangalore", it can trace the claim to the conversation, connector, or self-assertion it came from. Exposes: append(event, source-credential), replay(since), attest(event). The raw log is preserved separately from curated knowledge; this is where everything lands before the next primitive decides what is worth keeping. The design draws on event-sourcing patterns established outside this work.

The Curator

The bridge between raw log and durable knowledge. Proposes promotions from the event log into the record store ("you mentioned a new job title in this conversation — store as a fact?"), accepts confirmations, supersedes prior records, and decays stale ones. Runs as automated policy, user-in-the-loop, or both. Exposes: propose(record, evidence), accept, reject, supersede(old → new), decay. This is the load-bearing piece for memory formation — without it, a chat log exists, but not a substrate. Redaction ("forget X") is a Curator operation, not a separate primitive: supersede with a tombstone, write the redaction event to the audit trail.

The Curator is not RAG with a friendlier name. Retrieval-augmented generation is silent embedding refresh against an indexed corpus. The Curator is propose / accept / supersede / decay as first-class operations with user-in-the-loop attestation. The unit of work is different. The auditability is different. The failure modes are different.

The Capability Ledger

Signed, scoped, time-bounded grants that an agent presents to access a slice of the store. Capability-based rather than ACL-based, because there is no central authority that knows about every agent: the user mints a grant ("this drafting agent can read my work projects for the next hour, no writes"), the agent presents it, the store enforces it, and the grant is independently revocable. Exposes: mint(scope, ttl, rights), present, revoke, list-active. OAuth scopes are the closest existing analog, but they live inside vendors. This layer lives next to the user.

The Retrieval Interface

What models and agents actually call. A single protocol that combines typed query, semantic search, and graph traversal, all gated by the capability presented with the call. Exposes: query(predicate, capability), search(natural-language, capability), traverse(start, edges, capability), explain(result → evidence). Binding is MCP-shaped — any model can speak it — but the contract is owned by the substrate, not by the vendor consuming it. The explain verb is non-negotiable: every returned fact must carry the evidence trail back to ingestion, or downstream agents cannot reason about what to trust.

The Audit Trail

A tamper-evident log of every read, write, grant, and revocation. Not just for compliance — for inspection: the user must be able to ask "what does any agent know about me, who has been reading it, and on what authority?" and get a complete, verifiable answer. Exposes: record(access), query(by-agent, by-record, by-time), prove(trail-integrity). This is what makes the surveillance-with-a-friendlier-UI critique in § 1 falsifiable rather than rhetorical. The test for UPII is whether the user can run that query and get a real answer.

The Export Format

A standardized serialization of records, relations, attached content, identity proofs, and audit trail, such that a user can lift their substrate off one host and re-land it on another without losing continuity. Exposes: export(scope, capability), import(blob, identity-proof), verify(blob ↔ identity). The DNS registrar analogy is exact: identity stays, host changes, everything resolves the same way the next day. Without this primitive, user-owned is rhetorical. With it, the claim is enforceable by exit.

4. The Wedge

The first thing to ship is a cross-vendor context broker: a single user-owned process — browser extension plus local daemon, topology is implementation detail — that sits between the user and every LLM product they use, injecting the right slice of their substrate at the start of each session and capturing what is worth keeping at the end.

A single-sitting experience tests the thesis.

Install and onboard (ten minutes). Ingestion pulls from one or two sources the user already has — most plausibly Gmail, a Notion workspace, or a local notes folder — plus a short five-question interview: what are you working on right now, who do you work with on it, what is your role, what should no model ever assume about you, what is the recipient list you draft to most often. The Curator promotes the answers into typed records; the rest sits in the event log.

Open ChatGPT, start a real task. The broker detects the page, mints a capability ("read: work-project records and personal-style records; write: append new claims for curation; ttl: this session"), and prepends the relevant slice to the user's first message. A small banner appears: "Sharing 14 facts with ChatGPT — review." The user clicks through. The conversation runs with full context, no copy-paste, no re-explanation.

Switch to Claude in the next tab. Same thing happens. Same identity, same context, different vendor. The user notices viscerally that they did not have to re-introduce themselves to the second tool.

End of session: open the substrate UI. A feed appears: "ChatGPT read these 14 facts at 3:42 PM. Claude read these 11 facts at 3:48 PM. ChatGPT proposed 3 new facts for your record store; you accepted 2, rejected 1." The user revokes ChatGPT's grant with a click. The audit trail is intact and queryable.

That is the wedge.

Five of the eight primitives appear in the user's direct experience in a single sitting. The Identity Root is felt the moment the second tool just works without onboarding. The Record Store is what the banner lists. The Capability Ledger is the consent banner's mint / present / revoke. The Curator is the accept / reject review of newly proposed facts. The Audit Trail is the post-session feed. The Retrieval Interface is exercised under the hood as the path the broker takes when assembling the slice. Only the Ingestion Bus (mostly background after onboarding) and the Export Format (a month-six story, not a day-one one) sit off-screen.

The defensibility argument against "couldn't ChatGPT just ship this" is structural, not capability-based. The wedge's value is cross-vendor portability. The moment a vendor ships it, they are building their own off-ramp. The closest a vendor can credibly ship is "memory that you can export" — promised in various forms for two years, still delivered as lossy autosummary keyed to a vendor account. No single vendor can ship the broker, because the broker's job is to not be any vendor. This is the cleanest defensibility argument in the thesis: it does not depend on UPII being technically better, only on vendors not being structurally able to build it.

The surface is product first, protocol shadow. v0 is a real installable product (extension plus local daemon) that brokers against today's vendors using whatever input/output channel each one exposes — prompt prepending where there is no API, real APIs where there are. Behind it, every interaction is mediated by the same internal contract (mint → present → query → curate → audit), and that contract is the seed of the eventual protocol. Shipping the product first generates the artifacts a protocol effort needs — usage traces, real grants, real complaints, real revocations — which a protocol-first effort would have to invent.

Three other wedges were considered and deferred. A "what do you know about me" inspector that surfaces every fact any assistant has inferred or been told about the user, with delete, correct, and source-trace, has a strong privacy angle but exercises only three primitives, and vendors can credibly clone its appearance per vendor without ceding ownership of the underlying store. Unified personal recall — "ask anything about your own life" — has real consumer appeal, but it is recognizable as second-brain-shaped and the substrate claim disappears into "oh, like search across my stuff." A provenance-checked agent, where every claim in a drafted output is clickable back to its source, is sharp and developer-loved, but it is an agent feature, not a substrate moment, and lands better in v1 once the substrate has accumulated enough history to provide rich evidence.

The broker is the cheapest experiment that can falsify UPII's central claim. If users want cross-vendor portability badly enough to install a broker, the substrate is constitutional and the other seven primitives unfold from there. If they do not, then context lock-in is acceptable to them, and the whole thesis is wrong. That is exactly why it is the right v0.

5. Open Research Questions

Six questions are open. They are ordered roughly inner to outer: the Curator and the Capability Ledger are the primitives where research moves the substrate; provenance and multi-agent dynamics are where the substrate moves the field; evaluation is the meta-question that determines whether any of the rest can be tested; identity continuity is the floor problem that the rest assume.

5.1 What is the right unit of Curator promotion?

The Curator's central job is deciding what to promote from the ingestion event log into the durable Record Store. The choice of unit — sentence-level claim ("user lives in Bangalore"), episode-level ("conversation on 2026-03-12 about relocation"), or a hybrid where claims carry pointers back to their episode of origin — has not been studied empirically for personal-context use. Sentence-level promotion maximizes queryability and destroys context preservation; episode-level promotion preserves nuance and destroys retrieval precision. Worse, no objective function is established. Should the Curator be trained to maximize downstream task accuracy (noisy, slow), minimize per-session re-explanation rate (good but hard to measure), maximize claim-stability over time (defensible but circular), or optimize human acceptance rate in the propose/accept loop (operationally tractable, possibly biased)?

A research line here would build a benchmark of conversation streams paired with downstream tasks, train Curator policies at varying granularities, and map the Pareto frontier between retrieval precision and context fidelity. A subquestion falls out cleanly: when promoted claims contradict, what is the supersession policy — recency, source trust, or explicit user attestation — and what does the model actually see when it queries a contradicted record?

5.2 Is there a scope language that is both user-legible and enforceable?

The Capability Ledger requires a language for expressing what slice of the substrate an agent may read or write. OAuth-style enumerated scopes are user-hostile because they are authored by developers in vendor terms; ACL-style per-record grants are unscalable for any real user; topic-based scopes ("anything about Project Y") are intuitive but rely on the substrate to compute topic membership, which is itself an open problem.

The deep question is whether user-legible and machine-enforceable are compatible properties at all. A scope like "facts relevant to drafting an email to Anand" is interpretable to the user but requires intent-classification at grant time, with all the brittleness that implies. An experiment worth running: present users with multiple scope-language candidates (type-based, topic-based, intent-based, hybrid), measure both the accuracy of their grants (did they share what they meant to share?) and the enforcement quality on the substrate side (did the model actually only see what was scoped?), and look for the language that maximizes the product of the two. Capability-security literature provides a starting algebra for delegation and composition; it says almost nothing about whether the user can understand what they have granted.

5.3 Can provenance survive inference?

The Retrieval Interface's explain(result → evidence) verb is the substrate's anti-hallucination guarantee, and the entire user-side inspection story rests on it. Preserving evidence is trivial when the model returns a stored fact verbatim. It is hard when the model summarizes, infers, or composes across many records. Today's LLMs are unreliable at citation: they fabricate sources, attach generic citations, or attribute claims to the wrong evidence.

The research question is whether an architecture exists — constrained generation, evidence-as-input-token, retrieval-augmented generation with mandatory cite-or-abstain, post-hoc verification by a smaller model — that makes provenance faithful at acceptable utility cost. The measurable target is trace fidelity: for a held-out set of (query, response) pairs, what fraction of the load-bearing claims in the response correctly cite the records that produced them, and how does utility trade against trace fidelity? This is the substrate-side analog of mechanistic interpretability work, but the loss function is honesty about source rather than honesty about internal representation.

5.4 Under multi-agent write loads, does context quality compound or degrade?

The substrate is designed to be written to by many agents over time — drafting agents propose claims, research agents inject findings, summarization agents condense prior episodes. The open question is whether this produces a virtuous loop (each agent contributes signal the next one uses) or model-collapse-shaped degradation (agent outputs become inputs become outputs, biases compound, the substrate drifts away from the user's actual state).

The synthetic-data collapse literature is suggestive but not directly applicable. The substrate has two properties that pure self-training does not: a Curator with user-in-the-loop acceptance, and provenance that distinguishes user-attested from agent-attested claims. A clean experiment: simulate a substrate with N agents over T sessions, vary the Curator's policy on agent-vs-user attestation, and measure whether ground-truth-comparable user facts remain stable or drift. The hypothesis worth testing is that attestation-aware curation is the necessary condition for compounding — without it, multi-agent substrates degrade superlinearly with the number of writing agents, and the substrate becomes less useful over time, not more.

5.5 What is the right benchmark for a personal context substrate?

The substrate is a system-level intervention, not a model-level one, and no benchmark exists for it. Helpfulness averaged over a population does not measure the substrate, because the substrate's job is to make the model more useful to one specific person. Candidate metrics each have a flaw. Downstream task accuracy is noisy and confounded by model capability. User-reported usefulness is subjective and biased by novelty. Re-explanation rate per session is closer to the right thing but requires longitudinal study and a stable user.

A contribution worth making would be a benchmark suite where the same model is evaluated with and without substrate access, against tasks defined relative to a specific simulated user profile, with metrics that capture claim stability (does the substrate produce consistent answers about the same person across sessions, tools, and time?), grounding rate (what fraction of model assertions about the user are traceable to substrate evidence?), and contradiction frequency (how often does the model produce claims the substrate could have falsified?). Without a benchmark of this shape, every claim made for UPII — including the ones in this note — is anecdotal.

5.6 How does identity survive host migration?

The substrate is supposed to survive a registrar change: a user lifts their context off one host and re-lands it on another without losing continuity, the way a domain moves between registrars without losing its mail. The Identity Root and the Export Format are the two primitives that make this claim. The open problem is what continuity actually means once the substrate has been live for years.

Cryptographic key rotation under continuity is a known problem in the self-sovereign identity literature; what is unknown is how key rotation interacts with a substrate that other agents have outstanding capabilities against. When the user rotates from key A to key B during a host migration, what happens to the capability tokens that the user issued under key A? Hard revocation is safe but breaks every active agent. Lazy re-issuance is convenient but leaves a window of ambiguity. The same question applies to audit-trail integrity proofs issued under the old key — re-anchoring them under the new key preserves the user's verifiable history; failing to re-anchor it truncates the user's substrate at every key event.

A research line here would specify a continuity protocol that preserves outstanding capabilities, audit-trail integrity, and graph consistency across rotation, then prove (or disprove) that it leaks neither the old identity to the new host nor the new identity to the old host. The crypto machinery in DID and Verifiable Credentials work provides the primitives; the substrate-specific composition is the open question.

6. Related Work

Six neighborhoods, with what UPII inherits and what it does not.

Personal Knowledge Graphs and the Semantic Web. Solid (Berners-Lee and the W3C Solid working group) is the closest precedent for the broker described in § 4 — pods-plus-apps-request-access is structurally adjacent. UPII inherits the ownership thesis and the linked-data instinct that personal facts have types and relations. It diverges by being context-and-agent-first rather than data-storage-first, by treating schema as composed rather than canonical, and by adding a Curator — the propose / accept / supersede / decay loop has no Solid equivalent.

Capability-based security. From Dennis and Van Horn's original work through SPKI, macaroons, and UCAN. The Capability Ledger borrows the algebra: bearer tokens that are scoped, attenuable, delegable, and revocable, signed by an issuer that no third party needs to be aware of. The literature is about machine principals authorizing machine actions; the legibility of a scope to a human is treated as out-of-scope. UPII's contribution, framed in § 5.2, is treating scope-legibility as the central design problem.

Agent memory and LLM long-term memory. MemGPT, the Stanford Generative Agents work, Letta, and the broader long-term agent memory literature. UPII inherits the recognition that LLMs require durable memory beyond the context window. It rejects the architectural choice those systems make: the memory lives inside the model's process or the vendor's database, and the user does not own it, cannot inspect it, cannot grant scoped access to a third agent, cannot port it. UPII inverts this. The memory belongs to the user, agents are guests with scoped grants. The contribution is not better agent memory; it is moving memory out of the agent.

Personal recall and second-brain products. Rewind, Mem, Reflect, the broader Personal Information Management research tradition. UPII inherits the recognition that personal data is fragmented and that AI applied to one's own corpus is valuable. These are destination products — data lives in them, indexed for their search, summarized by their models. The substrate inversion is the whole UPII move: data lives in the user's store, products bind to it. Two consequences follow. The user can fire any product and the substrate persists. The same Record Store feeds many tools, not one.

Verifiable provenance and citation-faithful generation. RAG, ALCE, attributed question answering, Self-RAG, and the broader citation literature. UPII inherits the framing that model outputs should be attributable to identified sources, and the evaluation methodology around citation precision and recall. The literature evaluates attribution against an external corpus (Wikipedia, the open web) where ground truth is approximately knowable. UPII attributes against a personal substrate, where the corpus is the user's own lived record and what counts as correct provenance depends on whether the cited record itself faithfully represents the user's state.

Local-first, CRDTs, and self-sovereign identity. Local-first software (Kleppmann and collaborators), CRDTs (Shapiro and collaborators), DIDs, Verifiable Credentials, and the broader SSI movement. UPII inherits the local-first ideals as the user-side requirements of the substrate, treats CRDTs as the candidate machinery for Record Store sync, and adopts the DID-shaped identity model. The local-first literature is about collaborative documents with human consumers; UPII's consumers are agents. The SSI literature is about credential issuance to third-party verifiers; UPII's identity is about being addressable to one's own agents.

Two adjacent fields are deliberately not claimed as neighbors. Differential privacy concerns releasing aggregate statistics over many users with bounded privacy loss; UPII gates individual records to scoped agents on behalf of one user. The mathematics does not transfer. Event-sourced architectures (Fowler, Young) are an implementation influence on the Ingestion Bus and Record Store split, referenced in § 3; they are an engineering pattern, not an intellectual neighbor.

Full citations available on request to research@datafrontier.co. Citation-verification pass is pending; specific venue and year attributions for several works in this section are marked in the working draft.

7. What UPII Is Not

Seven readings the rest of this note invites have to be refused explicitly.

UPII is not a second-brain app or personal recall product. The destination-product framing is where a casual reader of § 4 will land. The difference is structural: a second brain is a place users go to find their stuff; the substrate is a place agents go to find the user. If users end up spending time inside a UPII app the way they spend time inside Mem, the design has failed; the substrate has become a destination, which means it has become another vendor.

UPII is not an AI assistant. Personal Intelligence invites this misreading. UPII does not have a chat interface, does not draft emails, does not reason about goals, does not hold opinions. It supplies context to systems that do. Confusing UPII with the assistant is the category error of confusing a filesystem with an application — both are personal in the sense that they hold the user's data, but only one of them generates output.

UPII is not agent memory research. The contribution is not better long-term memory for agents — not longer context windows, not smarter retrieval, not improved summarization, not more clever forgetting policies. Those are inside-the-agent problems. UPII's claim is structural and orthogonal: the location of memory matters more than its mechanics. Move memory out of the agent, give it to the user, and the questions about memory mechanics get asked in a different room — by the Curator, on the user's behalf, with a Capability Ledger in between.

UPII is not a privacy product. This is the most important disclaimer here, because it is the easiest one to drift into. Privacy properties — capability scoping, audit trail, user-side storage, the ability to revoke — fall out of the architecture for free. They are real. But the thesis does not stand or fall on them. If UPII shipped tomorrow and produced an order-of-magnitude improvement in personalized agent output across vendors, the thesis would be vindicated whether or not the privacy properties impressed an adversarial reviewer. Conversely, if UPII shipped with bulletproof privacy and produced no measurable improvement in context quality or portability, the thesis would be wrong. Privacy is necessary infrastructure for the substrate to be honest. It is not the substrate's reason for existing.

UPII is not a self-sovereign identity or data-rights project. § 6 cites the SSI and Verifiable Credentials lineage, and a reader of that section will reasonably ask whether UPII is SSI for AI. It is not. SSI and the data-rights movement treat ownership of identity and data as the goal of the work. UPII treats them as preconditions for a narrower goal: making AI useful to one specific person across many tools. The values overlap substantially; the framings do not.

UPII is not a protocol or standards effort. § 4 says product first, protocol shadow. The right discipline is to build the broker, run real grants and real reads against real users with real complaints, and let the protocol calcify out of working practice. The protocol falls out of the product; the product cannot fall out of the protocol. Time spent on a draft RFC in the next twenty-four months is time not spent on the v0 that would tell anyone whether the RFC matters.

UPII does not claim to solve alignment, obsolete vendor AI, or be "the operating system for the agent era." Alignment is a separate research program with different methods, and giving the user control of context does not change what the model is trained to optimize. Vendor models are the substrate's consumers; the substrate makes them more useful to one specific person, not less needed. The "OS for the agent era" framing flattens distinct layers (compute orchestration, identity, memory, policy) into a single grand claim. UPII is one of those layers, not the whole control plane. The honest claim is narrower: there is a missing primitive between the user and the agents; here is what it should look like; here is the v0 wedge that tests whether anyone wants it.

If a sentence anywhere in this note sounds like the substrate is solving more than the one problem named in § 1, that sentence is a draft error. § 7 exists to catch it before the reader does.

Cite this work

@misc{datafrontier_upii_2026,
  title  = {Unified Personal Intelligence Infrastructure},
  author = {{DataFrontier Team}},
  year   = {2026},
  note   = {Ongoing research. DataFrontier Innovations.},
  url    = {https://datafrontier.co/research/upii}
}

Comments and collaboration: research@datafrontier.co