// signals
Every agent session starts from zero. It re-reads the same repos, re-derives the same decisions, re-learns which server runs what; then the window closes and all of it evaporates. The next session pays the tax again. I got tired of that, so I built a place for the context to live and made every agent check it first.
The problem: context dies between sessions
An LLM agent has no memory past its context window. Close the session and every decision, every piece of infrastructure knowledge, every “I already tried that and it didn’t work” is gone. The next run derives it from scratch. Or worse, it doesn’t, and repeats a mistake I’d already solved. Across every repo and three machines, that’s not a small tax. It’s the same investigation, paid for over and over, forever.
The fix isn’t a bigger context window. It’s memory that outlives the session.
What it is
GBrain is a self-hosted memory server: an MCP endpoint every agent I run queries *before* it answers, and writes back to *after* it works. It’s live on my Darktower home lab at gbrain.randomsynergy.xyz/mcp, key-gated, running engine v0.42.53.0.
Retrieval is hybrid: vector plus keyword search, with multi-query expansion and a reranker on top, tuned with recency and salience boosts and a relational graph-walk recall. Pages are versioned, so I can see what a decision looked like three revisions ago. Links form a knowledge graph. A timeline tracks what happened when. And a set of code-intelligence tools (code_def, code_callers, code_callees, code_flow) lets an agent ask who calls this function across the whole codebase, not just the file in front of it. 84 tools in all.
The receipts
As of 10 July, the brain holds 2,386 pages, 17,932 chunks with 100% embed coverage, 1,683 links, 537 tags, and 1,072 timeline entries. Six sources feed it: every RandomSynergy17 repo’s README, CLAUDE, and CHANGELOG; claude-mem observations from three machines; 232 transcripts from 118 Claude Code sessions; plus three more.
Capture is automated so I never have to remember to remember. A nightly ingest cron stages and imports every source, and a 3 AM “dream cycle” extracts links and timeline entries from what came in. The stack underneath is deliberate: Docker Compose on Darktower, PostgreSQL 16 with pgvector for 1024-dimension vectors, BGE-M3 embeddings running at ~40ms on the GPU, and a bge-reranker-v2-m3 on top. Nothing exotic. Just parts I understand, wired to stay up.
I own the seam
The engine is upstream: Garry Tan’s open gbrain project. My build is the deployment and integration layer: the Docker stack, the LiteLLM routing, the six-source ingest pipeline, the URL-key auth, and the operator patches that keep it running. Two upstream schema bugs I diagnosed and patched in place; one of them I reported back upstream as garrytan/gbrain#2038.
Owning that seam matters. When the retrieval quality dropped after an embedding-model mismatch, I didn’t file a ticket and wait; I re-embedded all 6,230 chunks and watched the brain’s health score climb from 33 to 74 out of 100. That’s the difference between using a tool and running one.
The takeaway: memory is infrastructure, not a feature
Every agent I run is wired brain-first. Across blackair, bigmac, and Darktower, the rule sits in the global config: check the brain before you reach for a web search. That’s not a convenience bolted onto the workflow after the fact; it’s the substrate the workflow runs on. The agents are stateless by nature; the brain is where the state goes to live.
This is the method again, applied to a new layer. Build the capability once, in a place you control, and every agent that comes after inherits it, already loaded with what the last one learned. The technology that reads the memory will keep changing. The memory won’t.