How do you build a company brain for your team's AI agents?

What is a company brain?

Every AI assistant in your company starts from zero. One person spent an hour with ChatGPT working out how a supplier's API handles rate limits; the next person asks Claude the same question tomorrow. A decision made in Tuesday's chat never reaches Thursday's. The knowledge exists, but it is locked in individual conversations, and when someone leaves, it leaves with them.

A company brain fixes that by giving the team's assistants a memory they share. In the design I build, it has three properties:

• Agents write it during the work. When a task ends, the assistant proposes what is worth keeping: a decision, a finding, the current state of a project. Nobody has to stop and document.
• It is shared across people and tools. One person's ChatGPT, another's Claude and a developer's Codex all read and write the same memory.
• Every entry has an author, a date and a status. An agent can tell a decision from a proposal, and a fresh finding from something that was true in March.

The everyday effect: someone asks their assistant whether anything is happening on the new integrations, and gets the answer from a colleague's entry, without messaging the colleague.

Who needs a company brain, and when is ChatGPT memory or Claude Projects enough?

The built-in tools are good, and for many teams they are enough. Use them when:

• one person works with one assistant, and personal memory covers it;
• a team works on one project in one tool, and a shared project with files and instructions covers it;
• the knowledge already exists in documents, and the assistant only needs to search them.

A company brain makes sense when several people work with AI assistants every day, use more than one tool, and produce knowledge that has to outlive the conversation: decisions, the state of work, how internal systems behave. Another strong signal is a specialist who answers the same questions over and over and would rather have colleagues ask the memory instead.

The table compares capabilities, not product quality. Features change fast, so it is dated:

As of October 2026	Whose memory	Who writes it	Across assistants	Where data lives
ChatGPT memory	one person	the assistant, for that person	inside ChatGPT	OpenAI
ChatGPT shared projects (OpenAI)	one project	project members: files, instructions, chats	inside ChatGPT	OpenAI
ChatGPT company knowledge (OpenAI)	existing company apps	people, in Drive, Slack, SharePoint and others	inside ChatGPT, extendable with custom MCP connectors	in the source apps
Claude Projects (Team, Enterprise)	one project	project members	inside Claude	Anthropic
Enterprise search tools	existing documents	people	through their own integrations	vendor or company
Company brain	the company, plus private notes per person	agents during the work, approved by people	ChatGPT, Claude, Codex and any MCP client	the company's server

The rows are not either-or. ChatGPT company knowledge accepts custom MCP connectors, so a company brain can be one of its sources.

What does a company brain look like in a real company?

I run one at a multichannel e-commerce company. Six people from several teams took part in the pilot. Each of them works with their own assistant, some in ChatGPT, some in Claude, and all of them connect to the same memory with their company Google account. Codex connects the same way.

Within the first weeks several people were adding to the shared space on their own: what is being commissioned, how an integration behaves, which approach was agreed. People correct the canonical pages themselves too, for example moving a colleague to the right team on the page about who does what. One specialist plans to load the full knowledge of the product information system, so that colleagues ask the memory instead of asking her.

From the first day of work to all three memory scopes running took nine days. It is a pilot, and I measure the effect the way I describe further down.

How does it work: one MCP connector for ChatGPT, Claude and Codex

Everything goes through one MCP server, which every major assistant can now connect to as a custom connector. Behind it are three memory scopes:

• Private memory. One per person: a short instruction for the assistant, a context file (who I am, what I am working on), a monthly work log and topic notes. Only the owner can read it.
• The shared space. Entries from the whole team plus canonical pages that summarise them, such as who works on what and how the teams are organised.
• Automation knowledge. Descriptions of the company's n8n workflows: what each system does, which services it calls and how. When someone asks their assistant to build a new integration, the assistant can start from how the company already does it instead of researching the API from scratch.

Search works by keyword and by meaning. The index lives on the server and updates on every change, so an entry written a minute ago is already findable. Polish and other inflected languages need one extra rule: agents search by word stems, because a search for "decision" should also find "decided".

The automation knowledge deserves a word on safety, because workflow definitions contain credentials and customer data. Descriptions are generated by a separate process that reads definitions with a read-only database role, runs every node through a scanner for secrets and personal data, and sends the model only the structure: which services, which operations, which fields. Values never leave the server.

Running costs are modest: the server is one small container, the repository is open-source software on the same machine, and search by meaning is billed per character of indexed text, on the company's own account, with daily limits set on the server.

What goes into private memory, and what into the shared space?

The quality of a company brain depends on one thing: what gets written where. These are the rules the assistants follow from day one:

Private memory	Shared space	Never
context: role, current work	decisions, with status	passwords, API keys, tokens
personal preferences, such as preferred document format	the state of work: what is in progress and who owns it	personal data of customers or employees
work log, draft thinking	how a system or data source behaves	opinions about people
notes on topics only you work on	links to company documents	anything copied from private memory without consent

Three design rules make the shared space trustworthy:

• A proposal is not a decision. Every entry has a status: decided or in progress. While an architecture is still being designed, the assistant records options as in progress, never as settled.
• A person approves every shared entry. The assistant proposes what to save and why; the person accepts or corrects it. Writing to private memory needs no approval.
• Preferences stay private. How you like your documents formatted helps your assistant, not your colleagues.

The shared space is append-only. The server, not the assistant, sets the author and the date, so nobody can backdate or impersonate. Canonical pages are edited with a version check, so two people cannot overwrite each other.

The rules live in a skill, a short instruction the assistants load together with the connector. I test it like code: thirteen scenarios, such as a user pasting an API key and asking to remember it, or a colleague's entry that answers today's question. The current version passed 63 of 64 checks, and in no run did a secret or a private note reach the shared space. The one failed check was excess caution, not a leak: the assistant left out the user's own talking points for a salary review, treating them as HR data. The next version tells the two apart.

How do you secure a company brain?

A company brain holds what a company knows, so it is secured like any system with company data:

• Sign-in with the company account. Login goes through the company's Google Workspace, and the server accepts only addresses in the company domain. Someone with a private Gmail account cannot get in, even if they find the address.
• The server issues its own tokens. ChatGPT or Claude never sees the credentials for the underlying repository. The server keeps them encrypted and uses them only to act on behalf of the signed-in person.
• Private memory is protected by permissions, not by promises. Each private repository belongs to its user and is created with the user's own token. No service account has access to it, and the server never indexes it.
• Two independent gates. Repository permissions decide what a person can reach, and the server has its own allowlist of scopes on top. A bug in one does not open the other.
• Access to the shared space is granted by a workflow. When someone signs in for the first time, an n8n workflow checks the domain and adds them to the right team. Revoking access is one script.
• Data leaving the server is stated plainly. Only shared-space and automation text goes to the embeddings provider, on the company's own account. Where that is not acceptable, the embeddings model runs on your own server and no text leaves the company. The administrator of the repository server and its backups has technical access to the data, and the onboarding instructions say so.

If the server itself runs on infrastructure you manage, the same principles apply as for any self-hosted service. The n8n security checklist covers ports, the server and backups.

How much does it cost, and how do you measure the effect?

The cost depends mostly on what you already have. If your team already works with AI assistants and you run n8n, connecting a company brain and tuning the rules is the smaller end of the range on the AI agents page. Building everything from scratch, with several channels and the automation knowledge, sits at the upper end. Running costs are a small server and embeddings.

Measuring the effect is where most knowledge tools stay vague. I build it in from the start:

• The agent cites its source. When an assistant uses something from the shared space, it names the author and the date of the entry. That makes the benefit visible: you can count how many tasks started from a colleague's knowledge instead of from zero.
• Entries and searches per person. A memory nobody writes to is dead; a memory nobody searches is a diary.
• Questions that stopped reaching the specialist. The clearest business signal, and the one worth asking about after a few weeks.

Common mistakes when building a company brain

• Letting personal preferences into the shared space. "Doesn't like blue documents" helps one assistant and clutters everyone else's results. Preferences go to private memory.
• Saving proposals as decisions. An assistant that records "we decided" while the team is still debating misleads everyone who reads it later. Every entry needs a status.
• Importing documents without separating fact from plan. Design documents describe what will be, not what is. Load them as in progress, or the memory will state the future as the present.
• No source citations. If agents use shared knowledge silently, you will never know whether the company brain works.
• Treating it as a wiki for people. It is written for agents first: short entries, one fact each, with an author and a date. People get the benefit through their assistants.
• Embeddings on someone else's account. The text you index should go through the company's own account and data agreement, not the consultant's.
• No page about who works on what. It is the first thing agents need to route a question, and the first page I set up.

A company brain is a small system with an outsized effect on how a team works with AI. If your team already uses assistants every day and you want them to stop starting from zero, it is the next step after connecting an assistant to your automations.