Every new tool starts with amnesia
Cursor does not know what you decided in Telegram. A messaging bot does not know what you merged in git an hour ago. If each channel keeps its own scratchpad, you re-explain context forever or paste summaries by hand.
My assistant stack already had a notes vault as SSOT. What was missing was a thin, queryable memory tier that tools could write to in seconds without turning every thought into a permanent note. That tier is Engram, backed by local SQLite and exposed through MCP to editors and agents.
This post is only about memory boundaries. Not routing, not model tiers (see Cutting LLM costs), not the PublicBrain publish pipeline (see building PublicBrain).
Three layers, three contracts
Rule of thumb: if a future you should read it in prose, it belongs in the vault. If a next session in another tool needs "what we decided last Tuesday", Engram is enough until it earns promotion to the vault. If you need "what is running on this host right now", read the kernel snapshot, not a chat log.
Engram complements the vault. It does not replace editorial judgment.
Cycle context vs cross-session memory
Inside a thirty-minute governance loop, eight scripts run in order. They share a cycle context file: created at start, each step registers outputs, later steps prioritize what just happened, archived when the loop ends.
That file is intra-cycle state. It dies when the cycle ends.
Engram is cross-session and cross-tool. Cursor via MCP, Telegram agents, and shell hooks can append observations tagged by project. When I open the repo tomorrow, search returns the same thread whether the work happened in the IDE or on the phone.
Confusing the two leads to either bloated Engram (dumping cycle logs) or blind scripts (re-reading the whole vault every half hour).
Cohesion without copy-paste
Two mechanisms keep tools aligned:
1. Universal activity emit: one entry point for "something worth remembering happened" (command finished, decision made, file touched in a governed way). Emitters stay dumb; Engram stores structured observations.
2. Editor scan: a deterministic pass over local editor history picks up what MCP might miss, still routed into the same project namespace.
The goal matches PublicBrain on this site: one public surface, one private brain, no duplicated truth. Engram is the glue between interactive tools; the vault remains the glue between human narrative and published T4 content.
When Engram is down
Local-first means memory cannot depend on a daemon being up. Writes go through a safe save path: try Engram, buffer to the filesystem if unavailable, drain and reconcile on recovery. Same philosophy as file-based task queues in the broader stack: degrade, do not drop.
I treat stuck buffers as operational debt. If drain fails for days, search lies. That is a lesson, not a feature to hide.
What I deliberately do not store in Engram
- Secrets, tokens, credentials (deny by policy).
- Raw finance or legal documents (domain notes stay in governed vault paths).
- Marketing copy or publishable drafts (those flow vault / PublicBrain / site).
Search is powerful; garbage in means confident wrong recall out.
Optional future: self-hosted sync
Today Engram is local SQLite on the machines I control. A self-hosted sync layer (for example PostgreSQL behind Docker on a VPS) is on the roadmap for multi-machine continuity, not for replacing the vault. Local stays authoritative; cloud would be replica and backup, with the same buffer semantics on disconnect.
No timeline promise here. The architecture slot exists so I do not bolt sync on sideways later.
Takeaway
If you run more than one agent surface, decide explicitly:
1. Vault = durable story you would sign your name to.
2. Engram = fast recall for agents and future you across tools.
3. Cycle context = handoff inside one automated loop.
4. Kernel snapshot = machine truth, generated, short-lived.
Without that map, every new integration becomes another silo. With it, the assistant feels like one system even when the UI changes.
Related: Secondbrain architecture · Pattern selection decision tree · PublicBrain work case