Personal AI

What It Is

Personal AI is the configuration of an AI assistant to stay with a single operator across every tool and surface they touch, compounding what it knows about their work over weeks and months instead of resetting at every chat. The phrase belongs to Andrej Karpathy, who has argued since 2024 that the cloud-chatbot model treats each user as anonymous on purpose, which is the opposite of what most knowledge workers actually need from an assistant. A personal AI keeps your inbox, your calendar, your project notes, and your tool history in one queryable substrate. It draws on that substrate without being prompted. It does not forget you when you close the tab.

The category is distinct from a chat assistant with a bolted-on memory feature. Cloud assistants like ChatGPT and Claude store memory on someone else’s server, cap what they retain, and reset it when the provider changes its mind. A personal AI inverts the architecture: memory is the first-class object, the assistant is a thin surface on top, and the data lives where the operator does. OpenHuman, which surfaced this week, is the first open-source attempt to ship that inversion as a desktop binary.

How It Actually Works

A personal-AI system has three moving parts. First, a connector layer that reads from the operator’s email, chats, calendar, docs, and tool history through OAuth or local file access. Second, a memory substrate, usually a local SQLite or vector store, that gets refreshed on a schedule, every twenty minutes for OpenHuman, every twenty-four hours for slower variants. Third, an inference layer that can be local (Ollama running a 7B model on your laptop) or remote (a cloud API call with the operator’s data attached as context). The substrate is the moat, not the model. Swap the model and the memory survives.

The Memory Tree pattern OpenHuman uses is one variant. The connector layer extracts entities, the substrate builds a graph of who said what when, and the inference layer queries the graph instead of stuffing raw transcripts into context. That keeps prompt costs bounded and the data structured enough for non-chat surfaces like search, dashboards, and exports to use it too.

Why It Matters Right Now

The chat tab was always the wrong unit for an assistant that ought to remember you. Cloud labs build chat tabs because they scale and bill cleanly. Operators want continuity. Those two pressures have been pulling against each other since GPT-4 shipped. Three things changed in the last year. Local models got good enough that a 7B parameter model on consumer hardware does most of the work a 70B model did in 2024. Connector ecosystems matured: MCP, OpenAI’s Apps SDK, and Anthropic’s Tool Use API all standardized how an assistant reaches into the operator’s stack. Storage got cheap enough that running a 50-gigabyte personal index on a laptop is unremarkable.

OpenHuman ships at the intersection. Karpathy was right that the category was coming. The week it landed in a working binary is the week the chat-tab era starts to look like a temporary stopover.

How TWO Uses It

The TWO editorial bias is that an operator should own the substrate of her work, not rent it. Cloud chatbots are useful, and Scott uses them daily, but they cannot be the place his project history lives. The risk is not data exfiltration. The risk is silent drift: the cloud provider quietly changes what their model retains, retires a memory feature, or migrates a backend, and a year of accumulated context vanishes without a migration path. A local personal AI moves that risk surface inside the laptop, where the operator can back it up, version it, and migrate it on her own schedule.

The operator-decision moment lands when you are about to pour a year of project notes into a cloud assistant’s “Projects” feature for convenience. Stop. Ask whether the same content in a local memory substrate, queried by the same cloud model on demand, would give you the same upside without the silent-drift risk. Most weeks the answer is yes, and the friction is real but lower than the rebuild cost when the cloud provider changes the rules. The pattern crosses over from personal AI into project-memory generally: the file is yours, the model is a tool.

A Concrete Operator Scenario

You are running a one-person consultancy. Every client engagement generates email, Slack, Notion docs, three or four working drafts, a Loom or two, and a billing record in QuickBooks. You want an assistant that can answer “what did I commit to client X on the third call, and have I delivered it” without you stitching the answer together by hand.

The cloud-chatbot version: paste relevant transcripts into Claude, ask the question, accept that the answer is bounded by what you remembered to paste. The personal-AI version: the connector layer indexed all four sources at install, the substrate already has the client X timeline, and any model you point at the substrate can answer the question by querying it. Same model, different architecture, opposite ceiling on what the assistant can actually know.

What to Watch Next

The signal that personal AI is real is whether the substrate becomes portable across assistants. Today every personal-AI tool ships its own memory format. In six months the question is whether OpenHuman, the rumored Anthropic local memory feature, and Karpathy’s reference implementation converge on a shared substrate spec, the way MCP became the shared connector spec. If that happens, the operator’s memory becomes a file she owns, and the model becomes interchangeable. If it does not, personal AI stays a per-vendor lock-in, which is the chat-tab problem with extra steps.