Open a repo, start Claude Code, and watch it spend the first ten minutes rediscovering things you both knew yesterday. What is this project? How is it structured? What were we in the middle of? The agent is brilliant for one session and amnesiac between them — every session starts from zero, and everything it learned evaporates when the window closes.
The usual patch is a CLAUDE.md in the repo. It helps, but it has a shape problem: it lives in one repo. It can hold architecture notes, but not "where we left off last night," not "the decision we made two weeks ago about auth," and definitely not "what the backend team shipped while you were working on the frontend." A repo file is memory for a codebase. What agents are missing is memory for your work.
GitHub knows what happened. Nothing knows why.
Git history is a perfect record of what changed. It says nothing about why, what was rejected along the way, what's deliberately unfinished, or what comes next. That context lives in your head, and every session you either retype it or the agent guesses.
LLMBrain is one hosted place for exactly that context, across every project you have. A remote MCP server your agents connect to — Claude Code, Codex, anything that speaks MCP. Each project keeps a small set of canonical docs the agent itself maintains: architecture, data_model, product, and status — where work left off, updated before each session ends. Around them: milestones and issues as the roadmap, an append-only decisions log, comments as session-handoff notes.
GitHub knows what happened. LLMBrain knows why, and what's next.
Open a fresh clone on a new machine and the agent already knows the portfolio. Your frontend agent has met your backend, because both repos point at the same project.
Built for the agent first
Here's the design decision everything else follows from: the primary user is an LLM inside a coding tool. Humans get a web dashboard, but it's a thin view over the same API the agents use — not the other way around.
That flips some habits. Tool descriptions get written like landing-page copy, because for the primary user they are the entire UX — an agent decides whether to call start_session based on nothing but the words in its description. Error messages carry the fix inside them, because the reader can act on instructions immediately. And token economy is a feature, not an optimization: responses are shaped for a context window, not a screen. Orienting in a project costs about 400 tokens, not a directory crawl.
Memory that doesn't rot
A brain you can quietly rewrite isn't one you can trust, so the durable parts are append-only. Decisions are immutable records — you can supersede one, never edit it. Session-handoff comments have no delete path; a note records what someone believed at a moment, and that's the value. The status doc is the one deliberately rewritten surface, because "where we are now" is the one question whose old answers stop mattering.
And because docs written once go stale, every project reports docs_health — the brain tells the agent which docs are missing or stale, so maintenance is prompted rather than remembered.
Where it's at
LLMBrain is in beta, self-hosted in the most literal sense: the brain tracking its own development is served by the code being developed. This blog is the build log — the posts that follow dig into the engineering: one-call session bootstrap, cross-project search, skills that travel with you across machines.
Setup is one command — it wires the MCP server and hooks into Claude Code or Codex. And if you'd rather have your agent read the pitch itself: llmbrain.dev/agents.md is written for it.