What GBrain Teaches Us About Agent Memory

Garry Tan recently open-sourced GBrain, the agent memory system behind his OpenClaw and Hermes setup. The interesting part is not that it uses embeddings or exposes an MCP server. Those are implementation details.

The useful lesson is structural: an agent memory system needs readable canonical truth, indexed retrieval, explicit data ownership, resolver-routed context, and a disciplined writeback loop.

That is close to what we are building with SOS, Mirror, QNFT identity, and tenant-scoped agent fleets. GBrain gives us a useful external reference point for the same problem: how do agents stop waking up confused without turning every prompt into a giant pile of stale context?

#Mumega’s Prior Art

We are not starting from a blank page. Mumega already has public work that points at the same substrate shape from different directions.

A Map of the SOS Brain describes SOS as an operating loop over durable primitives: bus, memory, task ownership, lifecycle, economy, and bounded motor actions. Durable Substrates for Long-Running Multi-Agent Work formalizes the same pattern as a research paper: long-running agents fail through lost handoffs, duplicate work, dead-agent routing, stale directive revival, unsupported action drift, and unbounded spend unless the substrate preserves state below the model layer.

AI Agent Memory and Context Engineering cover the memory side: graph-enhanced selective retrieval beats full-context injection on accuracy, latency, and token cost; contradiction metabolism needs to run before the agent is invoked, not during the live task. Memory Provenance adds the missing multi-tenant property: cross-tenant retrieval is only acceptable if every engram keeps visibility class, source tenant, source agent, and QNFT-linked provenance.

QNFT and The Fractal Organism cover the identity side: every tenant and agent needs a cryptographic identity that carries scope and cause, so an action can be traced to who acted, under which authorization, inside which tenant.

GBrain is useful because it validates the same direction from outside Mumega. Its cleanest contribution is naming the routing split: database owner boundary versus content namespace.

#What GBrain Is Really Saying

The repo describes GBrain as a brain for forgetful agents: a human-readable knowledge base, a retrieval layer, a graph of entity links, MCP tools, and agent-facing skills. It also publishes an explicit agent read order in AGENTS.md: start from the operating protocol, then architecture references, then routing conventions, then the skill resolver.

That read order matters. It is a boot protocol, not a pile of notes.

For Mumega, this maps directly onto a problem we keep seeing: agents wake up, do not know their tenant, project, identity, current sprint, memory boundary, or bus address, then spend context reading files to reconstruct what the substrate already knows.

The fix is not “better memory” in the abstract. The fix is a product contract:

• Who am I?
• Which tenant and project am I inside?
• Which QNFT or agent role authorizes me?
• Which memory workspace can I read and write?
• Which sprint capsule is current?
• Which tools are allowed in this context?
• Where do durable facts go?

That is the shape of boot_context.

#The Comparison

GBrain and SOS are solving overlapping but not identical problems. GBrain is optimized for a personal or team brain that agents can query and update. SOS is an operating substrate for many agents, tenants, projects, bounties, memories, and identities.

#Brain Versus Source

The strongest architectural primitive in GBrain is the split between brain and source.

In their model:

• Brain means the database and ownership boundary.
• Source means a named content repository inside that database.

For Mumega, the equivalent should be:

• Brain: tenant, customer, internal substrate, or other owner boundary.
• Source: repo, sprint, agent mirror, meeting stream, product area, local computer, or project workspace.

That distinction matters because data leaks usually start as routing ambiguity. If an agent writes a tenant decision into the internal brain, the record exists but belongs to the wrong owner. If a local Mac keeps its own truth forever, the system forks. If cross-agent search silently merges everything, no one can audit why an answer appeared.

The rule should be simple: the owner determines the brain; the origin determines the source.

#The Boot Context Contract

Agents should not need to rediscover their world on every start. A new model loading into SOS should receive a compact context packet generated by the microkernel.

graph TD
A[Agent session starts] —> B[SOS resolves identity]
B —> C[QNFT role + tenant + project]
C —> D[Memory workspace + source]
D —> E[Sprint capsule + current priorities]
E —> F[Allowed tools + trust boundary]
F —> G[Agent works without crawling the filesystem]
G —> H[Receipts + memories + events]
H —> I[Dreamer consolidates into project truth]
I —> E

This is not a big prompt. It is a resolver output. The packet should point to deeper documents only when needed.

The difference is operational. A confused agent burns context. A resolved agent starts inside the right identity, workspace, and sprint.

#Local Computers As Mounted Sources

The local Mac question fits the same model.

A new computer should not need to run the whole SOS substrate to participate. It should create a local body: files, receipts, cache, project notes, and agent state. But it should not become a second source of canonical truth.

The efficient mycelium pattern is:

1. Local machine mounts into a tenant or project brain.
2. Local work writes receipts, notes, and artifacts into a local source.
3. Sync submits those receipts back to SOS with provenance.
4. Mirror indexes the accepted memories under the correct workspace.
5. Dreamer consolidates raw work into project truth.
6. The next boot_context carries the distilled truth back to every agent.

Local files are the hyphae. SOS and Mirror are the shared substrate.

#What We Should Steal

We should not copy GBrain wholesale. SOS already has primitives GBrain does not emphasize as much: QNFT identity, tenant fleets, bounties, audit gates, bus delivery, and economic routing.

The parts worth adopting are narrower:

• A formal brain-routing contract: every memory operation resolves tenant, project, agent, QNFT, workspace, and source before it runs.
• A boot context endpoint: one compact packet for identity, sprint, memory boundary, tools, and current work.
• A retrieval eval set: captured real questions replayed after Mirror changes to catch regressions.
• A source-mounted local body: Macs and other computers can work locally, then reconcile into canonical memory.
• A manual-work burn-down: every repeated Hadi action becomes a skill, microkernel operation, or scheduled job.
• Cited cross-brain synthesis: agents can federate across memories, but they must cite where each fact came from.

#The Risk

The trap is building a memory swamp.

More files, more embeddings, more agents, and more background jobs do not automatically create intelligence. They can create a larger confusion surface. The system only compounds if durable facts are owned, sourced, retrieved, tested, and consolidated.

That is the standard we should hold SOS to.

#The Mumega Version

The Mumega version of this pattern is not “GBrain but with tenants.”

It is:

QNFT identity
  -> boot_context resolver
  -> tenant/project brain boundary
  -> source-mounted local and agent work
  -> Mirror retrieval with provenance
  -> bus events and receipts
  -> Dreamer consolidation
  -> sprint capsule
  -> next boot_context

That loop is the information flow layer.

If it works, agents do not wake up confused. Customers do not have to manually explain their world every time. Local machines can join the organism without becoming isolated islands. And the system gets better because repeated work turns into durable procedure instead of another one-off chat.

#Sources

#Mumega

• A Map of the SOS Brain
• The Fractal Organism: Per-Tenant Harness with Shared Substrate
• AI Agent Memory
• Context Engineering
• Mumega 200.003: QNFT Cryptographic Identity
• Mumega 200.004: Durable Substrates for Long-Running Multi-Agent Work
• Mumega 200.104: Memory Provenance

#External

• GBrain repository
• GBrain AGENTS.md
• Brains and Sources
• Thin Harness, Fat Skills
• Brain Routing Convention