Every new chat session starts from zero. You re-explain your architecture decisions, your preferences, your project history, over and over, to every tool you use — and none of those tools share what they’ve learned about you with each other. I got tired of that tax and went looking for the actual fix, which isn’t a better prompt, it’s infrastructure: a memory an AI agent can write to and query across sessions and across tools.

Companies hit the exact same wall at a larger scale. Every team running AI agents has the same silo problem — Claude’s memory doesn’t talk to ChatGPT’s, one engineer’s captured context doesn’t reach a teammate’s session, and institutional knowledge either lives in someone’s head or in a wiki nobody keeps current. The naive fixes (a bigger context window, a longer system prompt, a shared Notion page) don’t actually solve it, because none of them are queryable, ranked, or agent-writable the way a real memory needs to be.

Open Brain is a working memory system: capture a thought from inside Claude or any MCP-capable tool, and it gets embedded and stored in Postgres with pgvector; search it back later by meaning, not keyword, and get a ranked, precise result instead of a keyword-match near-miss. It exposes real tools through an MCP server — capture_thought, search_thoughts, search_all (across your personal thoughts and an ingested knowledge wiki together), list_thoughts, recent_thoughts, review_memory, forget_thoughts, merge_thoughts — so any agent, not just one app, can read and write the same memory. There’s also a human-facing web UI (FastAPI + HTMX) with actual pages: a Lists view splitting memory into Personal/Work, a Curation view for spotting near-duplicate or contradictory entries and merging or deleting them, and edit/add forms — because a chat window is a keyhole, not a way to browse or bulk-clean hundreds of stored thoughts.

I built it as 15 sequential, runnable stages rather than one finished system, because each stage exists to fix a specific, demonstrable failure of the previous one: a naive file/keyword store that misses synonyms, upgraded to pgvector semantic search with an HNSW index, upgraded again to a two-stage retrieve-then-cross-encoder-rerank pipeline for precision, then made universally accessible via MCP, then given smarter capture (an offline nearest-centroid classifier that auto-tags personal vs. work with no external API call, measured 13/14 correct on a mixed test set), then better embeddings (HyDE query expansion, swappable embedding models, a real re-embedding migration when dimensions change), then merged with an ingested “LLM wiki” of external knowledge while keeping first-person memory uncontaminated, then a deliberate human-in-the-loop judgment line (the agent proposes, a human confirms, only then does anything get written or deleted), then the browsable UI, then production hardening (Bearer-auth HTTP transport, Cloudflare Tunnel, DB never exposed to the internet). A second arc (Stages 11-15) pushes further into a self-compiling knowledge base: the LLM synthesizes markdown wiki pages from raw sources with full provenance, re-ingesting a source merges into existing pages instead of overwriting, clusters of related thoughts get compiled into a single page, and a derived knowledge graph supports bounded multi-hop traversal in retrieval.

The course wrapping all of this teaches the same arc explicitly, module by module, with the actual production/teaching split maintained throughout: every course stage runs as its own isolated container, port, and database seeded with synthetic data only, so the real personal memory instance is never touched by a demo.

The most concrete lesson was operational, not architectural: I initially reached for `claude -p` as a cheap way to get structured JSON tags out of an LLM call inside the capture pipeline, and it silently broke — the CLI runs a full Claude Code session that inherits my global CLAUDE.md and hooks, so it returns conversational prose, not clean JSON. The fix wasn’t a better prompt, it was recognizing the coupling and building the reliable path (an offline embedding-based classifier) as the default, with the LLM path demoted to an optional, clearly-caveated bonus. The deeper lesson generalizes past this one bug: don’t build a system’s default, unattended path on a component whose behavior depends on invisible global state you don’t control.

The second lesson was about restraint in the design itself — the “judgment line.” It’s tempting to let an agent freely write and delete its own memory, but that’s how a memory system silently fills with duplicates, contradictions, and noise until you stop trusting it. Making “agent surfaces, human decides, agent executes” a hard rule, enforced by a capture-confirmation gate and a dedicated curation flow rather than left as a norm, is what keeps a growing memory usable instead of degrading.

The natural extension is the knowledge-graph and consolidation work already prototyped in Stages 14-15: bounded multi-hop traversal over explicit and inferred links between memory entries, and a standing “review” pass that surfaces disconnected or duplicate knowledge for a human to prune, so the memory improves with age instead of just growing.

At team or org scale this stops being a personal-productivity trick and becomes an institutional-memory problem worth solving deliberately: a shared, agent-writable memory per team, with the same judgment-line discipline (nothing gets written or merged into the shared store without a human sign-off) and the same two-tier separation between first-person notes and synthesized/ingested knowledge. That’s exactly the gap between a Slack history nobody can query and a wiki nobody keeps current — a queryable, curated memory an onboarding engineer or an AI agent could actually search on day one, rather than either re-deriving the answer from scratch or asking a person who happens to remember. The production stage here (auth, no exposed DB, HTTP transport) is already aimed at that multi-user, remote-access reality, not just a single laptop.