OzBrain's Shared Memory Architecture: How Multi-Agent Teams Avoid Re-Explaining Context Across Sessions

OzBrain, a shared memory architecture for multi-agent AI teams, was showcased on Hacker News, drawing 85 points and 50 comments. The system uses the Model Context Protocol (MCP) to let agents read and write to a shared knowledge substrate, avoiding the need to re-explain context across sessions. It features scoped brains, a routing index, freshness tags, and a conflict flag strategy to handle stale or contradictory context.

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. 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: 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. 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: 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/" . 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: 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 | 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 the fact before acting. The system does not auto-expire knowledge because some facts e.g., "brand voice guidelines" remain valid for months. The more dangerous failure mode is contradictory context . If an agent's working memory from the current session conflicts with OzBrain's shared memory, the agent must decide which to trust. OzBrain does not provide a resolution mechanism. Agents typically trust their working memory for session-specific facts and defer to shared memory for long-lived state. OzBrain exposes its API through an MCP server at https://ozbrain.com/api/mcp . Agents connect by adding the server to their MCP configuration. The connector supports four operations: list brains : Returns all brains the user can access. query brain brain id, topic : Returns knowledge units matching the topic. write unit brain id, topic, content : Creates or updates a knowledge unit. read unit brain id, unit id : Fetches a specific unit by ID.Here's a minimal example of an agent querying for client context: python import mcp client = mcp.Client "https://ozbrain.com/api/mcp", api key=user token List available brains brains = client.call "list brains" team brain = next b for b in brains if b "name" == "team-shared" Query for client contacts units = client.call "query brain", { "brain id": team brain "id" , "topic": "clients/meridian" } Fetch the top-ranked unit if units: contact info = client.call "read unit", { "brain id": team brain "id" , "unit id": units 0 "id" } print contact info "content" The MCP connector handles authentication via email-based login codes. When a user first connects, OzBrain sends a one-time code to their email. The agent exchanges the code for a session token, which it stores for future requests. OzBrain runs as a hosted service. Users do not self-host the storage layer or indexing infrastructure. This simplifies deployment but introduces a dependency on OzBrain's availability. If the MCP endpoint goes down, agents lose access to shared memory and fall back to session-only context. The system does not expose detailed observability hooks. Agents cannot trace which knowledge units were queried or how long the index lookup took. This makes debugging slow queries difficult. Teams must rely on OzBrain's internal logging, which is not surfaced to users. For teams that need audit trails, the lack of query logs is a blocker. You cannot reconstruct which agent read which fact at what time, so compliance workflows that require provenance tracking will struggle. OzBrain fits teams that: Avoid OzBrain if: OzBrain solves the context duplication problem with a straightforward storage and indexing layer. The MCP connector makes it easy to wire into existing agent workflows, and the scoping model personal vs. shared brains prevents accidental leakage. The routing index keeps prompts small by fetching only relevant knowledge units. The trade-offs are clear: last-write-wins conflict resolution, no semantic search, and reliance on a hosted service. For teams that can live with these constraints, OzBrain removes the friction of re-explaining context to every new agent session. For teams that need richer conflict resolution or self-hosted deployment, the architecture is too opinionated. The freshness tagging is a smart middle ground between auto-expiration which breaks long-lived facts and no expiration which lets stale data accumulate . The conflict flag is less satisfying because it pushes resolution back to the user or agent, but automatic merging would require semantic understanding that OzBrain does not attempt. If your multi-agent workflow is breaking down because agents cannot share context, OzBrain is worth testing. If you need fine-grained control over conflict resolution or query observability, you will hit the ceiling quickly.