Your team wants a company brain. The first real decision is whether to build one or buy one.

Building a company brain looks easy. A Markdown repo, a few MCP connectors and a good model will get you a great demo in a weekend. The hard part comes later: permissions, docs that quietly go stale, and someone who has to own the upkeep.

Gorgias knows this firsthand. Their custom build took a team of four about a month, after a year of testing another tool. Keeping it accurate and getting people to use it is now close to a full-time job for one engineer.

Buying skips the build, but you give up some control, like being able to read every agent trace.

So we put both options side by side.

Yochan Khoi, Staff Context Engineer at Gorgias, walked through Cortex, the company brain Gorgias built in-house.

Slite CEO Chris Pasquier showed the same thing with Slite, the off-the-shelf option.

Both follow the same three parts: structure, retrieval and maintenance. Then the person who actually built one gave a straight answer on who should build, and who shouldn't.

0:00 Welcome and introductions

Chris and Yochan both joined from Paris, while attendees checked in from São Paulo to Oslo to Portland. Yochan has been at Gorgias for three years and built the Gorgias company brain. Chris met Yochan about two months earlier while researching for the Company Brain ebook, and came away impressed by how far Gorgias had taken it.

2:14 What to expect

The session had four parts: a short recap of the research to agree on what a company brain is, a demo of each platform, a conversation about build vs. buy, and audience Q&A. As Chris put it, it wasn't a sales call. The goal was to show the components of a company brain in two different systems, and how close they turned out to be.

3:03 From second brains to company brains

Before AI, the popular metaphor was the second brain: a big pile of connected documents for productivity power users. Chris said he never found anyone getting real value from one.

That changed as coding agents got good at orchestrating search across large repositories of data.

Context graphs became a hot topic, Andrej Karpathy described LLM-generated knowledge bases, and Garry Tan's G-Brain showed that a well-structured Markdown repository plus your Slack messages and meeting notes could power an assistant that answers almost anything.

Y Combinator went on to list the category in its Requests for Startups.

6:37 What teams expect from a company brain

When Slite asked people what they expected, the answers varied wildly: search, wiki, context graph, ontology, memory. A few patterns stood out:

  • 71% expected a knowledge base that updates on its own: still a repository of information, but with self-maintenance around it.
  • Most teams were trying to build one themselves. The ones who managed were usually very small teams, where privacy doesn't matter, data volumes are small and simple search is enough.
  • The biggest concerns were accuracy of answers, privacy and permissions, the cost of maintenance, and token usage.
  • The surprise: only a minority wanted a company brain mainly to give context to agents. Most wanted universal context that every teammate can access. When agents came up, they were usually agents used by a person.

8:56 Why documents alone aren't enough

Chris shared Slite's own data on docs created year over year. As Slite's AI search matured, from 2023 to its connected, agentic version in 2025, the team needed to produce fewer new documents.

With a universal entry point to knowledge, people stop re-writing reports and re-sharing the same information.

People expect a company brain to be a self-maintaining set of documents, but a set of documents isn't a company brain on its own. It needs the agentic layer on top, connected to the rest of your work.

10:15 Structure, retrieval, maintenance

After reviewing dozens of solutions and talking to builders and users, Slite simplified a company brain into three components:

  • Structure: capturing knowledge from meetings, Slack, teammates and live connections to your codebase or SQL database, then organizing it and understanding how pieces relate.
  • Retrieval: finding the right context. Chris called this a solved problem if you have the right technology, but there's no silver bullet: you need semantic search, runtime access, codebase connections and an orchestrator that makes them work together.
  • Maintenance: a way to keep all of it accurate over time.

12:30 Inside Gorgias's Cortex

Cortex is the platform Gorgias runs its internal AI on. It has two sides: Cortex, the agent side (projects, artifacts, automations, personal skills, knowledge and connectors, and a simple way to create agents), and the context hub, which was the focus of the demo.

Note: For privacy, Yochan recorded the demo on fake data and talked through it.

13:55 The context hub: skills, knowledge, metrics and tables

Gorgias's context is made of four types of objects:

  • Skills, organized in folders by department. Each skill has a description and "target requests": example questions the skill should be retrieved for. With 300 to 400 skills, you can't fit them all in a system prompt. A built-in agent helps you write a skill and test it in a conversation.
  • Knowledge pages, in a Notion-like tree by department. Every page has a title, a description, an owner, and can reference skills, metrics, tables or other pages.
  • Metrics. Gorgias doesn't use a semantic layer. Instead, each metric is example SQL with rich metadata: business questions, aliases, seasonality, causal dimensions and an investigation path. The SQL has to compile before it can be saved.
  • Tables, which stay in dbt but are surfaced in Cortex. A toggle decides whether a table is exposed to agents, and "when to use" and "how to use" fields explain it the way you would to a fellow analytics engineer.

19:23 Retrieval: skills first, then the knowledge graph

All these objects compile into a graph. When a question comes in, Cortex first runs a BM25 search over skill titles and descriptions to pick the top 10, and the agent decides whether one fits.

If not, it starts at the top-level department pages and walks the graph node by node, using progressive disclosure: it only sees titles and descriptions and decides where to drill down.

That's why good descriptions matter so much.

22:43 Maintenance: change requests and ownership

Anyone can request a change on a piece of text or a whole folder. That creates a request card showing the files changed, a diff, and the owners who need to approve before it goes live.

Ownership matters: if an answer is wrong, you know who to ask. Yochan contrasted this with personal setups like G-Brain, where you can't be sure what has been appended.

Because most people won't file requests themselves, Cortex also works on its own: it detects knowledge gaps in conversations and drafts change requests, and automations watch GitHub, Linear and Slack to propose updates. Owners just approve.

26:00 Cortex Q&A

26:06 How did you seed the knowledge base?

How did you seed the original knowledge base? Where did you start as raw material?

Gorgias started more than three years ago, manually. Yochan sat down with each department and asked them to write down everything they'd tell a new joiner they weren't allowed to talk to for a week.

The structure of the pages mirrors how each department actually works, because controlling how knowledge is written improves retrieval accuracy more than any chunking strategy.

Rather than importing old, unapproved content from their knowledge platforms and repos, the team started clean and went deeper department by department.

Once the base structure exists, iterating with an agent is easy.

29:20 How did you build the graph, and do you run evals?

How did you build the graph, how do you update it, and do you run evals when it changes?

Yochan used an open-source package similar to Obsidian's backend, which compiles the links between pages into a graph.

At Gorgias's size you don't need a graph database: a JSON object that looks like a graph is enough. Evals don't run on every minor change.

30:38 Inside Slite's company brain

Chris followed the same structure, retrieval, maintenance pattern. Where Cortex is custom-built for one company, Slite is built to work for any team, which means more decisions about what not to do.

31:08 Structure: starting from documents

Slite started the other way around from Gorgias: from a document layer that already handled permissions, infinite nesting and built-in verification, so agents know what's trustworthy and maintained.

Agents can collaborate on it through MCP.

32:13 Retrieval across every source

Slite then connected everything else: semantic search over replicated data from tools like Slack and GitHub with permissions respected, the codebase browsed by an agent rather than indexed, BigQuery for structured data, and custom MCP sources.

Chris showed questions answered across these sources, from how a pricing plan evolved year over year to a breakdown of signup roles pulled from BigQuery and charted.

35:51 Maintenance programs

Accurate context is the hard part. Slite's agent-powered maintenance programs let you pick a channel or set of docs, a frequency, the people in charge, and the sources to fact-check against, or write a custom routine, such as keeping an org chart of who works on what up to date.

Suggested changes land in a change request, the equivalent of a GitHub pull request for your knowledge.

In the demo, a pull request merged five days earlier had been flagged automatically, with the Help Center update ready to approve.

39:24 The Help Center audit

Chris also showed a routine that reads an entire help center and flags contradictions, such as docs still referring to the old Premium plan, or two docs disagreeing about whether an integration needs to be set up. It's the easiest way to start cleaning a knowledge base, and a way to make the case for maintenance to your team.

41:37 Build vs. buy: what should you actually do?

Once Gorgias knew exactly what it wanted, after about a year of iterating on another tool, building Cortex fully custom took a team of four around three to four weeks.

Today about half of Yochan's time goes to new features and changes, and most of the rest to education: helping people use it well.

Yochan's advice was clear:

  • If you've never built agentic systems or deployed internal apps, or you're a small company, don't build. It isn't worth it, and there are tools like Slite and open-source options.
  • If you're a larger company with the technical people with context-design experience, it can be worth trying. For Gorgias it was a win-win: the company sells AI agents to customers, so what the team learns on Cortex feeds the product.

44:03 Traces, permissions and governance

Chris pointed out an advantage of building for yourself: Gorgias can use agent traces, the log of everything that happens between a question and an answer, to spot what's inaccurate or missing.

A product like Slite can't expose those to workspace admins, because answers may draw on private channels, docs and transcripts.

Yochan agreed that governance, who and which agent can access what, was the hardest part to get right.

46:35 Audience Q&A

46:40 Restricting what agents can access

How do you restrict certain agents from accessing specific parts of the knowledge base, for example keeping customer-facing agents away from financial data?

Chris called it one of the many layers you need for a company brain that works at the scale of a real company.

Slite replicates each source's permissions as closely as possible, for example using your email to know which BigQuery datasets you can access.

Some sources need compromises, such as admin-defined groups.

It's also where prototypes and company-wide systems differ most, along with maintenance: without a cleanup layer, one bad transcript gets indexed and stays there.

Yochan added that building a brain for yourself is easy; making it company-wide is hard, but it compounds, because one person's work benefits everyone.

49:25 Handling raw sources like sales calls

How would you handle raw sources like recorded sales calls that need processing before they enter the company brain?

Process the data before handing it to an agent. At Gorgias, tables are cleaned dbt models, not raw data, and some tables are multiple terabytes, so modeling data for agents matters.

Chris added a lesson from meeting-notes tools: raw transcripts are too unstructured to index or chunk well.

A first, cheap LLM pass to summarize them goes a long way.

51:42 Is this too technical? Use cases for business teams

The talk seems primarily tech. What are the use cases for a Growth Head at a B2B SaaS company?

Chris acknowledged the bias of two developers talking build vs. buy.

In practice, most company brain usage at Slite's customers comes from support, CX, sales and customer success.

Developers use it least, because the truth for them already lives in the code.

Yochan saw exactly the same at Gorgias: business teams hold the most knowledge that isn't written down anywhere.

Both agreed that tooling is only the first step. The bigger work is enablement and ownership.

Chris shared that when Slite added an agent button inside tools like Intercom through its browser extension, usage exploded.

Yochan described how Gorgias splits ownership: data analysts own metrics, analytics engineers own tables, and each department owns its knowledge, pushed both bottom-up by the teams building the tooling and top-down by leadership.

55:59 What should be visible, and what can stay hidden?

When should knowledge live as structured, editable entities in a UI, and when only in a queryable knowledge graph used by AI? Where's the source of truth?

Chris's view: some data and tribal knowledge can stay hidden, as long as the orchestrator finds it and evals check it.

The document layer should stay visible, maintained by the experts in charge of it, because that's where you anchor the truth. That's why Slite's goal is for almost every doc to be verified and under maintenance.

Yochan added that Cortex's context hub doesn't copy information that lives elsewhere. It acts as a router: it points to the table, GitHub page or Notion doc where the data lives, and explains how to use it.

58:57 Wrap-up

Yochan invited anyone curious about how Gorgias implemented Cortex to reach out on LinkedIn.

Want to see how Slite keeps a company brain accurate on your own knowledge? Talk to our team, or start with an audit of your help center to see what conflicting information already lives in your public docs.