Company Brain in action: how Meteor governs collections, tools and traceability

The useful question is no longer whether a business can chat with its documents. It is what happens between the message and the answer: which context entered, which source was queried, which permission applied, which tool ran and what evidence remained available.

That journey is what makes Meteor’s Company Brain operational. The parts already exist inside the platform and work together. Each company implementation decides the scope, connects the right sources and tests the boundaries before increasing autonomy.

For the definition and comparison with second brains or RAG, start with what a Company Brain is. This article serves a different intent: how it works inside Meteor today.

The complete journey from a conversation

A WhatsApp conversation can activate this sequence:

1. Meteor brings together recent history, available contact data, processed attachments and previous tool results that help maintain continuity.
2. The channel gives the Met a catalog of business collections. If an allowlist is configured, only the collections on that list appear.
3. Every allowed collection may operate as read-only or read and write. This is not only a model instruction: mutation tools are rejected when a collection is marked read-only.
4. When an answer needs a live fact, the Met may call an MCP tool from the store, CRM, ERP, calendar or another connected system.
5. The run may preserve events, steps and results that let a team inspect what happened and continue the process with context.

The outcome is not an answer generated over an indiscriminate block of information. It is a sequence in which the channel, collection and tool reduce the available surface.

The control matrix that exists today

Layer	What it does today	What it does not prove by itself
Contact context	Adds fields, recent history, processed attachments and tool memory to the turn	That every fact is correct, current or sufficient
Channel collections	Allows all domain collections or a selected allowlist	That broad access is appropriate for every process
Read or write	Rejects mutation tools for a collection marked read-only	That every external integration is read-only
Internal collections	Hides system collections from channel Mets	That an external contact is an authenticated member
MCP	Exposes named tools for querying or acting in connected systems	That connecting a system copies all of its data into Meteor
API scopes	Separates reading, writing, agent execution and integration access	That a key should receive every available scope
Run trace	May expose steps and events for reviewing an execution	That compliance certification or a legal audit exists

This matrix matters because it avoids a vague “role-based access” promise. Meteor has several specific boundaries and they are not interchangeable. Member roles govern authenticated people. The collection allowlist governs a channel Met. Scopes govern an API key. Credentials and tools govern access to each external system.

Collection permission is enforced at execution time

A limit written only in a prompt depends on the model following it. Meteor adds an execution control for collection tools.

When a channel uses an allowlist, a collection can be marked read-only or read and write. In read-only mode, the Met can inspect the schema and search records, but it cannot create, update or delete items, views or content blocks. The gate rejects those operations even if the model tries to call them.

There are two additional boundaries:

• an internal system collection is not available to a channel Met;
• a channel restricted to an allowlist cannot create a new collection to expand its own surface.

The limitation also needs to be visible: if an allowed collection has no granular permission, the historical behavior is write access. A governed implementation should therefore set permission explicitly and test it with an operation that must be rejected.

MCP takes the question to the system that owns the fact

A manual and an ERP serve different purposes. The manual explains a policy; the ERP holds inventory, receivables or current operational status. Periodically copying the second into a repository can produce a stale answer.

MCP tools let the Met query the connected system when the fact changes. Every page in the integration catalog publishes tools, requirements and limits. That precision is more useful than saying Meteor “connects to everything”: a team can inspect whether the operation exists before adding it to the journey.

Public API scopes separate capabilities too. Reading collections, writing items, running agents and using integrations are different permissions. A key can therefore be issued for the work it needs, although the final selection remains the responsibility of the workspace administrator.

Context returns to the operation

A Company Brain stops being search when the result lets work continue. The Met can use conversation context, query a collection or system and return an answer. If the journey authorizes an update, the new state becomes available to the next interaction.

The Mega Alfa Trans case shows one concrete shape. Its team describes notifications, worker document intake and maintenance information brought together through WhatsApp. The testimony does not prove every control described in this article, but it does document that the channel already participates in an operational process rather than only returning information.

What to test before expanding autonomy

A serious implementation does not begin by connecting everything. It starts with tests that can fail visibly:

1. Collection outside the allowlist: the Met must neither see nor query it.
2. Read-only collection: a search must work and an edit must be rejected.
3. Live fact: the answer must come from the system that owns it, not an old copy.
4. Sensitive action: the flow must stop for approval when the process requires it.
5. Evidence: the team must be able to review available steps and understand where a failure occurred.

Scope can then expand by process, not by enthusiasm. That is the difference between a demo that answers questions and a Company Brain that participates in operations under explicit controls.