{"slug": "ozbrain-s-shared-memory-architecture-how-multi-agent-teams-avoid-re-explaining", "title": "OzBrain's Shared Memory Architecture: How Multi-Agent Teams Avoid Re-Explaining Context Across Sessions", "summary": "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.", "body_md": "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.\n\nThe 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.\n\nOzBrain 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:\n\nWhen 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.\n\nThe 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.\n\nOzBrain 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.\n\nThe routing index uses a simple keyword and topic model:\n\nThis 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/\").\n\nWhen two agents update the same knowledge unit, OzBrain uses last-write-wins with a conflict flag. The system does not merge changes automatically. Instead:\n\nThis 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.\n\n| Conflict Strategy | Precision | Latency | Failure Mode |\n|---|---|---|---|\n| Last-write-wins | Low | Instant | Silent overwrites |\n| Manual merge | High | Minutes | User fatigue |\n| OzBrain (flag + LWW) | Medium | Instant | Requires agent or user to check flags |\n\nShared 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.\n\nOzBrain 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.\n\nThe 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.\n\nOzBrain exposes its API through an MCP server at `https://ozbrain.com/api/mcp`\n\n. Agents connect by adding the server to their MCP configuration. The connector supports four operations:\n\n`list_brains`\n\n: Returns all brains the user can access.`query_brain(brain_id, topic)`\n\n: Returns knowledge units matching the topic.`write_unit(brain_id, topic, content)`\n\n: Creates or updates a knowledge unit.`read_unit(brain_id, unit_id)`\n\n: Fetches a specific unit by ID.Here's a minimal example of an agent querying for client context:\n\n``` python\nimport mcp\n\nclient = mcp.Client(\"https://ozbrain.com/api/mcp\", api_key=user_token)\n\n# List available brains\nbrains = client.call(\"list_brains\")\nteam_brain = next(b for b in brains if b[\"name\"] == \"team-shared\")\n\n# Query for client contacts\nunits = client.call(\"query_brain\", {\n    \"brain_id\": team_brain[\"id\"],\n    \"topic\": \"clients/meridian\"\n})\n\n# Fetch the top-ranked unit\nif units:\n    contact_info = client.call(\"read_unit\", {\n        \"brain_id\": team_brain[\"id\"],\n        \"unit_id\": units[0][\"id\"]\n    })\n    print(contact_info[\"content\"])\n```\n\nThe 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.\n\nOzBrain 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.\n\nThe 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.\n\nFor 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.\n\nOzBrain fits teams that:\n\nAvoid OzBrain if:\n\nOzBrain 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.\n\nThe 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.\n\nThe 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.\n\nIf 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.", "url": "https://wpnews.pro/news/ozbrain-s-shared-memory-architecture-how-multi-agent-teams-avoid-re-explaining", "canonical_source": "https://dev.to/mech_app_ai/ozbrains-shared-memory-architecture-how-multi-agent-teams-avoid-re-explaining-context-across-1c19", "published_at": "2026-08-24 00:07:24+00:00", "updated_at": "2026-08-24 00:43:37.493951+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "developer-tools"], "entities": ["OzBrain", "Claude", "ChatGPT", "Cursor", "Model Context Protocol", "Hacker News"], "alternates": {"html": "https://wpnews.pro/news/ozbrain-s-shared-memory-architecture-how-multi-agent-teams-avoid-re-explaining", "markdown": "https://wpnews.pro/news/ozbrain-s-shared-memory-architecture-how-multi-agent-teams-avoid-re-explaining.md", "text": "https://wpnews.pro/news/ozbrain-s-shared-memory-architecture-how-multi-agent-teams-avoid-re-explaining.txt", "jsonld": "https://wpnews.pro/news/ozbrain-s-shared-memory-architecture-how-multi-agent-teams-avoid-re-explaining.jsonld"}}