Your people and your agents — reading, writing, and growing the same knowledge base, with governance and permissions built in. Every conversation, decision, and document compounds into leverage your team keeps from day one.
Andrej Karpathy, April 2026 (19.6M views): “a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge” — describing an LLM-maintained wiki of markdown files that agents read, write, and query. He closes with: “I think there is room here for an incredible new product instead of a hacky collection of scripts.”
Three days later, Dharmesh Shah (HubSpot CTO) sketched the team version: “Next step would be to make it multi-player so businesses/teams could use it. Content is default private (each user has their own directory). Any individual directory/file could be tagged/shared to a team, to the company or to the world (public). Make it available via API, MCP, CLI etc.”
Andreessen Horowitz is framing the next wave as institutional AI: “Individual AI creates chaos. Institutional AI creates coordination.” They argue that “productive individuals do not make productive firms” — and that “thousands of agents (or humans) rowing in opposing directions creates a standstill.” Brilliant is the coordination layer: an institutional-grade context store designed agent-first.
This is exactly what Brilliant is.
The real context for your business is scattered across a dozen tools. Email. Calendar. Notion. Obsidian. Meeting notes. Slack. Every agent you add can only see a slice of it.
flowchart LR
subgraph tools["Where your knowledge lives"]
direction TB
EMAIL[Email]
CAL[Calendar]
NOTION[Notion]
OBS[Obsidian]
MEET[Meeting Notes]
SLACK[Slack]
end
subgraph users["Who needs it"]
direction TB
P1[People]
AG1[Agents]
end
P1 -.->|hunts across| tools
AG1 -.->|sees a slice| tools
style tools fill:#181b24,stroke:#f0a77b,color:#e2e4ea
style users fill:#181b24,stroke:#9ba1b0,color:#e2e4ea
style EMAIL fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style CAL fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style NOTION fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style OBS fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style MEET fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style SLACK fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style P1 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style AG1 fill:#242836,stroke:#6c8aff,color:#e2e4ea
flowchart BT
subgraph tools["Existing tools"]
direction TB
T1[Email]
T2[Calendar]
T3[Notion]
T4[Obsidian]
T5[Meeting Notes]
T6[Slack]
end
P1["Ada
(her agent)"] -.-> tools
P2["Ben
(his agent)"] -.-> tools
P3["Chen
(her agent)"] -.-> tools
P4["Priya
(her agent)"] -.-> tools
P5["Marcus
(his agent)"] -.-> tools
P6["Sofia
(her agent)"] -.-> tools
D1[Research notes] --> P1
D2[Sales calls] --> P2
D3[Code & PRs] --> P3
D4[Customer emails] --> P4
D5[Meeting notes] --> P5
D6[Design docs] --> P6
style tools fill:#181b24,stroke:#f0a77b,color:#e2e4ea
style T1 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style T2 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style T3 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style T4 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style T5 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style T6 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style P1 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style P2 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style P3 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style P4 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style P5 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style P6 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style D1 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style D2 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style D3 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style D4 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style D5 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style D6 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
It isn't just you hunting across a dozen tools — every teammate is doing the same, each with their own slice of data. The scatter multiplies. Nothing compounds, nothing coordinates.
flowchart LR
subgraph sources["Your existing tools"]
direction TB
S1[Email]
S2[Calendar]
S3[Notion]
S4[Obsidian]
S5[Meetings]
end
USER[You] -->|ask / instruct| AGENT["Your Agent
(Claude Co-work / Code)"]
sources -.->|agent reads| AGENT
AGENT -->|reads & writes| CORTEX[(Brilliant Knowledge Base)]
CORTEX -->|structured context| AGENT
AGENT -->|answers| USER
style sources fill:#181b24,stroke:#f0a77b,color:#e2e4ea
style S1 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style S2 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style S3 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style S4 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style S5 fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style USER fill:#242836,stroke:#6c8aff,color:#e2e4ea
style AGENT fill:#242836,stroke:#6c8aff,color:#e2e4ea
style CORTEX fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
flowchart LR
CEO1[CEO] -->|reads / writes| FIN[(Financial records)]
NH1[New hire] -->|reads / writes| FIN
FIN -.->|new hire edits numbers| BAD["Unintended change by junior user"]
style CEO1 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style NH1 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style FIN fill:#3d2a1a,stroke:#f0a77b,color:#f0a77b
style BAD fill:#3d1a1a,stroke:#f07b7b,color:#f07b7b
flowchart LR
CEO2[CEO] --> CA[CEO's Agent] --> PERM{Permissions}
NH2[New hire] --> NHA[New hire's Agent] --> PERM
PERM -->|authorized| FIN2[(Financial records)]
PERM -.->|blocked| DENY["New hire: no access"]
style CEO2 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style NH2 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style CA fill:#242836,stroke:#6c8aff,color:#e2e4ea
style NHA fill:#242836,stroke:#6c8aff,color:#e2e4ea
style PERM fill:#242836,stroke:#f0a77b,color:#e2e4ea
style FIN2 fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
style DENY fill:#3d1a1a,stroke:#f07b7b,color:#f07b7b
A shared folder treats everyone the same. Brilliant scopes access by role — and agents inherit the permissions of whoever invoked them, so the CEO's agent can see the books while the new hire's agent can't.
flowchart LR
AA1[Agent A] -->|writes| FILE[(File.md)]
AA2[Agent B] -->|writes| FILE
FILE -.->|last write wins| LOST["Agent A's work: gone"]
style AA1 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style AA2 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style FILE fill:#3d2a1a,stroke:#f0a77b,color:#f0a77b
style LOST fill:#3d1a1a,stroke:#f07b7b,color:#f07b7b
flowchart LR
BA1[Agent A] -->|writes| GOV{Governance}
BA2[Agent B] -->|writes| GOV
GOV --> DB[(Shared KB)]
DB -.->|every change attributed| KEEP["Nothing silently lost"]
style BA1 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style BA2 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style GOV fill:#242836,stroke:#f0a77b,color:#e2e4ea
style DB fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
style KEEP fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
Two people editing the same doc at the same time — someone's work disappears. Ten people, ten agents — it multiplies.
This isn't a productivity problem. It's an infrastructure problem. We'll come back to how writes land safely in Collaboration.
Every conversation, every decision, every lesson learned — captured once, available to everyone, forever.
Your team and your agents all read from and write to the same knowledge base. No more hunting across twelve tools for the right answer.
You don't live in a notes app. You talk to your agent; it reads and writes to Brilliant. Knowledge accrues without you editing pages by hand.
Every day your team uses it, the knowledge base gets smarter. New hires and new agents plug in and immediately have the full picture.
flowchart LR
subgraph s1["Day 1"]
direction TB
a1(( ))
end
subgraph s2["Day 2"]
direction TB
b1(( )) --- b2(( ))
end
subgraph s3["Day 3"]
direction TB
c1(( )) --- c2(( ))
c1 --- c3(( ))
c2 --- c4(( ))
c3 --- c5(( ))
c4 --- c6(( ))
c5 --- c6
end
subgraph s4["Day 4"]
direction TB
d1(( )) --- d2(( ))
d1 --- d3(( ))
d2 --- d4(( ))
d3 --- d4
d4 --- d5(( ))
d5 --- d6(( ))
d5 --- d7(( ))
d6 --- d8(( ))
d7 --- d9(( ))
d8 --- d10(( ))
d9 --- d11(( ))
d10 --- d12(( ))
d11 --- d12
d3 --- d7
d4 --- d8
d2 --- d9
end
s1 --> s2 --> s3 --> s4
style s1 fill:#181b24,stroke:#9ba1b0,color:#e2e4ea
style s2 fill:#181b24,stroke:#6c8aff,color:#e2e4ea
style s3 fill:#181b24,stroke:#6bdfb8,color:#e2e4ea
style s4 fill:#1a3d2e,stroke:#6bdfb8,color:#e2e4ea
style a1 fill:#242836,stroke:#9ba1b0
style b1 fill:#242836,stroke:#6c8aff
style b2 fill:#242836,stroke:#6c8aff
style c1 fill:#242836,stroke:#6bdfb8
style c2 fill:#242836,stroke:#6bdfb8
style c3 fill:#242836,stroke:#6bdfb8
style c4 fill:#242836,stroke:#6bdfb8
style c5 fill:#242836,stroke:#6bdfb8
style c6 fill:#242836,stroke:#6bdfb8
style d1 fill:#242836,stroke:#6bdfb8
style d2 fill:#242836,stroke:#6bdfb8
style d3 fill:#242836,stroke:#6bdfb8
style d4 fill:#242836,stroke:#6bdfb8
style d5 fill:#242836,stroke:#6bdfb8
style d6 fill:#242836,stroke:#6bdfb8
style d7 fill:#242836,stroke:#6bdfb8
style d8 fill:#242836,stroke:#6bdfb8
style d9 fill:#242836,stroke:#6bdfb8
style d10 fill:#242836,stroke:#6bdfb8
style d11 fill:#242836,stroke:#6bdfb8
style d12 fill:#242836,stroke:#6bdfb8
In four days of active use, a team's knowledge base can reach this level of connectedness. The value isn't the count of nodes — it's the edges between them compounding.
Massive knowledge bases don't have to mean heavy context. Brilliant retrieval climbs a five-level ladder — starting with the smallest indexes and only reaching for full entries when the agent actually needs them. The map is built and maintained automatically as the knowledge base grows.
No grep required. Titles, paths, relationships, and summaries are first-class metadata stored alongside each entry — not re-derived by scanning files. The agent asks the database for the map; the database hands it back natively.
flowchart TB
AGENT["Agent"] -->|get_index depth=N| L1
L1["L1 — Category counts by type
minimal tokens"]
L2["L2 — + Document index
titles, IDs, paths, timestamps"]
L3["L3 — + Relationships between entries
recommended default"]
L4["L4 — + Summaries for each entry
high tokens"]
L5["L5 — + Full content of all entries
very high tokens"]
L1 -->|deeper only if needed| L2
L2 -->|deeper only if needed| L3
L3 -->|deeper only if needed| L4
L4 -->|deeper only if needed| L5
KB[("Knowledge Base")] -.->|auto-indexed on write| L1
L5 -->|just enough context| AGENT
style AGENT fill:#242836,stroke:#6c8aff,color:#e2e4ea
style L1 fill:#242836,stroke:#6bdfb8,color:#6bdfb8
style L2 fill:#242836,stroke:#6bdfb8,color:#e2e4ea
style L3 fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
style L4 fill:#242836,stroke:#f0a77b,color:#e2e4ea
style L5 fill:#3d2a1a,stroke:#f0a77b,color:#f0a77b
style KB fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
Stay lean by default. Go deep only where the question demands it. See how many contributors share that same map below.
Humans and agents contribute in parallel. Governance sits between written and landed — so concurrent writes don't step on each other, and nothing silently overwrites previous work.
flowchart LR
subgraph contributors["Humans & Agents"]
direction TB
H1["Alice"]
H2["Bob"]
A1["Agent A"]
A2["Agent B"]
A3["Agent C"]
end
H1 --> GOV{Governance}
H2 --> GOV
A1 --> GOV
A2 --> GOV
A3 --> GOV
GOV --> KB[("Knowledge Base")]
KB -.->|read| contributors
style contributors fill:#181b24,stroke:#6c8aff,color:#e2e4ea
style H1 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style H2 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style A1 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style A2 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style A3 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style GOV fill:#242836,stroke:#f0a77b,color:#e2e4ea
style KB fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
Every contribution accrues. Nothing silently overwrites. Nothing gets lost. See how governance decides what lands below.
Four tiers decide what happens between an agent submits a change and the team sees it. Humans stay in the loop for the stuff that matters — and out of the way for everything else.
flowchart TD
WRITE[/"Agent writes to KB"/] --> DECIDE{What kind of change?}
DECIDE -->|New, additive| T1[Tier 1: Auto-approve]
DECIDE -->|Minor, uncontested| T2[Tier 2: Auto-merge]
DECIDE -->|Conflicting| T3[Tier 3: AI review]
DECIDE -->|Destructive| T4[Tier 4: Human approval]
T3 -->|resolves| T1
T3 -->|escalates| T4
style WRITE fill:#242836,stroke:#2e3344,color:#e2e4ea
style DECIDE fill:#242836,stroke:#6c8aff,color:#e2e4ea
style T1 fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
style T2 fill:#1a2340,stroke:#6c8aff,color:#6c8aff
style T3 fill:#3d2a1a,stroke:#f0a77b,color:#f0a77b
style T4 fill:#3d1a1a,stroke:#f07b7b,color:#f07b7b
Most writes flow through auto-approve and auto-merge. AI review only engages when it sees a conflict. Humans only get paged for the truly destructive or truly ambiguous.
Brilliant uses a Google-Workspace-style sharing model. Each user starts with their own private knowledge. Content is shared explicitly. Agents inherit the permissions of whoever invoked them.
flowchart LR
USER["User / their Agent"] --> KB[("Knowledge Base Entry")]
KB --> RW["Read + Write
(edit, contribute)"]
KB --> RO["Read Only
(reference, query)"]
KB --> NONE["No Access
(invisible to search)"]
style USER fill:#242836,stroke:#6c8aff,color:#e2e4ea
style KB fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
style RW fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
style RO fill:#1a2340,stroke:#6c8aff,color:#6c8aff
style NONE fill:#3d1a1a,stroke:#f07b7b,color:#f07b7b
flowchart LR
subgraph scenarioA["Editor invokes agent"]
direction LR
H1["Human (Editor)"] -->|invokes| A1[Agent]
A1 -->|inherits| P1[Read + Write]
end
subgraph scenarioB["Viewer invokes agent"]
direction LR
H2["Human (Viewer)"] -->|invokes| A2[Agent]
A2 -->|inherits| P2[Read Only]
end
style scenarioA fill:#181b24,stroke:#6bdfb8,color:#e2e4ea
style scenarioB fill:#181b24,stroke:#f0a77b,color:#e2e4ea
style H1 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style A1 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style P1 fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
style H2 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style A2 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style P2 fill:#3d2a1a,stroke:#f0a77b,color:#f0a77b
The CEO's Q3 restructuring notes don't leak to new hires. Financials stay scoped. Mission statement goes read-only to the whole org. You set the rules, not the tool.
Wiki links say these two things are connected. Typed links say how they're connected — so agents can query the graph, not just walk it.
graph LR
W_A[Entry A] -->|links to| W_B[Entry B]
W_A -->|links to| W_C[Entry C]
W_A -->|links to| W_D[Entry D]
style W_A fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style W_B fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style W_C fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style W_D fill:#242836,stroke:#9ba1b0,color:#e2e4ea
graph LR
C_A[Entry A] -->|supersedes| C_B[Entry B]
C_A -->|related_to| C_C[Entry C]
C_A -->|deprecated_by| C_D[Entry D]
style C_A fill:#242836,stroke:#6c8aff,color:#e2e4ea
style C_B fill:#242836,stroke:#6bdfb8,color:#e2e4ea
style C_C fill:#242836,stroke:#6bdfb8,color:#e2e4ea
style C_D fill:#242836,stroke:#6bdfb8,color:#e2e4ea
Ask "what supersedes the old onboarding policy?" and the graph answers directly — no full-text scan required.
Connect the way that fits how your team already works — no platform lock-in.
flowchart LR
API["REST API\nScripts, apps, automation"] --> CORTEX[("Your Brilliant Knowledge Base")]
MCP["MCP Server\nClaude Co-work, Claude Code"] --> CORTEX
CLI_node["CLI\nTerminal, shell scripts"] --> CORTEX
style CORTEX fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
style API fill:#242836,stroke:#6bdfb8,color:#6bdfb8
style MCP fill:#242836,stroke:#6bdfb8,color:#6bdfb8
style CLI_node fill:#242836,stroke:#6bdfb8,color:#6bdfb8
Best for existing apps, automations, background jobs. The primary integration path — token-efficient and fully typed.
Best for Claude Code and Claude Co-work. Plug Brilliant straight into your agent. Works on personal accounts too.
Best for operators and power users. Shell-first. Under the hood, it calls the same REST API.
Raw MCP tools are powerful but low-level. The knowledge-base skill — shipped for Claude Code and Claude Co-work — turns Brilliant into something closer to a working memory. It initializes context, routes content to the right place, preserves corrections as permanent conventions, and compresses sessions so the next one resumes cleanly.
flowchart TB
USER["You"] <--> AGENT["Claude Code / Claude Co-work"]
AGENT <--> SKILL["knowledge-base skill
session init · routing · auto-save · teaching loop · compress/resume"]
SKILL <--> MCP["MCP tools
session_init · search · get_index · create/update · staging"]
MCP <--> KB[("Brilliant Knowledge Base")]
style USER fill:#242836,stroke:#6c8aff,color:#e2e4ea
style AGENT fill:#242836,stroke:#6c8aff,color:#e2e4ea
style SKILL fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
style MCP fill:#242836,stroke:#6bdfb8,color:#e2e4ea
style KB fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
When you correct the agent, the correction is saved as a permanent convention under System/Rules/. No repeating yourself across sessions.
Every session opens with a briefing from the last one and closes with a compressed log — decisions, learnings, pending items — so nothing gets dropped between conversations.
The skill knows where decisions, meetings, projects, and daily notes belong. It files them automatically, links related entries, and never asks permission to preserve what matters.
The MCP tools are the API. The skill is the operating system.
Brilliant grows with you — from a personal pool, to a team, to an organization with real permission structure. Same system at every stage.
flowchart LR
H[You] --> A[Your Agent]
A --> KB[("Knowledge Base")]
KB --> A
A --> H
style H fill:#242836,stroke:#6c8aff,color:#e2e4ea
style A fill:#242836,stroke:#6c8aff,color:#e2e4ea
style KB fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
flowchart LR
H1[You] --> A1[Your Agent] --> KB[("Shared Knowledge Base")]
KB --> A1
A1 --> H1
H2[Your Team] --> A2[Their Agents] --> KB
KB --> A2
A2 --> H2
style H1 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style H2 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style A1 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style A2 fill:#242836,stroke:#6c8aff,color:#e2e4ea
style KB fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
flowchart LR
LEAD[Leadership] --> KB
MGR[Managers] --> KB
STAFF[Staff] -.->|scoped| KB
KB[("Org Knowledge Base + Permissions")]
KB -->|full| LEAD
KB -->|scoped| MGR
KB -->|filtered| STAFF
style LEAD fill:#242836,stroke:#6c8aff,color:#e2e4ea
style MGR fill:#242836,stroke:#6c8aff,color:#e2e4ea
style STAFF fill:#242836,stroke:#9ba1b0,color:#e2e4ea
style KB fill:#1a3d2e,stroke:#6bdfb8,color:#6bdfb8
Same system at every stage. No migration when your team doubles.
Second-brain tools like Obsidian are built for one person's notes. Brilliant is built for a team of people and agents writing together — with governance so nothing silently overwrites.
Five commands. Local Docker. A working knowledge base with governance, ready to go.
git clone https://github.com/thejeremyhodge/xireactor-brilliant.git
cd xireactor-brilliant
cp .env.sample .env
docker compose up -d
bash tests/demo_e2e.shThe end-to-end test creates entries, stages writes, runs governance, and validates the full pipeline. See the README for detailed setup.
The context layer for your team should be something you own, not something you rent. Star the repo, file issues, send PRs.
Questions, requests, or thinking about Brilliant for your team? Send a note.
Prefer LinkedIn? Connect with me on LinkedIn