What a Company Brain is and what changes when a second brain becomes organisational

The AI second brain became popular because it solves a personal problem: notes, meetings and decisions spread across tools, while each model conversation starts without the full history.

The problem changes when that idea enters a company. There is no longer one owner, one memory or one access rule. Sales, support, operations, finance and leadership share some sources and must keep others separate. That is where a second brain stops being enough and a Company Brain begins.

How Meteor’s Company Brain operates

Meteor already combines five layers that turn company knowledge into continuous work:

1. Contact context: standard and custom fields, recent conversations, processed attachments and previous tool results remain available to the agent.
2. Collections: structured company knowledge and processes that Mets may query or update.
3. MCP: connections to CRM, ERP, commerce, scheduling and other systems for live facts and authorised actions.
4. Feedback: results may update contacts, collections or company variables for the next person, agent or automation.
5. Governance: members use roles and scopes; channel Mets receive an explicit collection list with read or write access, and executions leave a technical trace.

Meteor is therefore not a repository with a chat layer. It is an operational Company Brain: context enters a decision, the decision uses a tool and the result returns to the operation.

More documents do not make a Company Brain

A company can collect thousands of files and still fail to produce a reliable answer. Location is only one part of the problem. The system must also know who owns a source, whether it is current, who may access it, what happens when sources conflict, which facts require a live query and which action is allowed afterwards.

The product is therefore not defined by repository size. It is defined by the complete journey from a question and an identity to a source and an observable outcome.

From personal memory to governed company knowledge

A personal second brain may assume its owner can access everything they saved. A company cannot. A manager, sales representative and operations clerk may belong to the same organisation without needing the same information.

Moving to company scale adds five duties:

1. Identity: know who is asking and how that identity was verified.
2. Permission: decide which sources and tools that person may use.
3. Provenance: preserve where each answer came from.
4. Freshness: distinguish current content from an older version.
5. Action: define what may be read, prepared, changed or escalated.

Without those layers, the result is an assistant with many documents, not governed company knowledge.

RAG is one component, not the whole product

RAG retrieves relevant passages and adds them to the model context before an answer is produced. It works well for manuals, policies, procedures and documentation. It does not solve identity, permission, citations, conflicts or actions by itself.

It also does not replace a transactional system. A returns policy may live in a document; an order status must come from the store or ERP. A Company Brain has to recognise the difference and route each question to the source that owns the fact.

WhatsApp can be the interface, not the authorisation

WhatsApp has a practical advantage: teams already use it. They do not need to learn a new interface to ask a quick question about a procedure, customer or order.

The phone number still cannot become permission by convenience. Before internal knowledge is returned, the system must map it to a verified identity, workspace and role. It then applies that scope before searching content and before calling a tool.

A safe sequence is:

1. verify the person;
2. resolve role and scope;
3. retrieve only allowed sources;
4. cite the source and its freshness;
5. request confirmation before a sensitive action;
6. record what was queried and what was executed.

A simple interface can sit on top of rigorous architecture. Simplifying the experience does not mean simplifying control.

Four tests for any Company Brain

You do not have to accept a vendor label. Ask for these four demonstrations.

The same question from two roles

Ask about a commercial term using a sales account and an operations account. The system should prove that it retrieves different sources or rejects what is outside each scope.

Two documents that disagree

Provide a current policy and an older version. The answer should identify the source, expose the date and acknowledge the conflict instead of mixing both documents.

A fact that changes in real time

Ask for stock or order status. The answer should query the operational system rather than an indexed snapshot from the previous week.

An action that requires approval

Ask to modify a record or send something. The system should explain which tool it would use, stop when approval is required and preserve evidence of who approved it.

Start with a bounded implementation

The first use case should remain small: one team, two or three sources and a known user group. The initial goal is not to index everything. It is to answer a real question set correctly, respect permissions and make failures visible.

A prudent implementation starts with read access. Actions can be added after coverage, corrections and escalation have been measured. The internal AI chatbot and operational Meteor Company Brain uses collections, contact context, live systems connected through MCP, member or channel permissions and actions that feed the operation. A connected system is not automatically copied into Meteor and an incoming WhatsApp number does not inherit an internal role: each journey defines what it queries, what it updates and within which scope.