When you run multiple agents across Claude, ChatGPT, and Cursor, each one starts from scratch unless you manually paste context into every session.
OzBrain solves this by exposing a shared knowledge substrate that agents read and write through the Model Context Protocol (MCP).
The system routes context so agents see only what they need, and teams avoid explaining the same facts to every new agent instance.
The Show HN post drew 85 points and 50 comments because the problem is real: production multi-agent workflows break down when context lives in isolated chat histories or scattered documents.
OzBrain's architecture treats knowledge as a first-class resource with explicit scoping, indexing, and conflict resolution.
Storage Layer and Scope Boundaries OzBrain organizes knowledge into brains, which are either personal or shared.
Each brain holds structured knowledge units that agents query through the MCP connector.
The system decides scope at write time: Personal brains store user-specific preferences, writing style, and private project state.
Shared brains hold team-wide facts like client contacts, project decisions, and open threads.
When an agent writes to OzBrain, it specifies the target brain.
The MCP connector enforces access control: agents can read from any brain the user has joined, but write permissions depend on the brain's sharing policy.
This prevents accidental leakage of personal context into team memory.
The storage layer tags each knowledge unit with metadata: creation timestamp, last update, and a freshness indicator (fresh, aging, stale).
Agents use these tags to decide whether to trust the stored fact or re-query the source.
Indexing Strategy and Query Routing OzBrain does not load the entire knowledge graph into every prompt.
Instead, it maintains a routing index that maps topics to knowledge units.
When an agent queries for "client contacts," the index returns pointers to relevant units without pulling in unrelated project state.
The routing index uses a simple keyword and topic model: Each knowledge unit declares its topic (e.g., "clients/meridian", "voice", "projects/q3-launch").
The index builds a reverse lookup from topic to unit ID.
Agents send a topic query through the MCP connector, which returns a ranked list of unit IDs.
The agent fetches only the top-ranked units, keeping the prompt under token budget.
This approach trades precision for speed.
The index does not use embeddings or semantic search, so agents must know the right topic label.
In practice, this works because teams establish naming conventions early (e.g., "clients/", "projects/", "preferences/").
Conflict Resolution When Multiple Agents Write When two agents update the same knowledge unit, OzBrain uses last-write-wins with a conflict flag.
The system does not merge changes automatically.
Instead: Agent A writes a new version of "projects/q3-launch" with status "delayed." Agent B writes a conflicting version with status "on track" 30 seconds later.
OzBrain stores Agent B's version as the current state but flags the unit as "conflicted." The next agent to read "projects/q3-launch" sees the conflict flag and can surface it to the user.
This is a deliberate trade-off.
Automatic merging requires semantic understanding of the conflict, which OzBrain does not attempt.
The conflict flag ensures that contradictions do not silently propagate through the team's shared memory.
Conflict Strategy Precision Latency Failure Mode Last-write-wins Low Instant Silent overwrites Manual merge High Minutes User fatigue OzBrain (flag + LWW) Medium Instant Requires agent or user to check flags Failure Modes and Staleness Shared memory introduces a new failure mode: stale context.
If a knowledge unit says "client prefers email" but the client switched to Slack last week, agents will make incorrect assumptions until someone updates the unit.
OzBrain mitigates this with freshness tags.
When an agent reads a unit marked "aging," it can prompt the user to confirm t