Your agent just told a founder that revenue grew 14% last month. It is wrong. Not because the model is weak, and not because the SQL is malformed. It is wrong because your orders table has both created_at and paid_at, and only one of them means revenue. Nobody wrote that down. It lives in the head of the engineer who built the billing flow in 2023.
That single fact is what people now mean when they talk about a company brain. Models got good fast. The bottleneck moved. What agents lack is not intelligence, it is the accumulated, unwritten knowledge of how your specific company works.
This guide covers what a company brain actually is, why documents make a poor one, and what it takes to build one that agents can trust.
TL;DR
| Question | Short answer |
|---|---|
| What is it? | A living, current map of how your company works, structured so AI agents can use it |
| Who named it? | Tom Blomfield, in YC's Summer 2026 Requests for Startups |
| What it is not | Company-wide search, a chatbot over your wiki, or RAG across Notion |
| What it holds | Connected sources, metric definitions, data quirks, and executable procedures |
| Why now? | Models stopped being the constraint. Missing business context became the constraint |
| The big split | Brains built on documents go stale. Brains built on systems of record cannot |
| Where to start | The systems that already run your business, not the docs describing them |
What a company brain actually is
The term got its definition in April 2026, when Tom Blomfield wrote the Company Brain entry in Y Combinator's Requests for Startups. He is a YC general partner and previously co-founded Monzo. His framing was specific:
A system that pulls knowledge out of all these fragmented sources, structures it, keeps it current, and turns it into an executable skills file for AI. This isn't a company-wide search or a chatbot over documents. It's a living map of how a company works.
Two clauses in there do the heavy lifting. The first rules out search. The second rules out documents. What is left is a much harder and more useful thing.
Break the definition into requirements and you get four:
| Requirement | What it means in practice |
|---|---|
| Pulls from fragmented sources | Reads across your database, warehouse, billing, CRM, analytics, and ad platforms |
| Structures it | Turns scattered facts into typed, retrievable knowledge, not a pile of text |
| Keeps it current | Reflects the business as it is today, without anyone maintaining it by hand |
| Makes it executable | Hands agents procedures they can run, not passages they have to interpret |
Most tools that claim the label satisfy the first two. The last two are where they separate.
Why documents make a bad brain
Almost every company brain being built right now ingests the same set of sources. Docs, Slack threads, email, meeting transcripts, tickets. There is a reason for that. It is where humans leave traces, and it is easy to index.
It is also where knowledge goes to rot. Every one of those artifacts is a snapshot of what somebody believed on the day they typed it. Nothing updates them when reality moves.
Consider how fast each source decays:
| Knowledge source | Updates when reality changes? | Typical staleness |
|---|---|---|
| Notion page on pricing tiers | Only if someone remembers | Months |
| Slack thread agreeing on a metric | Never. It gets superseded silently | Weeks to years |
| Onboarding doc for the data model | Only during onboarding rewrites | Quarters |
| Your production database schema | Continuously. It is the business | Zero |
| Stripe | Continuously. It is the revenue | Zero |
The bottom two rows are the point. Stripe is not a description of your revenue. It is your revenue. Your warehouse is not a summary of the funnel, it is the funnel. A brain built on those cannot drift, because there is nothing to drift from.
This is also why dashboards keep losing to agents. A dashboard is another artifact that encodes an assumption and then quietly ages.
The knowledge that breaks agents is not in your documents
Here is the uncomfortable part. Even a perfectly current document set would not fix the revenue answer from the top of this article.
The created_at versus paid_at distinction was never in a document. It was never in a Slack thread. It is a property of the schema plus a convention the team adopted without discussing. That combination is exactly what an agent cannot infer and a document scraper cannot find.
We wrote about this at length in why business context is harder than connectors. The connector takes an afternoon. The context takes weeks, because it has to be discovered through use.
Real examples from real Sequel deployments look like this:
- Revenue uses
paid_at, notcreated_at. Filtering on the wrong one inflates growth. customer_subscriptions.deleted_atis a soft delete. Missing it double-counts churned accounts.- Refunds require
status NOT IN ('refunded', 'chargeback'). Checking only forrefundedundercounts losses. - Marketing counts an active user weekly. Product counts monthly. Both call it "active".
None of these are exotic. Every company has forty of them. Each one silently produces a plausible, wrong number, which is the worst possible failure mode. We covered a specific version of this in why GA4 through MCP returns the wrong numbers.
What a company brain is made of
Strip away the marketing and a working company brain has four layers. Each answers a different question an agent has.
| Layer | Answers | Without it |
|---|---|---|
| Connected sources | Where does the data live? | The agent asks you to paste a CSV |
| Learned semantics | What do these columns mean here? | Confident, wrong numbers |
| Executable skills | How does this company do this task? | The agent improvises a different method each time |
| Governance | Who ran what, against which system? | No audit trail, and credentials in chat logs |
That third layer is Blomfield's "executable skills file", and it is the one most teams skip. A skill is not documentation of a process. It is the process, written so an agent can follow it: which tools to call, in what order, with which filters. Sequel ships these as agent skills, covering things like channel attribution and subscription revenue health.
The fourth layer matters more than it sounds. A brain that reads your production systems needs to do so without handing keys to a model. Sequel connects with read-only credentials, holds every secret in a gateway the agent never sees, and logs each call. That is the practical version of the MCP security and governance argument.
Two kinds of company brain are being built
The category has split, and it is worth knowing which side a tool sits on before you buy.
| Document brains | Systems-of-record brains | |
|---|---|---|
| Sources | Docs, Slack, email, transcripts, tickets | Databases, warehouses, billing, CRM, analytics |
| Knows | What people said | What is true right now |
| Answers | "What did we decide about pricing?" | "What did we actually charge last month?" |
| Fails at | Any question whose answer is a number | Any question whose answer is a conversation |
| Freshness | Decays from the moment of writing | Cannot decay |
Both are real, and a large company will eventually want both. But only one of them can answer the question that ends most meetings, which is some version of "what is the number, and is it right?"
Sequel is deliberately the second kind. It does not index your documents. It connects the systems those documents are usually wrong about.
How Sequel builds one
The mechanics are less exotic than the framing. Three steps.
Connect the sources. Postgres, MySQL, BigQuery, Snowflake, ClickHouse, Redshift, MongoDB, plus Stripe, HubSpot, GA4, Google Ads, Meta Ads, Mixpanel, Amplitude, PostHog, Intercom, Search Console, and Sheets. Sequel is cloud-first, so managed instances like RDS, Supabase, and Neon connect directly. See the full source list.
Let it learn. Sequel maps your schema on connection. From there it accumulates the conventions your team uses, scoped to the organization, a specific source, or one person. When an agent hits a data quirk and works out the fix, it writes that lesson back, so the next question starts from the correction rather than repeating the mistake.
Give every agent the same brain. Sequel exposes all of it over MCP, so Claude Code, Cursor, ChatGPT, and Claude Desktop each answer from identical definitions. You teach the company once. Every agent inherits it. That is the difference between a brain and a context window, which resets the moment the chat ends.
The result is that the question "what was our blended CAC last month" joins ad spend, product signups, and billing without an ETL job standing between the question and the answer. We wrote about that pattern in connecting marketing data to AI.
How to evaluate one
If you are assessing tools in this category, five questions separate them quickly.
- Can it produce a number? If it can only retrieve text, it is a search product wearing a new label.
- What happens when the schema changes? A brain that needs manual re-documentation is a wiki with embeddings.
- Where do metric definitions live? If the answer is "in the prompt", they will not survive the week.
- Does the agent ever hold a credential? It should not. Ever.
- Can you see what it ran? Every answer should show its query. Auditability is not optional once agents touch production.
Start with what cannot go stale
The instinct when building a company brain is to start with the wiki, because that is where knowledge feels like it lives. It is the wrong starting point. The wiki is where knowledge went to be forgotten.
Start instead with the systems that cannot lie about the present, then teach the brain the handful of conventions that make those systems legible. That is a smaller job than it sounds, and it is the part that compounds. Get started free and connect your first source, or talk to us about what your team keeps getting wrong numbers on.