Brief
Company Brain: origins, OKF, and a founder-scale version
Shared memory for people and agents — not a chatbot, not RAG, and not a Google product name.
A Company Brain is an organization’s shared, continuously maintained, AI-readable memory. People and agents should be able to see how the company actually operates, act on current context, and write results back. It is not a Google product. Google Cloud’s Open Knowledge Format (OKF) is a file spec that can sit inside such a system. The name that caught fire in 2025–2026 came from Y Combinator’s Garry Tan (GBrain) and a cluster of startups (Supermemory, Qontext, and others), then got a second wind from Andrej Karpathy’s LLM Wiki and from the fact that agents were failing in production for lack of local context, not lack of reasoning.
The practical test is simple. A market-research agent should not start from a blank web search. Before it acts it should know which market definitions the team already uses, what research is done, which sources are trusted, which assumptions are live versus deprecated, which metrics are approved, and what the last experiments concluded. After it acts it should write findings, links, confidence, and any change to prior assumptions back into the same layer. That read–act–write loop is the difference between a knowledge chatbot and a Company Brain.
Map of related product landscapes: GEO, Agentic Commerce, Commerce AI. This brief is the category story, not a vendor catalog.
From knowledge management to agentic memory
| Stage | Typical form | What it solved | Why it is not a Company Brain |
|---|---|---|---|
| Knowledge management | SharePoint, Confluence, Notion, SOP wikis | Documents humans can find | Manual, stale, weak machine use |
| Personal second brain | Obsidian, PARA, private Markdown | One person’s recall | No shared truth, no permissions, no team agents |
| Enterprise search / RAG | Embeddings, vector DBs, chat-with-docs | Relevant fragments | Does not decide current truth or resolve conflicts |
| Knowledge graph / semantic layer | Entities, relations, metric catalogs | Structured relationships | Expensive to keep honest; often disconnected from daily work |
| LLM Wiki | LLM-maintained Markdown with links | Continuous compilation of reusable pages | No common schema, trust, or portability |
| Company Brain | Shared, governed, evolving context + action | Agents and people work from one operating memory | Still early; governance is the hard part |
A document repo answers “where is the file?” A RAG system answers “which chunks look similar?” A Company Brain should answer: what does the organization currently believe, why, who verified it, what changed, and what should the agent do next?
The 2025–2026 turn is that models got good enough that production failures stopped looking like “the model cannot reason” and started looking like “the model does not know our names, approvals, customer constraints, or whether that bug was closed three weeks ago.”
Karpathy’s LLM Wiki is the direct predecessor
The LLM Wiki pattern, associated with Andrej Karpathy, is: do not reconstruct the answer from raw files on every query. Compile recurring knowledge into a persistent Markdown wiki the LLM maintains.
Three layers:
- raw/ — source documents, transcripts, research, logs. Humans add. The LLM reads; it does not rewrite the originals.
- wiki/ — concept pages, entity pages, decisions, timelines, indexes. The LLM writes and cross-links.
- AGENTS.md / CLAUDE.md — how to ingest, cite, resolve contradictions, and lint.
Karpathy’s line: Obsidian is the IDE, the LLM is the programmer, the wiki is the codebase. Google’s OKF write-up treats this pattern as the thing it is formalizing: agents maintain a growing Markdown knowledge base the way a team maintains a codebase — review, diff, history.
Two gaps remain. Every repo is a dialect (folders, filenames, metadata). And a page of Markdown does not advertise whether it is a draft, stale, human-verified, or already deprecated. Those two gaps are why OKF exists.
Google Research’s WikiSkill paper takes the same idea one layer down: not only research knowledge, but agent experience. Raw traces stay immutable; a wiki of patterns is consolidated from successes and failures; executable skills are updated only after a proposed change is tested, and rolled back if it hurts. For a solo builder that is the useful discipline, not the benchmark apparatus: trace → pattern → skill → next run → review.
Google OKF: a format for the brain, not the brain
Google Cloud published OKF v0.1 on 12 June 2026 as an open spec for portable, navigable, versionable knowledge bundles, and v0.2 on 24 July 2026 with trust and lifecycle signals. It does not require Gemini, Google Cloud, or a particular SDK. A bundle is a directory tree. Each Markdown file is a concept (a metric, an API, a playbook, a decision, a skill). The only required frontmatter field is type. Suggested extras: title, description, resource, tags. Links are ordinary Markdown. index.md lets an agent browse cheaply before opening full text.
OKF is not a vector database, a graph, a SaaS, a chat UI, or a Company Brain. It is a knowledge interchange layer. A Company Brain can use it as the canonical file format while retrieval, MCP, workflows, and models sit around it. Git is the natural home: history, authorship, diffs.
v0.2 is the part that matters for agents that write:
| Signal | Question it answers |
|---|---|
sources | Where did this claim come from? |
generated | Which agent or person wrote it, and when? |
verified | Has a machine or a human reviewed it? |
status | Draft, stable, or deprecated? |
stale_after | When must this be re-checked? |
| Attested computation | Did this number run the approved method? |
Attested computation splits “definition of GMV” from “the SQL we actually allow.” An analytics agent can fill parameters; an executor returns a receipt; a non-LLM attester checks that the job matches the approved calculation. That is the control you want before an agent is allowed near attributed revenue.
A concept page, stripped down:
---
type: Playbook
title: Cross-border product opportunity assessment
status: stable
generated:
by: research-agent
at: 2026-08-31T06:00:00Z
verified:
- by: human:tao-zhang
at: 2026-08-31T08:00:00Z
stale_after: 2026-11-30T00:00:00Z
sources:
- id: market-methodology
title: Internal market research methodology
resource: /references/market-research-methodology.md
---
The YAML is not decoration. It lets an agent decide before reading the body whether the page is current, authoritative, and on-topic.
Four operating layers
1. Ingestion. Notion, Drive, Slack, GitHub, CRM, tickets, meetings, warehouses, external research. The point is not to ingest everything. Mark canonical sources versus discussion, decide what must never be ingested, and separate real-time events from batch.
2. Consolidation. This is the line versus “RAG with a chat box.” New material becomes an observation, compared to current beliefs. Conflicts resolve by source authority, recency, human sign-off, and domain owner. Old beliefs are marked deprecated, not deleted. Example: an older page says Meta ads are the primary SEA acquisition channel; three experiments show stronger conversion on TikTok Shop live. The brain should not retrieve both as peers. It should keep the old strategy as history, attach the evidence, and publish a new current recommendation after the right human review.
3. Retrieval. Semantic search, keyword/BM25 for SKUs and codes, entity lookup, graph walks, time filters, reranking, and permission filters before anything enters the context window. OKF’s index.md plus frontmatter is cheap navigation. A vector index or MCP server is the runtime. They are not substitutes.
4. Action and feedback. Agents read before they act and write after. Competitor research, SEO drafts, support replies, coding PRs — then the output, the human decision, and the metric result become new observations. Without write-back you have a library. With it you have a brain.
Vectorize’s bar, which is strict and useful: shared, enforceable in the workflow, evolving, and agent-readable. Miss one and you still have a wiki, a search layer, or a graph — not a Company Brain.
What it is not
| Thing | What you get | Enough? |
|---|---|---|
| Notion / Confluence | Human docs | Source, not the brain |
| RAG / vector DB | Similar chunks | No current truth, no lifecycle |
| Knowledge graph | Relations | Not automatically operational knowledge |
| Personal second brain | One person’s memory | Wrong scope and permissions |
| LLM Wiki | Evolving Markdown | Foundation, not org governance |
| OKF | Portable files + metadata | Format, not the system |
If the “company” is one person
You do not need Slack ingestion, per-user ACLs, or a memory database. You need a Founder Brain: Karpathy’s wiki as the knowledge layer, WikiSkill’s trace → pattern → skill loop as the operating discipline, and three Company Brain rules — canonical files, consolidation instead of dual retrieval, write-back after work.
Keep enterprise ingestion, graphs, self-modifying skills, and a meta-platform that only organizes the organizer for later. A compact Git repo with raw/, wiki/ (or docs/), skills/, patterns/, and an AGENTS.md is the whole MVP. Globegraphy and this site’s own research maps are the first two tenants: source-audited market facts in one place, agent/product theses in the other, skills for “source-audited research” and “research to published brief.”
Minimum governance, copied from OKF v0.2 and worth putting in AGENTS.md on day one:
- Agent-written pages start as
status: draft. - External claims need a source and a date.
- Market, product, metric, and policy pages need a human
verifiedbeforestable. - Time-sensitive pages get
stale_after. After that they are history, not operating rules. - Superseded decisions are
deprecated, not silently overwritten. - Agents read the relevant pages before consequential action, and write results back as observations — not as automatic truth.
Company Brain is a real problem wearing an unconverged product label. The hard parts are authority, conflict, permissions, human verification, making work actually read the brain, and making results actually return. OKF is an early common language — closer to what MCP is for tools, or Git for code — not the finished system. For this site, the working version is: maps hold the living cards; briefs hold the dated argument; inbox holds raw research the agent may compile but must not publish as a page.