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 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.
MCP Connector Implementation
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:
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.
Deployment Shape and Observability
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.
When to Use OzBrain
OzBrain fits teams that:
- Run multiple agents (Claude, ChatGPT, Cursor) and need consistent context across tools.
- Have established naming conventions for topics and can train agents to query the right labels.
- Accept last-write-wins conflict resolution and are willing to manually resolve contradictions.
- Trust a hosted service for knowledge storage and do not require self-hosted deployment.
Avoid OzBrain if:
- You need semantic search or embeddings-based retrieval. The keyword index is too brittle for open-ended queries.
- Your workflow requires automatic conflict merging. The conflict flag is a signal, not a solution.
- You need detailed query logs or observability into agent memory access.
- You require on-premises deployment or air-gapped operation.
Technical Verdict
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.