Two Brains, One Operator

Public note: this paper describes a real production system but uses generalized names and omits live values, page identifiers, customer identities, hostnames, and credentials. Finding classes and counts are real; the specifics are deliberately not.

Both fleets need the same mechanical thing - a knowledge base behind MCP that agents can search, read, and write - but they need it to behave in opposite ways. That tension is what this paper is about.

Three consequences follow.

The split is the architecture: two GBrain servers, one per trust domain, each reached over MCP with its own credential. Sections 3 and 5 describe each half.

One engine - stock upstream GBrain 0.51 with its managed writer - serves three sources. One shared company source, ~750 pages: the shared documentation folders (decisions, standards, domain, platform, runbooks, incidents, sources) plus a products/<product>/ folder per registered product and an agents/<agent>/ folder per writer. A frozen archive source holds ~1,160 historical imports - searchable, read-only, every hit labelled historical. A restricted internal source sits empty with no grants, created so restricted material has a home the agents cannot see.

Every writer is a fenced client. Each agent's credential - an OAuth client I approve once in the admin page - carries a server-enforced list of write prefixes: its own agents/<name>/ folder plus products/. A write outside the fence returns permission-denied from the server; I verified that live, it is not policy prose. Reads span the shared source and the archive.

The write protocol is revision-safe and asynchronous. The agent reads the page, rewrites it, and calls put_page with the expected revision and a request id; the caller polls a receipt until the write is committed and the Markdown file is on disk. A lost response replays the same request id; a revision conflict is re-read and retried, never forced.

Git-backed Markdown stays the authority; the database and the vector index are projections. Nightly native maintenance - backlinks, embeddings, orphan scan, a weekly exceptions digest - runs inside the engine. There is no custom verifier and no review queue.

My role shrank to the edges: approve a new client, set its fence, handle destructive operations, and decide anything touching internal or the topology. Everything else is agents writing.

One insight from the old design survived. Before the restructure, the brain reported ~1,900 unverified pages - which read as 1,900 things waiting for a human. Composition analysis showed most were imported reference material that never needed a verdict. That is why they now live in a frozen archive rather than a review queue.

What the skeptic found, in finding classes:

I responded to the leaks directly: redacted the live pages, rewrote git history, and purged the database version store - it held the same secrets in page snapshots that any read-scoped agent could have fetched. Scrubbing then moved upstream to intake, so secrets are redacted before they reach a commit.

The incident was not the sweep's real output. I learnt three lessons that changed the architecture:

The idea that carries the weight: skills, harness conventions, and device knowledge live in the brain, not in each harness's private configuration. The brain publishes its own skills over MCP; a harness connects, discovers what I know how to do, and inherits my working patterns - routing rules, memory verbs, ingestion discipline - with no per-harness setup. A new device or a new harness is connect-and-go.

The clearest example of the adapter pattern is how memory itself is routed. The brain serves its own memory verbs as skills - /remember, /recall, /forget - and any harness that connects inherits them. /remember is an ingestion router: it takes a write, classifies ownership, and routes it to the correct store - personal notes to the personal brain, company knowledge to the company brain. An explicit destination wins; when ownership is genuinely ambiguous the skill asks rather than guesses, and it never dual-writes. /recall is the retrieval mirror: it selects one brain and searches only that one. The routing policy - what counts as personal, what counts as company, what to do when unsure - lives in the brain, not in any harness.

This is what makes the split operable. Two brains are only safe if every writer routes correctly, and the router is a skill the brain serves - not a convention each harness must reimplement. A new knowledge source is a new row in the routing table, not a new integration in every harness.

That is why my personal brain can stay permissive where the company brain must be strict. Single owner, no third-party subjects, git-backed and reversible: the cost of a bad write is a bad note, and the remedy is a revert. The same properties would be negligence on the company side.

The pairing is the point. Planning work is low-volume and high-consequence - a wrong promotion policy is a design flaw that lives for years - so it gets the strongest available reasoning. Verification is high-volume and mechanically bounded - each page either passes the checks or it does not - so it gets cheap, fast, local throughput on hardware I own. And the build itself used several harnesses, which is exactly what the Section 5 adapter layer exists for.

The release posture follows directly. Reading the company brain is safe today - archive hits are labelled historical. Writing is open to every fenced agent. The remaining work is off-host backup of the Git vault and moving the nightly synthesis onto the engine's native provider path. If you run agents against shared memory, tell me where this breaks for you.

Until 21 September 2026 the company brain ran a different design: agents could only write to an unreviewed captures tier, an intake scrub redacted secrets, a nightly local-model verifier wrote recommend-only digests, and only a human PR moved a page into a reviewed tier. It was correct on paper, and it is what the Section 4 audit tested.

It did not work for me. The reviewed tier stalled at 19 pages against ~1,900 captures; I was the bottleneck. Once intake scrubbing and the audit had cleaned the corpus, the risk left was where an agent could write, not whether I had signed - and the engine already shipped that control natively. I also did not want to maintain a custom pipeline on top of an engine whose authors had solved the problem differently.

On 21-22 September I moved it to stock GBrain 0.51. The pipeline was retired - nothing deleted; the old captures source is soft-archived and restorable - and replaced by one shared source plus the frozen archive plus internal, per-agent fences, OAuth clients with every legacy token revoked, and native nightly maintenance. Devin did the cutover; the details are in Section 6.

What I gave up: the guarantee that a human had read every page before an agent could cite it. What I kept: Git history as the audit trail, labelled retrieval, credential isolation, and the physical split of Section 2. Whether fences alone are enough is the question the next revision should answer.