Mindbase
An R&D project exploring the missing layer between company knowledge and AI automation: extracting how a company actually works from its scattered data, and turning it into decision logic AI agents can act on — with humans approving every rule.
Overview
Mindbase is my answer to a problem the whole industry is circling in 2026: AI agents are geniuses with amnesia. Frontier models are capable enough to do real work, but they have no idea how a *specific* company operates — who approves refunds, how incidents get resolved, why a system was built the way it was. So companies buy AI tools and still can't automate anything.
Mindbase is a system that ingests a company's scattered knowledge — chat, tickets, code, docs — extracts the repeated decision logic hiding inside it, routes every extracted rule through human review, and serves the approved logic to AI agents so they can actually do the work the way that company does it.
It's currently in deep research and development: the problem space is mapped, the architecture is designed, and the plan has been stress-tested. Building comes next.
Status: research & development. Nothing here is launched yet — this page documents the thesis, the research behind it, and where the build is heading. Numbers below are research outputs, not product metrics.
The Problem
The idea responds to a gap Y Combinator recently named in a Request for Startups: the blocker to AI automation is no longer model capability — it's domain knowledge. Every company's critical know-how is scattered across people's heads, Slack threads, support tickets, and old email. The company functions because humans vaguely remember where that knowledge lives.
Existing tools don't close the gap, because they all stop at the same place: retrieval. A knowledge base answers a question to a *person*, who then decides and acts. An agent needs something different — the conditional logic itself (*if the order is over 30 days, the lead approves, unless it's an enterprise account with an open incident*) so it can take the action. Retrieval ends at an answer; execution ends at a completed task. That distinction is the entire project.
“…like replacing 90% of your employees with a team of geniuses who have no idea how your company operates.”
The Design Principles
Execution over retrieval
The output isn't a document a human reads — it's versioned decision logic an agent can query and act on.
Provenance on everything
Every extracted rule carries verified citations to the exact sources it came from. No citation, no rule.
Human-approved, always
Nothing becomes executable until a designated owner reviews and approves it — review embedded in workflows people already do, not a standalone chore.
Confidence earned, not assigned
Every use is outcome-tracked, so trust in a rule is a statistic that grows with usage — never a launch-day number.
Audit-first
AI-drafted, human-approved, fully audited. Every agent action logs which rule, on what evidence, with what result.
How It Works — Two Loops
Connect
Server-side connectors ingest the company's high-signal sources — resolved tickets, postmortems, docs, code — with chat as a secondary source for exceptions.
Extract
An LLM pipeline detects repeated decision patterns and drafts structured rules, each with verified citations and a tracked lineage.
Review
The designated owner for each domain approves, edits, or rejects — inside rituals like postmortems and PR review.
Serve
Approved logic is exposed over MCP and a typed API, so any agent can query it and act — at draft/assist tier first.
Stay current
Batch re-extraction proposes versioned updates when reality diverges from a stored rule, keeping the brain alive instead of rotting like a wiki.
The Research: Where 14 Knowledge Tools Stop
My audit of 14 knowledge, search, and process-documentation tools against a strict test: does it output executable process logic an AI agent can act on without a human in the loop? Every tool passes ingestion; none pass the execution test. That unbuilt middle — extraction and structuring — is where Mindbase aims.
The Landscape
| Category | Examples | Where it stops |
|---|---|---|
| Knowledge bases | Notion AI, Confluence, Guru | Stores information, not process — answers humans, no executable representation |
| Enterprise search | Glean, Bloomfire | Best-in-class retrieval, but retrieval is not execution |
| Process documentation | Scribe, Tango, Loom | Human-readable guides that drift; not machine-executable |
| Personal AI memory | Mem, Rewind | Individual recall; no shared, executable organizational layer |
| Mindbase (R&D) | — | Targets the unbuilt middle: extraction → executable, human-approved logic |
Stress-Testing the Idea
Before writing code, I ran the full concept through an adversarial review: a four-model LLM council (GPT-5.1, Gemini 3 Pro, Claude Sonnet, Grok 4) answering independently, blind-ranking each other, with a chairman model synthesizing the verdict — explicitly instructed to find flaws, not encouragement.
The council confirmed the core insight (execution over retrieval, provenance-tagged logic) is sound — and then correctly attacked the hard parts: extraction from raw chat is unreliable because the real reasons behind decisions often never make it into the text; standalone review queues decay like every wiki before them; organizations don't have one canonical truth, they have competing informal processes; and autonomy for consequential actions is capped by liability long before model quality.
Every one of those findings changed the design — extraction now leads with high-signal resolved artifacts, review is embedded in existing rituals, each domain gets a designated truth-owner, and the year-one posture is drafts-with-audit-trail rather than autonomy.
The open risk, stated plainly: reliably extracting correct decision logic from messy company data is the make-or-break bet. The build plan gates on proving extraction accuracy on one narrow process with a human-audited gold set before anything else gets built on top.
Planned Stack
Extraction pipeline — LLM orchestration, clustering, citation verification
Rule store, metadata, and semantic search in one boring, reliable system
The serving interface — any agent queries approved logic through one standard
Review console and web surface
R&D Timeline
2026-06
Problem Research
Mapped the YC 'Company Brain' problem space; audited 14 existing tools against the execution test; identified the unbuilt extraction-and-structuring gap.
2026-06
Product & Architecture Design
Defined the two-loop workflow, the provenance-first extraction pipeline, and the review/trust model. Named and branded the project.
2026-07
Adversarial Review
Four-model LLM council stress-test; eight concrete design improvements adopted, four new risks added to the register.
2026-07+
Next: Prove Extraction
Build the extraction prototype for one narrow process and benchmark accuracy against a human-audited gold set — the go/no-go gate for everything after.
What the Research Taught Me
The biggest lesson so far: the obvious architecture is the easy part. Once you read the problem carefully, ingestion, graphs, and MCP serving design themselves — which is exactly why multiple teams are converging on the same shape. The defensible work is the unglamorous middle: making extraction trustworthy, making review something humans actually keep doing, and earning autonomy one audited rule at a time.
Second lesson: inviting brutal criticism early is cheap; discovering the same flaws after six months of building is not. The council review reshaped the plan more in one evening than weeks of solo iteration — and the honest risk register it produced is now the most valuable document in the project.