Giving Multiple AI Agents One Shared Brain That Grows — With Git

A very concrete pain point

I run AI coding assistants across several machines at once: Claude on my MacBook, Codex on a server, plus a few Linux boxes running Gemini and Hermes. Each one is plenty smart, but they’re all amnesiac toward one another.

Things I’d nailed down with Claude on the Mac — like “the project got renamed from DualViewX to Duovid,” or “which email address is my authoritative one” — I’d have to explain all over again when I switched to Codex on the server. The more agents you have, the heavier the tax of re-explaining yourself.

What I wanted wasn’t a smarter individual agent. I wanted all of them to share the same brain — one that grows over time.

Why Git, and not a database or an MCP server

The obvious first instinct is to stand up a service: a database, a memory API, and let every agent read and write to it. But I shot that down pretty quickly:

• Every extra service is one more thing to operate, keep online, and watch crash;
• Memory is fundamentally text plus versioned evolution — which is exactly what Git is best at;
• I needed to audit where a memory came from — “which session and which commit wrote this conclusion?” Git history answers that for free.

So the core decision behind nestwork is: memory is just a pile of Markdown files in a Git repo. No plugins, no daemon. Each agent runs git pull --rebase at the start of a session, and commit + pushes whatever it learned at the end.

Layering: who’s allowed to write what

Cramming all memory into one file gets out of hand fast, so I layered it — and isolated write access strictly:

queen/        # Global behavior rules and strategy, human-maintained, read-only for agents
shared/       # Stable cross-agent facts (user identity, tech stack, collaboration preferences)
agents/<host>/<id>/   # Private memory for a single agent instance, writable only by itself
projects/<name>.md    # Project snapshot + collaboration state
workflow/     # Methodology that's portable across projects

There are only a handful of constraints, but they’re all hard rules:

• An agent can only write to its own agents/<host>/<id>/ directory;
• queen/ is always the human’s call — agents don’t touch it;
• shared/ is read-only for agents day to day, and only gets merged and updated through an explicit “distillation” process.

This isolation makes conflicts nearly impossible: every directory has exactly one writer. Even if two machines push at the same time, they’re touching different files.

The priority chain: who wins when things conflict

Layering alone isn’t enough — you also have to spell out the priority order when things conflict. nestwork uses a single one-way chain:

queen/agent-rules.md  >  queen/strategy.md  >  shared/memory.md
   >  agents/*/*/memory.md  >  projects/*.md  >  workflow/*.md

When two layers of instructions clash, you don’t do a “compromise merge” — you take the higher-priority one and drop the lower. Compromise is the mistake agents are most prone to: they try to satisfy two contradictory requirements at once and end up doing neither well. An explicit priority chain turns that decision from “improvised at runtime” into “settled at the protocol layer.”

A counterintuitive trap: high-churn files will blow up your main branch

Two weeks in, I found the repo had ballooned to 177MB — some agents had been committing high-churn history.jsonl files (rewritten every session, and compression-hostile to boot) straight into main. 411 commits later, the main branch had gotten completely out of control size-wise.

The fix was to give that kind of high-frequency artifact its own orphan branch, with the host and agent-id baked into the branch name:

• Each snapshot is a parentless commit that force-pushes over the previous one;
• The branch only ever holds a single commit, so the remote object count stays pinned at “the size of the current snapshot”;
• Because the branch name is unique and has a single writer, force-pushing is conflict-free by construction.

The lesson went straight into the protocol: high-frequency, compression-hostile artifacts go on an orphan branch by default, never into main. Only the low-frequency, human-written memory stays on the main line.

The real problem it solves

On the surface nestwork is a sync tool, but at its core it’s really a protocol: how to layer, who can write, who wins a conflict, what to remember and what to forget. Tools are replaceable; the protocol is the asset.

Now when I switch to any agent on any machine, the moment it finishes pulling it knows: who I am, what project I’m on, where I got stuck last time, and which decisions are already locked in and shouldn’t be re-litigated. The amnesia tax drops to nearly zero.

The project is open-sourced at github.com/songth1ef/nestwork. If you also find yourself re-explaining the same thing across multiple machines and multiple agents, it might be worth a try.