Directions Brain

Context OS / Brain

8 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.
  • Passive ingest is not enough. 2026-06-13 sharpened the harness requirement: for the Brain to be trusted, it must actively ask clarifying questions, let users mark stale/irrelevant action items, and capture decisions that are not cleanly present in transcripts. Otherwise it becomes a confident but partial summary layer.
  • Output-first constraint. Same meeting made the product critique harsher: a Brain that only stores and retrieves context is hard to sell. The Brain has to power a specific output surface - AM capacity, revenue-cycle optimization, construction exec visibility, etc.
  • OKF / persistent wiki validation. In the 2026-06-14 session, the team interpreted Google’s OKF-style specification as external validation of the Karpathy-style persistent Markdown wiki pattern: frontmatter helps an LLM route to the right file without reading every token.
  • Brain quality may be the reusable internal work. Guy’s dogfooding proposal was not generic context infrastructure; it was improving the inputs and maintenance loop: proactive action-item follow-up, missing-context detection, stale/garbage cleanup, user interviews, and correction flows so the Brain can support AM or construction agents later.
  • But Brain is not automatically the product. Saar pushed the team to treat Brain as a black-box capability in the toolbox and return to concrete pains. Nizan agreed generic context management may become built into Claude/OpenAI/Google, so startup leverage is more likely in vertical flavor and workflow outputs.
  • Human accountability is the missing trust layer. 2026-06-20 sharpened the trust problem: better retrieval/indexing is not enough because real org truth includes politics, culture, authority, and half-true status reports. The Brain should reduce the number of human checks, but key facts still need human approval to become accountable knowledge.
  • Living context layer is now an external operating recommendation. a16z’s software-refounding article explicitly recommends process-capture sprints and a living context layer from SOPs, tickets, transcripts, requirements docs, policies, CRM notes, support logs, event data, and approval paths, with evals around accuracy, exception handling, latency, and cost. That validates living-context-layers-become-ai-infrastructure while also warning that context is infrastructure for an AI-native product engine, not the product by itself.

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.
  • 2026-06-13-directions-revenue-cycle-and-construction-poc — output-first critique of generic context products; active clarification / human-in-the-loop surfaced as necessary for Brain trustworthiness; three output surfaces compared: revenue-cycle-brain, account-management-vertical, and construction exec visibility.
  • 2026-06-14-directions-from-home-strategy-brain-dogfooding — OKF/frontmatter interpreted as validation of persistent wiki context; Brain dogfooding scoped around proactive maintenance and missing-context discovery, but team cautioned against treating Brain itself as the product before validating a pain.
  • 2026-06-20-directions-planning-the-week-18-30 — strongest human-accountability framing so far: company-context architectures may improve technically, but they will not be trusted for important decisions unless the product captures human approval/rejection at the right moments.
  • 2026-03-23-a16z-two-paths-left-for-software — external evidence for living context layers as AI-native company infrastructure: workflow/process capture, documentation as product infrastructure, and evals on accuracy/exceptions/latency/cost. Caveat: the article is public-software-board advice from a16z, not operator validation of a paid Brain product.

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? 2026-06-02 working answer: account-management-vertical. 2026-06-13 reopened comparison with revenue-cycle-brain and construction POC; AM remains clearer, revenue-cycle is larger, construction has warmer design-partner access.
  • 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.
  • Which proactive-maintenance features are actually required for a vertical Brain, and which are generic infrastructure that labs will absorb?
  • What is the first vertical workflow where human approval makes the Brain feel trustworthy without becoming operational drag?

Graph View

Backlinks