Totem: memory becomes a node

Part II — The Node and the Join · Chapter 4 of 9

If the assistant's home is the user's machine, then memory can't be a table in someone else's database. It has to be a thing — with a location, an identity, and an owner. That thing became Totem: a local vector and knowledge-graph memory node, a separate program with its own lifecycle, and the second member of what would become a three-process stack.

A node, not a service

Totem persists a node as a small set of store files on the user's own disk, their filenames embedding the node's UUID. That's the whole database: vectors, knowledge graph, registry, sitting in the user's own folders like any other files they own.

The design commitment hiding in that filename scheme is stronger than it looks: the node UUID is the database identity. There is no account row that points at the data; the identifier in the filename is the identity, full stop. The client code treats minting a fresh identity while a persisted one exists as the cardinal sin — doing so would silently orphan the entire database. Identity is not managed about the memory; it is part of the memory.

An undated note from this period — written about competitors, but really a specification — says why this mattered so much to me:

Undated field note. "None of it is yours. Delete your account, your personalization disappears. Switch providers, you start from zero. Seer's behavioral model is exportable — a .seer file that the user owns, carries, and controls. The personalization is the file. The platform is just the runtime."

Totem is that sentence, built. Memory as files the user can copy, back up, move to a new machine, or delete — with the servers demoted to runtimes for data the person owns.

And identity threads through retrieval, not just storage: when the full stack is signed in, the authenticated subject becomes the owner ID that every memory group and document address is hashed against. As the system's own documentation puts it — sign in as someone else and you address a different memory entirely, not a filtered view of the same one. Memory isn't scoped by a WHERE clause; it's addressed by owner, cryptographically, at the bottom of the scheme.

The topology

With Totem, the stack took its lasting three-process shape:

Seer serves realtime chat, speech, and the fleet view over HTTP, and runs a gRPC mothership channel. Totem serves gRPC for direct query, library, and graph calls, plus a gated administrative surface — and here's the structural surprise: Totem dials into Seer's mothership, and memory updates ride that session rather than a direct connection. The reasoning lane and the memory node are peers with distinct duties, joined by an explicit wire contract — a shared protocol definition, called Conduit, that all three programs build against, so the contract can't drift per-process.

Bonnie — arriving properly in the next chapter — supervises both as child processes: starts the mothership first, then Totem, which dials in. Or adopts them: a healthy server that Bonnie didn't spawn is respected as external and never touched. Three programs, three lifecycles, one contract.

The one-line division of labor that the documentation opens with, and that this book will keep returning to:

Bonnie acts, Seer reasons, Totem remembers connections.

Graphs with an ontology

"Remembers connections" is the operative word. Alongside vectors, Totem runs server-side entity and relationship extraction over what's deposited — building a knowledge graph under a configurable ontology (people, organizations, places, events, works, concepts — and Bonnie later extends the kind list with its own: files, projects, apps, abilities, skills). Memory that knows that two things are related and how answers questions vectors alone can't.

A graph you keep for years also needs maintenance — renaming an entity, merging duplicates, deleting a relationship, re-running extraction — and those operations are irreversible surgery on the user's memory. So the administrative surface is deliberately narrow, and every caller of it stands behind an explicit confirmation. The principle that chapter 8 will give a formal name: where reversibility ends, consent begins.

Three programs, one sentence

What Totem contributed to the eventual paradigm is almost embarrassingly concrete. Against an industry treating memory as either a prompt-injected text ledger or a hosted vector store — both owned by the provider, both evaporating on account deletion — this stack's answer is: memory is a node. It has files you can point at. A UUID that is the identity. Ports you can probe. An owner the addressing scheme is hashed against. A graph with an ontology you can amend.

Memory you can point at — a file, a UUID, a port.

What remained was the hard part: a reasoning lane and a memory node are still headless. Nothing yet lived where the person lives — in front of the screen, inside the apps, in the middle of the workday. That program needed a name.