# What is a company brain?

A company brain is an informal name for shared company knowledge that people and AI can use. It brings together relevant records, business rules and the reasons behind earlier decisions, so the next person or AI system has useful context to work from.


> By Saad Bin Shafiq, founder of Nodes · Sep 27, 2026
> Canonical: https://www.nodes.inc/blog/company-brain


---
**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 stopping this customer from starting to use the service, and who can clear it?

## How do I get AI to understand my business?

Start with one question your team needs answered. Connect the records that help answer it, explain your company’s terms and rules, and involve someone who knows the exceptions. Test the answer on familiar cases before giving AI more responsibility.


**Build useful company context around one question**

1. **Question and owner**: Which onboarding case is stuck, and who owns the result?
2. **Sources**: Bring the relevant CRM, support, documents, and operating rules.
3. **Shared meaning**: Match the customer and define what each status means.
4. **Permissions**: Limit each reader and action to current authority.
5. **Answer test**: Check ordinary, missing, and conflicting cases.
6. **Approved work**: Route a permitted next step to the right owner.
7. **Later result**: Record whether the customer could start using the service.


### 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](/products#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](/blog/what-is-a-knowledge-graph) can represent the account, support case, document, rule, owner, and their relationships. A [context graph](/blog/what-is-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](/blog/context-layer-is-the-moat) 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](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) describes the broader practice.

## How do I build an AI brain for my company?

Start small: choose one problem, connect its records, agree on their meaning, and test the answers. Keep the reasons behind decisions and what happened afterward. Add more systems when the first part is useful and reliable.

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: could the customer start using the service with less rework? A [Decision Trace](/glossary/decision-traces) 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](/products#engine) builds and uses company context to investigate and coordinate authorized work. Nodes Connector supplies tested reads and actions. [Nodes AI FDE](/products#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](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)

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