Your agents don't need better models. They need a shared brain.

The multi-agent context problem

Two agents, fine. Three agents, awkward. Five agents, a mess.

The multi-agent context problem is not a model problem. Every agent in the team wakes up with no idea what the rest of the team just did. The same research happens three times. Decisions made on Monday get re-litigated on Wednesday. Token budgets burn on context the team already has.

The 2026 answer is usually some flavor of "buy our memory infrastructure." Vector DB. Graph DB. Multi-scope tagging. All useful, and all incomplete.

A shared memory layer for agents only earns its keep when humans on the team can also read it, edit it, and version-control it. That is what we kept relearning while running our own internal AI team, and it is why we ended up adopting GBrain, Garry Tan's open-source memory layer.

Here is what GBrain is, how we use it, and why we recommend it to anyone running a mixed human + agent team.

What GBrain actually is

GBrain is an open-source, MIT-licensed memory system built by Garry Tan, President and CEO of Y Combinator, to run his own AI agents. The public repo describes it as the production brain behind his OpenClaw and Hermes deployments: a large markdown-backed brain with pages for people, companies, meetings, tweets, calls, and original ideas.

The shape:

• The brain is a regular git repo of markdown files. Your knowledge lives in plain text: diffable, branchable, browseable in any editor. Open people/jane-doe.md to see what your agents currently believe about Jane.
• A Postgres + pgvector layer indexes it for retrieval. PGLite works for a local brain; Postgres or Supabase can back shared and hosted deployments.
• A self-wiring knowledge graph extracts typed entity links without LLM calls. Mentioning a person in a markdown file can wire the graph automatically, with typed links such as works_at, invested_in, founded, and advises.
• Hybrid search happens at retrieval time. Vector search, BM25 keyword search, reciprocal-rank fusion, graph traversal, and ranking rules compose into the answer.
• Agents can read and write through CLI and MCP surfaces. Claude Code, Cursor, Windsurf, and other MCP-aware clients can use the brain through a standard tool surface.

GBrain's own README reports BrainBench P@5 of 49.1% with the graph layer on, a +31.4 point lift over its graph-disabled variant. The exact benchmark matters less than the design choice underneath it: the source of truth is a git repo a human can read, not an opaque vector database the team has to query through an "agent memory inspector."

Yes, GBrain uses vectors. The vectors are an index on top of the markdown, not the thing your team has to trust blind.

How we use GBrain

We have been running GBrain as the shared memory layer for our own internal AI team. The brain has typed folders, each holding markdown files:

• people/ — every stakeholder we deal with
• companies/ — orgs, prospects, partners
• concepts/ — internal frameworks, terms, and mental models
• ideas/ — open hypotheses we are sitting on
• media/ — assets and references
• newsletter/ — newsletter-specific context
• projects/ — active work
• operations/ — how we work; internal SOPs

The flow inside our setup:

1. A research agent ingests new findings into the brain.
2. Every other agent reads the brain as first-step context before doing any task.
3. The orchestrator captures durable decisions back into the brain after each task closes.
4. Tools such as X, web, and news pull fresh information at task time, not at memory-write time.
5. The orchestrator synthesizes a result and hands it back to us.

GBrain is not an agent. It is the shared memory layer that lets a company of agents act like a team, with cross-reference and a centralized brain.

Eight folders. Three of them carry most of the value.

people/ is the most useful folder we run. Before any sales pitch, our orchestrator pulls the people/ entry for the stakeholder we are writing to: what they care about, prior conversations, the language they use to describe their own problem, what they pushed back on last time. The pitch goes out tailored to that specific person, not generic copy with their name swapped in. The difference shows up in reply rates.

This is the part vector-DB-only stacks cannot give your team. Semantic recall returns "memories similar to this query." It does not give a human on your team a 30-second answer to "what do we currently believe about Jane?" A file named people/jane-doe.md does. You can open it, correct it inline, and git diff to see what the agents added since last week.

companies/ does the same thing at the org level. Before outbound to a prospect, the agents read the company entry: where the company is, where it is going, what is loaded into its quarter. The pitch reflects that, not a generic positioning statement.

concepts/ is the quietest win. It is the team's shared vocabulary: the internal frameworks, terms, and mental models we use to describe our own product and market. Without it, every new agent re-invents our worldview from scratch and picks up subtly wrong versions of our own language. With it, every agent and every human on the team talks about the same thing the same way. The first time a new specialist agent uses the exact phrase the team uses, in the exact context, you understand why the folder exists.

The interface is a Slack DM, not an API

GBrain solves the memory problem. The interface problem is separate, and just as important.

A shared brain only works if humans and agents hit it through the same channel. Otherwise it splits the team: the agents talk to the memory, the humans talk to a dashboard, nobody sees the same thread.

In our setup we have 2-3 AI "employees" living in Slack. They have roles, not just names:

• @CEO — business decisions, strategy, deal shape
• @CMO — marketing, positioning, channels, campaigns
• @CPO — product, roadmap, prioritization

Routing is the same as messaging a human colleague. A business question goes to @CEO. A marketing question goes to @CMO. A product question goes to @CPO. Code review and bug-fix work routes to the same DMs. The agents handle it through the same surface, not a separate tool. All three roles read and write the same GBrain repo, so a decision the @CEO agent records on Monday is context the @CMO agent has on Tuesday.

Slack is the primary channel. Telegram is the fallback transport: same agents, different pipe, in case Slack is down or someone is on the move. The web portal is a third entry point. The agents are not bolted to one platform; they are first-class colleagues who can be reached anywhere the team is.

The interface to the shared brain is a DM to a named role. That is the part the memory-infra conversation keeps missing.

What this means for the agentic workspace

GBrain handles the memory layer. The workspace layer, projects, threads, and accountability for mixed human + agent teams, is what Tulsk is for. Both work on the same instinct: humans and agents read and write the same thing. Markdown files for memory. Threads and comments for work.

The mapping is clean:

• GBrain projects/ folder ↔ Tulsk projects
• "Orchestrator writes durable decisions back" ↔ Tulsk threads and comments
• "Specialists read-first" ↔ OpenClaw agents with workspace access
• "Orchestrator reads before every task" ↔ EMA
• "2-3 AI employees in Slack" ↔ @-mention agents and humans in the same Tulsk thread

This is the bridge from multi-agent memory, which looks like a database problem, to the agentic workspace, which is a team problem.

It is also why most AI rollouts stall at the demo stage. The agent has memory, the human has none, and there is no shared place for the work to land. We wrote about the workspace side in what an agentic workspace actually is and the weekly-operating cadence in how we use Hermes Agent for SEO research.

If you are evaluating Tulsk, we recommend running GBrain underneath it. See pricing for Tulsk, and the GBrain repo for the memory layer.

The fair objection

The pushback we hear: "isn't this just another memory provider with a markdown coat of paint?"

It is not. The difference is which artifact is the source of truth. In a vector-DB-only stack, the truth lives in opaque embeddings, and the markdown export, if there is one, is a downstream view. In GBrain, the markdown brain repo is the truth, and the vector index is the downstream view.

That inversion is the entire point. When you edit people/jane-doe.md and commit it, the agents see the corrected version on their next read. When you git log, you see exactly what the agents added, when, and why. The team is in control of what their agents believe, instead of negotiating with a black box.

What to do next

Three concrete moves if you are running a multi-agent setup right now:

1. Audit where your agents' memory lives today. If no human on the team can browse it without opening a DB client, that is the first thing to fix.
2. Try GBrain. It is open source, MIT-licensed, and ships with PGLite so a personal brain can start without a separate database server. Start with people/ and concepts/, the two folders that pay back fastest.
3. Give each agent a role and a human-shaped surface. A Slack handle, a Telegram bot, a workspace @-mention, not a custom dashboard or a CLI flag.

The multi-agent context problem is not a model problem. It is a workspace problem. Solve it where your team already lives, and use a memory layer your team can also read.

Try Tulsk free→