The Multi-Project Brain: How One Server Runs 12 Projects Without Forgetting Their Stacks
One of my servers hosts 12 projects. All of them are mine: SaaS apps, the tools behind them, a mobile app with its backend, landing pages, a blog API. None of them are client work. One AI coding agent works across all of them, and every session starts from zero, because that is how coding agents work.
What stops the agent from mixing them up is a Project Brain: one folder of plain Markdown that maps every project on the server. This post isn't a tour of the tool. It's what that brain actually contains after months on a busy server, with the numbers measured on 30 October 2026.
What is on the server
| Stack | Projects |
|---|---|
| Python · Flask | 6 |
| Flutter · Dart | 2 |
| Static HTML · Caddy | 2 |
| Node.js | 1 |
| Python standard library | 1 |
Six Flask apps on one box is exactly the setup where an agent goes wrong in quiet ways: it reaches for the right pattern from the wrong project, or "fixes" something one app does on purpose because another app does it differently.
The numbers
- 12 projects plus one cross-project section for things that apply to the whole server
- 52 topic files, one per subject (billing, auth, animations, fact-checking …)
- Topic status in the index: 40 done, 7 verified, 6 in progress
- 4 hard rules, the "never do this" lines the agent must not break
- index.md: 54 KB · index.compact: 3.8 KB. The agent reads the compact one at the start of every session. That's about 7% of the full map.
- brain-check --report: 0.22 seconds (three runs, all 0.22–0.23 s)
- 287 commits in the brain's own private git repository since 3 July 2026. After every update the brain is committed and pushed, so its history survives the server.
One word to start a session
This is how a session started today. I typed one word: "hello". Before answering, the agent read the 3.8 KB compact index and replied with where each active project had stopped: the mobile app was waiting for me to test quotes on a phone, a blog post was next in line for LinkedIn promotion, and the social-post generator still had an open issues list in progress.
No re-explaining, no "remind me what we were doing". Each active project has a one-line resume in the map: what was done, what's next, what's blocking it. The agent doesn't remember anything. It reads where we left off.
One fix, written down once, used everywhere
The value of a shared brain shows up when a lesson from one project protects another one.
A bug on two sites at once. In September I complained that the landing-page animations on two products felt weak, even after several rounds of timing tweaks. The real cause was worse: on both sites, the main headline had been invisible the whole time. A CSS percentage transform used as the "hidden" state, plus a GSAP tween on yPercent, leaves the element stuck where it started unless you reset it with gsap.set() first. The fix was one line per site. The lesson went into the brain as a general note, so it now applies to every landing page on the server, not just the two where it was found.
A fix that broke the device that worked. On the same day, a desktop-only scroll bug was fixed site-wide, and mobile, which had been fine, got worse. The rule that came out of it: a fix for one device class is gated to that device class, and both are checked afterwards. That rule lives in the brain too, so the next project doesn't have to learn it the hard way.
A backup that wasn't. Today, while testing a change to one of the Flask apps, I found that copying its SQLite database with cp misses recent changes. The database runs in WAL mode, so the newest writes sit in a separate -wal file. Any SQLite database in WAL mode has the same trap. It's now one line in the brain: back up with sqlite3 … ".backup", never cp.
Rules the agent must not break
Hard rules are short and absolute. Two of the four apply to the whole brain: topics may only use the five real statuses (done, verified, in progress, failed, superseded), never "planned" or "todo", and one validator run checks only the brain it's run in, not every brain on the machine. The other two belong to a single project and deal with what data may leave it and where it may go.
A rule like that is cheap to write and expensive to forget. The compact index always includes hard rules, so the agent sees them at the start of every session, even for projects it isn't touching today.
Decisions that stay decided
Projects keep a short decision log: what was chosen, what was rejected, and why. One real entry: when the Project Brain repository was renamed in September, GitHub started redirecting the old URL. The decision log records that a new repository must never be created under the old name, because that would silently kill the redirect behind every link in older articles.
Nothing in the code says that. Without the log, someone could "tidy up" months later and break every old link.
One brain per server
A brain describes one server. That sounds obvious until two of them disagree.
When this very article went through fact-checking, the agent on another server, the one that builds Project Brain itself, answered "this brain has 9 projects, not 11". It was right about its own server. The draft was describing this one. Both numbers were true. The draft just didn't say which brain it meant.
The lesson: a claim about a brain has to name its server. Agents on different servers keep their own brains, and when they check each other's facts, they say whose brain they read.
What it doesn't do
The brain doesn't write itself. Every note in it is there because a human or an agent decided it was worth keeping, after a piece of work was finished. It doesn't make the agent smarter. It stops the agent from starting from zero, and from quietly redoing work that's already done.
On a server with 12 projects, that's the difference between an assistant and a stranger.
- Project Brain: github.com/OoneBreath/project-brain
- FixFlex: fixflex.co.uk
Slawomir Luzny, FixFlex Ltd
Top comments (0)