The Company Brain for AI Agents: Beyond One Person

A company brain is the shared knowledge that people and AI agents in a company read from, and increasingly write to. Most of what is taught today about building one describes a personal version: one person, their documents, their mail, their assistant. That version works, and it is worth understanding. A company of 50 or 500 people, though, has departments, sensitive data and decisions taken by more than one person, and its company brain has to answer questions the personal version never meets. This article describes what changes, where the approaches stand as of October 2026, what I measured when I tested them, and where to start.

The personal company brain

The pattern most guides describe has three parts:

• A folder of markdown files. Who you are, what you sell, how you price, your procedures, and a page for each client.
• An AI assistant connected to your tools. Mail, calendar and CRM, usually through MCP connectors (the Model Context Protocol, a standard way to plug tools and data into an AI assistant).
• A nightly job. It rereads what came in during the day, updates the client pages, removes information that is no longer valid, and links new facts to old ones.

This is close to the LLM Wiki that Andrej Karpathy described in April 2026. Instead of "rediscovering knowledge from scratch on every question", a model maintains "a persistent, compounding artifact". Karpathy also notes that it works "at moderate scale (~100 sources, ~hundreds of pages)".

The nightly consolidation is ahead of most products. Anthropic's dreams, which consolidate a memory store of Claude Managed Agents into a new one, are a research preview. The four kinds of agent memory Google announced at Gemini at Work on 8 October have no general availability date yet.

For a professional who works alone, the pattern works because three things are true:

• There is one reader, so there is one permission level.
• There is one person who decides which of two versions is correct.
• The mail and chats the job reads belong to the person who set it up.

In a company with departments, none of the three holds.

Five questions an extended company brain has to answer

1. Who can read what the agent writes?

Folder permissions protect sources. They do not protect the pages an agent writes from them. A client page built from a sales email, a note from HR and an unpaid invoice has three sets of readers, and it usually ends up with the permissions of the folder it is saved in.

In my test on a synthetic company with three visibility levels, a wiki without per-page permissions exposed restricted data to an ordinary employee in 73 of its 142 pages. Restricting each page to the readers of the sources it cites still leaked, because the model does not always cite where a fact came from. What worked best was lineage: recording every document the model had in front of it when it wrote the page, and letting a person read the page only if they may read all of those documents. It still left one gap, described below.

The same question applies when agents talk to each other. In the AgentLeak benchmark (February 2026), private data leaked in 68.8% of the messages agents exchanged, against 27.2% of their final outputs. An audit that only checks what the user sees misses the messages in between.

2. Who decides which version is true?

In a personal brain, when a new fact contradicts an old one, the job can ask the owner which one to keep. In a company it is less clear who that person is:

• a price changes in a sales meeting;
• a procedure changes in an operations review;
• a policy changes in a management decision.

The person who would be asked may not be allowed to see the other version.

"The latest decision wins" is a rule a model applies inconsistently. Research points the same way. MemStrata (June 2026) measured retrieval returning outdated values 15–40% of the time. With a ledger that records when each fact was valid and a fixed replacement rule, that fell close to zero.

In my own test on decisions taken in chat, decision cards extracted by a model first scored worse than indexing the whole conversation: 31% against 44%. They matched it, at 44%, once two things changed. A classifier picked out the chats that contained a decision, and the card recorded the dates, which earlier decision it replaced, and an excerpt of the chat. The difference is that the replacement is written in the data, where a system can enforce it.

3. What happens when a source is deleted?

Removing a document from a folder does not remove what the nightly job wrote from it. In my synthetic test, after I deleted a source, its facts were still written in nine pages. Regenerating the pages listed in that source's lineage removed its facts from all of them in under a minute. That covers the pages, not every other copy: indexes, memories and backups need the same treatment.

Research on agent memory is less reassuring. In MemCut (October 2026), after a deletion guided by a model, 39–76% of the deleted secrets could still be recovered from what remained in memory. Products are not there yet either: Microsoft documents that deleting a Copilot chat "doesn't delete saved memories". If those pages and memories contain personal data, a request for erasure is hard to honour without a record of what was derived from what.

4. Whose mail and chats does it read?

A job that rereads its owner's mail every night already touches other people's data, but its owner decides what to connect. A job that rereads the mail, chats and meeting notes of fifty employees is a different processing activity, and it brings checks the personal version never needs:

• In Italy, tools that make remote monitoring of workers possible can fall under Article 4 of the Workers' Statute. That requires an agreement with the union representatives or an authorisation from the labour inspectorate. Since October 2025, Law 132/2025 also requires employers to inform workers about the AI systems they use.
• In Germany, the works council has a say on technical monitoring before productive use.
• Under GDPR, the Court of Justice has held that data from which sensitive information can be inferred falls under Article 9. A meeting summary that reveals a colleague's health condition is in that category, and processing such data on a large scale requires a data protection impact assessment.

These are checks to run with a lawyer before the first meeting is indexed. In my reading they are not reasons to stop.

5. Can you put documents in as they are?

Guides often suggest dropping documents in as they are and letting the model sort them out. I tested that on 1,700 pages of real public documents, mostly collective labour agreements, EU regulations and tax instructions. Of the 76 questions, 38 did not get a fully correct answer, and 7 of those had failed at the first step: the text extraction had lost the table row or the heading that held the answer.

Among the changes I tested, the most effective was to put the document title and section in front of each chunk before indexing. The overall score rose from 65% to 70%, and the questions where the right chunk was not retrieved at all fell from 12 to 4.

A wiki on its own did not replace retrieval. On the synthetic corpus, the model answered 42% of the questions correctly from the wiki pages alone, against 76% from plain retrieval. In half of the questions it could not pick the right page from a list of titles.

What an extended company brain is made of

An extended company brain has four layers. Most products today cover one or two of them.

• Sources. Documents, records, tickets, chats and data tables, written by people and systems. They already carry permissions: a contract in the legal folder, a price list for sales, a salary table for HR.
• Curated knowledge. Pages written on top of the sources, such as how a returned part is handled, what we know about a customer, or the definition of a metric. Google's Open Knowledge Format (OKF) gives such pages a portable format. Version 0.2 records their sources and whether a page was generated or verified, and it states that these trust tiers "are advisory signals, not access control".
• Decisions. What was decided, by whom, when, which earlier decision it replaces, and who may read it.
• Agent memory. What agents did, what they learned, and the procedures they wrote for themselves.

A search engine over the sources covers the first layer only. The value of a company brain comes from keeping the four layers consistent. Most of the new risk sits in the other three, because they combine information from several sources and keep it after the sources change.

Where things stand in October 2026

I tag each approach by how ready it is for a company with sensitive data:

• Build today: generally available, with no major gaps for this use.
• Pilot: beta or preview, or available with gaps you have to design around.
• Watch: research or standards work.

Reading with permissions: build today

Every major platform now offers enterprise search that filters what an agent retrieves by what the user can already see in the source system:

• Gemini Enterprise: permission-aware search, with connectors that either query the source directly or copy it into the index together with its access lists. In Google Workspace, Gemini grounds answers "only in content that a user already has permission to view".
• Claude: enterprise search on Team and Enterprise plans. "You only see search results from data you have permission to access in the original systems."
• ChatGPT: company knowledge on Business, Enterprise and Edu, limited to what each member can already access in the connected apps.
• Microsoft 365 Copilot and Copilot Studio: retrieval with the user's own Entra identity.

Two caveats apply. A connector that uses one shared credential can show everyone whatever that credential can reach, unless the application checks each user's permissions separately. And filtering is not authorization: AWS states plainly that its own ACL feature for knowledge bases "provides ACL-aware filtering, not a security boundary", so the application still has to authenticate the user.

If you build the search yourself, restrict it to the documents the user may read before picking the top matches to send to the model, not after. In my tests on real documents that was enough, as the numbers below show.

Curated knowledge and agent memory: pilot

• Claude Managed Agents memory stores (beta). A store is attached to a session as read-only or read-write, and every change creates an immutable version you can audit and redact. Access is set per store, not per fact. The documentation also warns that a prompt injection could write malicious content into a store.
• Memory Bank on Gemini Enterprise Agent Platform (generally available). Memories are isolated per identity, and access rules (IAM conditions) can restrict who reads and writes each group of memories, for example per user. A memory shared by a whole team is something you design yourself.
• Microsoft 365 Copilot memory (preview). Retention policies do not apply to it, and it produces no audit log entries.
• OKF. Still at version 0.2, with open issues on deletion and on which sources a reader may see.

None of these attaches the permissions of the sources to what gets written. The partial exception is Microsoft Purview: in Word, PowerPoint and Outlook, content that Copilot generates inherits the highest-priority sensitivity label of its sources, which is usually the most restrictive one. That shows the labelling part of the rule can work in a product. It does not yet cover memories, meetings or other apps, and a single label cannot express permissions that overlap between departments.

Decisions from meetings: pilot

Meeting notes are where many decisions get recorded today:

• Google Meet "Take notes for me": the notes are a document in the organizer's Drive, shared with the invited guests. Google is explicit that this means everyone on the invitation, "not guests who actually attended".
• Microsoft Teams intelligent recap: available to people in the organization who were invited.
• Slack huddle notes: visible to anyone in the channel where the huddle took place.
• Labels: Microsoft notes that sensitivity labels that protect Teams meetings and chat "aren't currently recognized by Copilot and agents."

In each case access follows the invitation list or the channel, not what was said. A meeting where a salary or a dispute came up produces notes with the readers of the invite.

For the "which decision replaced which" part, open-source building blocks exist. Graphiti stores facts with validity intervals and invalidates them over time, but it has no access control of its own.

Permissions on derived knowledge and verified deletion: watch

There is no standard yet for the permissions of content an agent writes:

• MCP. Authorization in the current MCP specification is optional, and it carries the user's identity to a server. It does not carry labels or provenance for the content that server returns.
• Research. Work on provenance, such as signed memory entries that record what they were derived from, and on verified deletion is active, but it is research.

What I measured

I ran two tests for a client project in October 2026, both with open-weight models running locally. The samples are small, and I read the numbers as signals, not benchmarks.

The first used an invented manufacturing company: 54 short documents at three visibility levels (everyone, sales, management), with questions and expected answers I wrote myself. Besides the results above, three things came out of it. A wiki on top of retrieval kept the score where it was, 77% against 76%, without raising it at this size. With permissions computed from lineage, none of the 18 probing questions got a restricted fact back, yet one page still leaked through something the lineage did not record: the index of page titles that the model reads to decide where a new fact belongs. Since then I record everything the writer saw, index included. And a small classification model that judges whether a text is restricted made a good alarm on generated text and a poor filter on its own; one of the two highest-scoring models marked a disciplinary record as public.

The second test used 29 real public documents, 1,723 pages in all, for four kinds of small company. The manufacturer split permissions by department, the professional firm by client with walls between client files, the distributor by sales area and the IT agency by project. Only the restricted level was synthetic.

With the permission check inside each search, no probing question leaked in any of the four companies. Without it, 15 of 30 probes got restricted data back, and restricted chunks reached the model's context in almost every probe, including those where the model did not repeat them.

Plain vector search scored 65%. Most of what I tried on top of it scored the same or lower:

• hybrid keyword and vector search, 53–61%;
• smaller chunks, 62%;
• a larger answering model, 65%;
• several searches per question, 59%: the generated sub-questions pulled in less targeted chunks and more "I don't know" answers;
• a model that kept only the chunks it judged relevant, 59–63%, with summary questions hit hardest, because they need several chunks that each hold part of the answer.

I ran LightRAG, a graph-based retrieval engine, on the distribution company only. It scored 81%, the same as the title-and-section fix on that company, and it cost far more: about 15 seconds of model time per chunk to build the index, around two hours for six documents on a laptop, and twice as much text sent to the model with every answer. On the first run 5 of the 6 documents failed to index. The insert call returned normally; the failure showed only in each document's status.

Scale was not an issue. A search over 20,000 chunks, with the permission check in the query, took about half a millisecond on a small virtual machine. When the answer was not in the documents, the answering model said so in 11 of 11 cases. No fixed similarity threshold could have made that call, because the scores of answerable and unanswerable questions overlapped.

Where it is heading

What follows is my reading of the direction, based on the products above and on what I measured. It will change as the products do.

1. Retrieval with permissions stays the core. Every serious approach I see keeps a permission-aware index under everything else. It is the part that scales and that can be checked, as long as identities and source permissions are right.
2. Curated pages become a reviewed view, not the index. Pages for the subset that deserves an owner (procedures, customers, products, metric definitions), built on top of retrieval and reviewed by a person.
3. Lineage becomes a requirement. Purview already lets the most restrictive label of the sources win on generated documents. I expect the same rule to extend to memories, wiki pages and hand-offs between agents: whatever an agent writes carries the record of what it read, and only people allowed to read all of it may read the result.
4. Decisions become records. A decision that states which earlier decision it replaces, from when, and who may read it is something a system can enforce. A model's sense of "the latest" is not.
5. Forgetting becomes a feature. When a source changes or disappears, the pages, memories and titles derived from it are regenerated as part of the design, not as a clean-up project.

Where to start next quarter

For smaller companies the main obstacles are often not the technology itself. In 2025, 17% of small EU enterprises and 30% of medium-sized ones used AI. Among those that had considered it and not adopted it, the most cited reasons were lack of expertise (71%), unclear legal consequences (53%) and data protection (49%), according to Eurostat. The steps below address those concerns more than the technology.

1. Check who can see what today. An agent with permission-aware search will find every document that is shared too widely. Microsoft's own Copilot deployment guidance starts with "remediate oversharing", and the advice applies to any platform.
2. Start with permission-aware search on what you already have. It is generally available on the main platforms. If you build it yourself, filter by permission before picking the top matches, and add the document title and section to each chunk.
3. Leave HR, health and legal sources out of the first phase. Bring them in once the legal basis, access and retention rules are settled, after a data protection impact assessment where one is required.
4. Before indexing meetings and chats, talk to your workers and their representatives. Check the monitoring rules that apply in your country, and decide who may read the notes based on their content, not on the invitation list.
5. Record lineage from the first page an agent writes. Note which documents each page, memory or summary was written from. It is the record that makes permissions, updates and deletion possible later.
6. Write a deletion rule that covers everything derived. That includes the index, the summaries, agent memory and backups, as well as the original files.

A personal company brain is a good place to learn how this works. The extended one is a different design problem. The model and the tool matter less than who may read what an agent wrote, and what happens to it when a source changes. Both the Google and the Anthropic stacks give you the pieces to answer those two questions. Neither answers them for you yet.

For the mechanics of retrieval with Google ADK, see Knowledge Bases for Agents. For memory and consolidation in a single agent, see the Digital Brain series.

Last technically reviewed: 19 October 2026. Gemini Enterprise, Claude Managed Agents, Microsoft 365 Copilot and OKF are evolving quickly; their documentation is the source of truth for current features.