Knowledge Graph · Field notes · Part 1 of 3
Knowledge Graph, Part 1: The canvas and the stack
Memory should be a place, not a thread. The whole stack has to fit in 16 GB and still work with the network unplugged.
Knowledge Graph started as a bet that memory should be a place, not a thread. Photos, notes, conversations on a canvas. Time as depth. You fly to a month instead of scrolling a log. The originals stay on hardware you own.
The first wave of agents could do things on your computer. OpenClaw was the leap. Utility moved. Memory did not. The agent still forgot Tuesday. That is the personal problem. Utility and personal look like the same product. They are not. I wrote that split in Utility vs Personal AI. Bolt on API keys and the "AI on your machine" story stops being true. That one is Who has your data?.
Knowledge Graph is the bet that memory is the hard part, and that it is the one worth getting right first.
Why a canvas
Lists and chat windows flatten life into a sequence. A spatial surface lets the same day hold photos, notes, and later conversations without forcing them into one scroll. Zoom out for months. Zoom in for an afternoon. The camera is the navigation. Not a sidebar of folders.
Local by default — on 16GB shared
Models run on the laptop's own chip. No cloud required. Speech, vision, the memory index, the database, and the canvas share one machine. Cloud is optional. It is not the path of least resistance.
The test is offline. Airplane mode. No Wi-Fi. No fallback API. If the assistant still answers from weights on disk and data on disk, it is local in fact, not a thin client dressed up as "AI on your machine." Anything that phones home when the cable is unplugged has already failed.
Why 16GB, specifically? Because that is the machine this is built on — not a hypothetical target spec. The dev box is a 14‑inch MacBook Pro with an Apple M2 Pro: a 10‑core CPU (6 performance, 4 efficiency), a 16‑core GPU, and 16GB of unified memory — meaning the processor and the graphics share one pool of memory, there is no separate graphics memory to spill into. That is the entire budget, and the operating system, the browser, the database, and the live canvas are already in it when the first model loads.
This is the part of the local‑AI story that most write‑ups quietly skip. The demos that get shared are almost always run on rented A100s or a workstation that cost more than a used car. Large orgs have the money to blow on GPUs — a frontier‑class rig is a line item, not a sacrifice. Most people do not. The Steam Hardware Survey is one of the few public windows into the machines real users actually own, and the RAM split tells the story plainly:
| System RAM | All platforms | macOS only |
|---|---|---|
| 8 GB | ~8% (and growing — RAM prices are forcing downgrades) | ~2% |
| 16 GB | ~41% — the single most common configuration | ~43.6% — the plurality on Mac |
| 32 GB | ~37% (slipping as kits stay expensive) | ~32% |
| 64 GB+ | under 5% | under 3% |
In other words, for nearly half the people reading this, 16GB is not a floor they are trying to climb above — it is the ceiling they are living under. If a local stack only runs on a $4,000 box most of them will never buy, then “local AI” is a hobby for the few, not a tool for the many.
That pool is the hard constraint — not “local in theory” but local in fact. The main model, the speech recognizer, the vision model, and the live canvas all compete for whatever is left once the operating system, the browser, and the database have taken theirs, which is why the stack leans on compressed models, reclaims memory the moment a tool is idle, and is careful about what loads first. Those are product decisions in this stack, not optimization trivia.
The pipeline
Ingest path
The canvas is the product. Bonsai is the engine on this laptop now. Open WebUI is a temporary conversation surface. Next is swapping that window for this canvas.
Part 2 is what happened when phones, microphones, and more than one client hit that 16 GB budget at once.