How to build a company brain, one workflow at a time
A company brain gives people and AI agents the same context. Start with the one workflow where your team re-explains the most, then grow from there.
Ask Claude Code how your team names database migrations and it will guess. Open a new session tomorrow and it will guess again.
People paste the answer in instead. A paragraph about conventions, a link to the architecture doc, a note about the service nobody should touch. Every session, on every laptop, slightly differently each time.
People have the same problem without AI. In a survey of 12,000 knowledge workers and 200 executives, leaders and teams said they lose 25% of their time searching for answers.
A company brain fixes this one workflow at a time, and it fails when you try to load the whole company on day one.
What a company brain is
A company brain is a shared memory layer that people and AI agents both read from. It holds how your company actually works: conventions, decisions, customer history, who owns what. Every chat and every agent starts from that context instead of from zero.
It differs from a wiki in 2 ways. It stays current as work happens, and agents can query it directly instead of waiting for someone to paste a page in.
"Why not connect everything and let the AI sort it out?"
It's tempting. Most memory tools will index a whole drive, a Slack workspace, and every repo in an afternoon.
The trouble is that a company's archive disagrees with itself. The 2023 onboarding doc says one thing, a Slack thread from March says another, and the code does a third. An agent that retrieves all 3 will pick whichever reads closest to the question, which is not the same as whichever is true.
Starting with one workflow keeps the sources small enough that someone can say which one wins. It also gives you a way to tell whether the thing works.
Step 1: Pick the workflow where context gets lost most
Look for work where people keep rebuilding the same background before they can start. A few common ones:
- Code review. Reviewers explain the same conventions on every pull request, and agents write code that ignores them.
- Customer support. Each agent, human or AI, pieces together a customer's history from tickets, the CRM, and old email threads.
- Onboarding. New hires ask the same questions for months, and the answers live in a few senior people's heads.
Pick the one where the repetition is easiest to see and most expensive.
Your AI sessions already show you where it is
If your team uses AI tools every day, the repetition is sitting in the sessions. Several people doing the same kind of task. Long sessions that spend their first stretch rebuilding context. The same instructions pasted into the start of every conversation.
Tokenize groups your team's AI sessions into workflows, shows who does each kind of work and what it costs, and flags when several people are doing similar work. Its savings recommendations point out repeated work that a skill could take over and sessions that rebuild context every turn.
Start where the same context gets rebuilt most often, by the most people.
Step 2: Put in only what that workflow needs
For code review, that might be the style guide, active architecture docs, decision records, and recent pull request history. It isn't the whole engineering drive.
| Put in | Leave out |
|---|---|
| Current conventions and style guides | Docs nobody has touched in a year |
| Decision records, with dates | Brainstorm threads that never reached a decision |
| Architecture docs for live systems | Docs for systems you've retired |
| Recent pull requests and their review comments | Every Slack message that mentions the repo |
An example scope for a code review brain. Your list will differ; the test is whether a senior reviewer would point a new hire to it.
Vet it before it goes in
Give new material a holding area and a named owner who approves it. One common setup is a folder per domain (Security, Legal, Product) with a staging area for new files and an approved area for trusted ones. Agents only read from the approved side.
Bad inputs can't be fixed downstream. A wrong fact in the brain gets repeated with confidence by every agent that reads it.
Link to live documents
Copying a doc's text into the brain gives you a snapshot that starts going stale the next day. Sync from the source, so when someone updates the style guide, the brain changes with it.
When two sources disagree, decide which wins and write that down. For decisions, a merged pull request description might outrank a Slack thread. Make the rule explicit so the agent doesn't have to guess.
Step 3: Choose where the memory lives
There are 3 reasonable places to keep it, and the right one depends mostly on team size.
| Option | Good for | Watch out for |
|---|---|---|
| A folder of Markdown files in a repo or shared drive | A small team or one department starting out | Someone has to keep it tidy; access follows folder permissions |
| A model provider's built-in project memory | A team that works mostly in one AI tool | Doesn't carry over to other tools or agents |
| A dedicated memory platform | Many teams and agents sharing context | Another system to buy, secure, and run |
Most teams outgrow the first option before the third is worth it.
A plain folder goes further than people expect. Start with an empty structure and add context only when a real task needs it.
Whatever you pick, avoid a wiki that only changes when someone remembers to edit it. The brain has to update as tickets close, pull requests merge, and decisions get made.
Step 4: Connect your agents to it
Point every tool at the same source
Claude Code, a Slack bot, and an internal support agent should all read from one brain. If each tool keeps its own memory, you're back to 3 versions of the truth.
For coding agents, some of the brain can ship as skills: files that teach the tool how your team does a task, like reviewing a diff. Tokenize can send managed skills to Claude Code and Codex on your team's devices, scoped to the teams that need them, and shows which skills people actually use.
Enforce permissions in the storage, not the prompt
A sales agent shouldn't read engineering's incident notes, and a support agent shouldn't see payroll. Telling the agent "don't look at HR files" in its instructions is a request. Folder and group permissions are a rule.
Grant access to groups instead of individuals, and check permissions when the agent retrieves something, not only when the file is added.
Write corrections back
When a reviewer tells an agent "we don't do it that way here", that correction should land in the brain, not just in the current chat. Otherwise the next session makes the same mistake.
Some teams keep a running mistakes log that the agent reads before it starts. Others have the agent propose an edit to the source doc for a person to approve. Either way, the brain gets better each time someone fixes it.
How to tell it's working
Measure the workflow you started with, before and after:
- How often people ask the same question
- How long it takes to finish the task, like time from opening a pull request to merging it
- How often an agent's output gets sent back for missing context
- How much of each AI session goes to rebuilding background before the real work starts
If those numbers don't move, the problem is usually what went in. Go back to Step 2 before adding a second workflow.
Expect the first workflow to take the longest, because it sets everything up. The second reuses most of it.
What changes when it works
The senior engineer stops answering the same question in every review. New hires find the answer instead of interrupting someone. And your AI tools stop spending the start of every session relearning what your team decided last quarter.
That last one shows up in the bill as well as in people's time. If you want to see where your team rebuilds the most context today, book a demo and we'll show you on your own data.
Source: Atlassian, State of Teams 2025.