What is a company brain, and how do you build one?

A company brain is a nickname for company knowledge that people and AI can use together. It connects relevant records, local meanings, rules, decisions, and later results so a team can answer a question and understand the basis for the answer. It is not one model that knows everything employees know.

Start with a problem someone owns. Importing every document first can give a system a large collection of text without resolving which account a record describes, whether a rule is current, or who may act. A useful company brain grows around questions it can answer reliably.

Illustrative example: A customer is stuck during onboarding. The CRM has the account owner, support has two document requests, a shared folder has the customer's latest file, and an operating rule says which version is required. One team thinks the file is missing. Another has it but has not matched it to the right case. The first question is simple: what is blocking this customer's usable rollout, and who can clear it?

Build it around one question

1. Question and ownerWhich onboarding case is stuck, and who owns the result?
2. SourcesBring the relevant CRM, support, documents, and operating rules.
3. Shared meaningMatch the customer and define what each status means.
4. PermissionsLimit each reader and action to current authority.
5. Answer testCheck ordinary, missing, and conflicting cases.
6. Approved workRoute a permitted next step to the right owner.
7. Later resultRecord whether onboarding became usable.

Start with the owned question and test the answer before expanding the sources or authorizing work. Record the later result so a proposed lesson can be evaluated.

Name the question and owner

Write the question as a decision someone must make. “Understand our business” is too broad to test. “For this onboarding case, identify the next missing requirement and the responsible owner” has a visible answer. Name the person who will judge whether the answer is useful and who will handle an exception.

Define the result at the same time. A first version may only explain why a case is stuck. A later version may create an authorized task. Neither result is the same as the customer completing onboarding. Set a baseline for the measure you care about before changing the process.

Connect the smallest relevant set of sources

List the records needed for the first answer and who maintains them. In the illustrative case, those are the account record, support requests, customer documents, and the current operating rule. Record when each source was last updated. An external notice may matter too, but only after checking which local accounts and deadlines it affects.

The access route may be an approved API, export, or existing tool. A successful connection is the beginning of the test. Check which fields can be read, which actions are allowed, and what happens when a credential expires. Nodes Connector helps build and verify private integrations, but each required operation must be validated in the customer's environment.

Agree on names, meanings, and identities

“Document received” can mean the file arrived, passed format checks, or was accepted by the reviewer. Those states should not collapse into one green status. Decide which system is authoritative for each field, how the same customer is matched across systems, and who resolves a conflict. Keep both source values and dates when they disagree.

A knowledge graph can represent the account, support case, document, rule, owner, and their relationships. A context graph emphasizes the circumstances around the decision, including human judgment and later outcome. The labels overlap. Judge the implementation by what it retains and how it handles corrections.

Carry permissions into the answer

A shared answer must respect the access of the person or service using it. If the support agent cannot view contract terms, a summary should not reveal them indirectly. Test both an allowed and a denied request. Review service-account access separately from employee access, since the two may differ.

Reading and acting need different grants. A system may be allowed to inspect an onboarding status but not edit it. Routine tasks can run within standing authority where policy permits; consequential or newly scoped actions can require review. An earlier approval never widens current permissions.

Test the answer before adding actions

Use a few cases whose correct handling the team knows. Include one clean case, a stale document, two customers with similar names, conflicting requirements, and a missing rule. Ask what evidence the answer cites and what it does when the evidence is incomplete. A useful system can say that it cannot determine the next step yet and identify the owner who can resolve the gap.

Context engineering selects the relevant instructions, facts, history, and tool results for this task. The graph may help store those relationships. Model capability, retrieval, and the quality of the underlying records still matter. Test them together instead of treating the graph as a substitute for evaluation. Anthropic's context-engineering guide describes the broader practice.

Move from an answer to approved work

After the answer is reliable, decide whether a next step should be taken. In the example, the team might send one clear document request to the customer and assign one internal owner. The plan should state which requirement is missing, which source supports it, who may send the request, and how delivery will be confirmed. If the issue is a disputed policy, the system should route it for review rather than choose a convenient interpretation.

A generated plan is a proposal. Test the destination action, denied access, retries, and the case where the destination response is unknown. Confirm the action actually happened before reporting completion. Then check the later business result: did the customer finish rollout with less rework? A Decision Trace can connect evidence, human input, authorized action, and the later observation. That record does not prove the action caused the result; it makes evaluation possible.

Know when a simpler tool is enough

If the task is “find the current policy paragraph,” a permission-aware search tool may be sufficient. If the team needs a fixed weekly report, a report may be easier to maintain. Add connected context when the question depends on relationships across records, changing rules, or earlier decisions. Add an agent only when choosing and checking steps provides value beyond a fixed workflow.

Nodes Engine builds and uses company context to investigate and coordinate authorized work. Nodes Connector supplies tested reads and actions. Nodes AI FDE helps clarify the goal, configure the workflow, and test it. The company retains its context graph, Decision Traces, and outcome history. A proposed lesson from one case needs evaluation before another team relies on it.

The next useful exercise is to choose one owned question and assemble five representative cases, including at least one that should stop for missing evidence. That gives the team a testable starting point instead of an open-ended data import.

Sources

• Effective context engineering for AI agents

Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.