Directions Brain

context-os-brain

5 min read

Context OS / Brain

Definition

An LLM-maintained company knowledge wiki that ingests cross-conversation context (meetings, calls, docs, chat) and exposes it both to humans (for browsing/synthesis) and to agents (as queryable structured context). Conceptually an org-level instantiation of Karpathy’s “LLM Wiki” pattern.

Key points

  • Two pillars (Nizan’s framing in the meeting):
    1. Operating System — the wiki itself: ingest pipeline, structured pages, dedup, permissions, personal/team/org spaces, scale.
    2. Skins — the things plugged into the OS: NoteTakers, integrations, agent harnesses that consume the brain.
  • The unlock is cross-team context. Within one person’s existing context the brain mostly saves copy-paste. The killer use case is when an IC needs knowledge from a room they were not in, or when a CEO needs to see how stated priorities are translating into actual work.
  • Agent-native is the design constraint. The brain has to be queryable by agents from day 1, not retrofitted. See agent-native-go-to-market.
  • Compounds over time. Unlike RAG-on-uploads, the brain is incrementally maintained — every new source updates the existing structure rather than being re-derived per query.
  • Personal / team / org tiers with permissions. Authorization is non-trivial because permissions are dynamic; glean’s claimed solution is the closest reference point.
  • Agent harness for the Brain. guy-barkat’s 2026-05-31 framing: just as coding agents need a “harness” (Claude Code’s tool loop, validation, retries), the Brain needs an organizational harness — proactive validation when sources disagree, human-in-the-loop on uncertain inferences, explicit conflict surfacing (“Nizan changed the OKR — please confirm” rather than silently overwriting), and a persistent log so conflicts can be audited. Naive ingest at scale produces a worse-than-nothing source-of-truth because partial data confidently extrapolates.
  • Difficulty as moat. Same conversation, same person: because the Brain is hard to build correctly at scale, large hi-tech enterprises won’t successfully build it in-house, which is exactly what makes it a sellable product to them. This reinforces (not contradicts) vertical-use-case-led-brain — narrowing scope to one vertical’s data shape is what makes the harness tractable for a startup.
  • Source-of-truth — qualified yes. nizan-shifman: the Brain is the org’s source of truth — alignment + transparency + speed flow from it. guy-barkat: not a true source-of-truth because it’s not deterministic — at best it’s “high-quality aggregation that may be wrong.” Working synthesis: it’s a useful source-of-truth when paired with conflict-surfacing UX, not as an opaque oracle.

Evidence

  • 2026-05-06-brain-os-strategy-brainstorm — the prototype was demoed; Harmony’s full landing page, pricing strategy, and competitive SWOT were generated from accumulated brain context with no manual context attachment.
  • 2026-05-27-directions-vertical-pivot-and-prediction-markets — Brain repositioning to vertical-use-case-led product; nizan-shifman’s heatmap example as evidence the Brain compounds across his work; ari-leshno / eye-clinic anecdote as a candidate vertical.
  • 2026-05-09-alonhuri-linkedin-ai-native-company — external VC validation of the framing: alon-huri (team8) defines a real AI-native company as “an organizational operating system” — closed-loop, queryable, agents treated like employees with maximum context (meetings, Slack, email, Notion, Jira, code, customer feedback). Verbatim alignment with the team’s pillars; Alon’s litmus-test question — “when a real question comes up about your company, who answers it: the system or five people in a chain?” — is exactly the painkiller framing the Brain is being designed to deliver. The migration dilemma he flags (“how to transition orgs of hundreds-to-thousands without breaking them mid-flight”) is an open vertical-wedge candidate. Skepticism caveat: Alon is a VC partner; treat as advocacy, not neutral analysis.
  • 2026-05-31-directions-connect-businesses-and-brain-scaling — Guy’s strongest scaling-difficulty argument yet (need an agent harness; partial data is worse than no data; conflict resolution is unsolved); flipped mid-conversation to “difficulty is the moat.” Saar reinforced that vertical determines data model. Nizan reported “I’ve cracked AI” via daily Brain use — confirms personal-productivity case at the user-level even while the org-level value is still being articulated.
  • 2026-06-02-directions-account-management-vertical — AM vertical demo sharpened the concrete Brain architecture: one Brain per account manager, per-customer nodes built from raw call transcripts, agents draw from Brain as source of truth. Saar explained the current indexing approach (index.md + graph traversal performant at current scale; RAG/chunk layer planned next). Team reached explicit consensus: “Brain is infrastructure; agents are the product.” Agentic CRM debate (integrate via MCP vs. build new CRM) is live and open.

Strategic direction (updated 2026-05-27)

The team’s working answer to the prior open question “what separates the Brain from another RAG tool” has shifted: rather than defend the horizontal context-OS pitch on its own merits, build the Brain as the moat underneath a vertical, use-case-led agent product. See vertical-use-case-led-brain for the full argument. This reframes most of the open questions below: scale, permissions, and conflict-resolution stop being “must solve generically” and become “must solve for the chosen vertical’s data shape and access pattern.”

Open questions

  • Which vertical does the Brain pick first? Working answer as of 2026-06-02: Account Management / Customer Success. See account-management-vertical and vertical-use-case-led-brain.
  • How to scale to large orgs (Saar acknowledges current prototype will not scale as-is — has overnight ideas about scale/RAG approaches but not yet implemented). 2026-05-31 sharpens this: the missing piece is the agent harness (proactive validation, human-in-the-loop, conflict surfacing), not just sharding.
  • Permissions model at scale — is the glean approach the best reference, or is there a better one given dynamic permissions?
  • Conflict resolution when sources disagree (e.g. KPI changes across meetings) — current behavior is a mix of append and edit; not stress-tested. 2026-05-31: explicitly flagged as the load-bearing UX gap; Saar’s cousin at Amazon got the same question on his Brain demo there.
  • Pricing model. Holy-Grail framing (Nizan) doesn’t yield a number; Guy keeps returning to “we don’t know what value to attribute, so we don’t know what to charge.” Open as of 2026-05-31.

Graph View

Backlinks