Company Brain Concept: A Shared Record Your AIs Can Use

The company brain concept means keeping a maintained record of organizational knowledge, decisions and current work that the right people and AI assistants can use. It combines useful context with sources, human owners and access boundaries. The value comes from knowing which information applies to a job and whether someone is responsible for keeping it accurate.

fenbs shows one part of that idea in practice: a shared record of projects, tasks, Decisions and rules, and Where we left off. A team can give connected assistants that work context without expecting a private chat to become the company’s lasting memory.

What does the word “brain” mean here?

“Brain” is a metaphor for accessible context. It does not mean the company has become conscious, or that a single system understands every document. It describes a place or connected set of records that helps someone recover the information needed for a decision or a task.

An AI model supplies language and reasoning capabilities. The company record supplies facts about the work: what the team is trying to achieve, what people chose, which rules apply and what happened last. Keeping those roles separate makes it easier to question an answer instead of treating fluent wording as organizational knowledge.

A large language model, or LLM, is an AI model that works with language. Connecting one to company records does not by itself train it on those records or give it permission to act. Our guide to what an AI brain is explains the general idea of keeping useful context outside a conversation.

What belongs in the maintained record?

Include information that helps a person understand or continue real work. A company brain can draw on a handbook, approved reference documents and project records, but it should explain how those pieces relate. A large collection of files is not useful merely because an assistant can read it.

• Purpose: what a project is trying to achieve and who it serves.
• Sources: where important claims and approved requirements come from.
• Decisions: what people agreed, why they agreed it and which work it affects.
• Rules: instructions that continue to apply, with a clear scope.
• Current state: what has been completed, checked or left unresolved.
• Ownership: who maintains the information and who can answer open questions.

Imagine a furniture company changing an installation guide. The shared record says which product version the guide covers, who approved the new fitting instructions and whether a demonstration has been checked. The original drawing remains the reference; the work record explains what the team is doing with it.

A broader AI second brain can help collect reusable knowledge. A company record adds the organizational questions: who owns this information, who may see it, and which answer has authority for the current work?

How does an assistant actually use it?

An assistant needs a supported way to receive relevant information. A person might provide a reviewed summary, or an approved connection might let the app read an outside record. Access must be arranged; the existence of a company brain does not make every AI app aware of it.

Before drafting the installation guide, the assistant should read the project’s current goal, rules, relevant decisions and saved progress. It should identify an unresolved approval rather than guessing the answer. After the session, someone needs to save the useful changes so the next conversation starts from the updated state.

This is a repeatable reading and maintenance habit, not a guarantee of correct answers. Ask the assistant to identify the source behind a consequential claim. Check that source yourself when the result affects safety, obligations or an important commitment.

In fenbs, connected assistants read Rules first, followed by the project’s saved starting point and work context, then save progress before stopping.

What makes a record authoritative rather than plausible?

A useful record separates observation, interpretation and agreement. “A reviewer reported that the diagram is unclear” is evidence. “The diagram may need another view” is an interpretation. “The product owner approved a second view” is a decision with a different level of authority.

Keep the origin of important information visible. The W3C PROV overview↗ (opens in a new tab) describes provenance as information about how something was produced, useful when assessing reliability. In ordinary company work, that can mean a source link, the relevant version and the person who reviewed it.

Authority also needs time and scope. An accepted instruction for one product release may be wrong for another. When the team changes a choice, preserve the earlier reason and mark the replacement. AWS’s decision-record guidance↗ (opens in a new tab) provides a concrete example of keeping that decision history.

fenbs keeps human decisions distinct from assistant suggestions in Decisions and rules, with changes recorded in History. That provides a record to inspect; a person still needs to ensure the recorded decision accurately reflects what was agreed.

Who should be able to see and change the context?

Shared context should reach the people involved in the work, with limits appropriate to the information. A contractor revising the guide may need product instructions without access to employee records or unrelated client projects. The same boundary should apply when an assistant helps that contractor.

Use NIST’s least-privilege principle↗ (opens in a new tab): grant the access needed for the job. Consider reading and editing separately. An assistant can be useful when it can read an approved reference and propose changes without changing the source itself.

Summaries need the same care as original documents. A restricted source can still leak through a summary copied into a broadly shared project. Review what the new audience may learn, and test access with an appropriate member account before relying on the boundary.

How to do this with fenbs

1. Create a free account and choose a real project to try. A personal kanban board is free for one person with no credit card; use a team kanban board when colleagues need access.
2. Add the project goal and current tasks. Include relevant source links and identify what has been checked versus what remains uncertain.
3. Record the choices people made in Decisions and rules, with continuing instructions scoped to the work they govern.
4. Connect a supported assistant through the integration guides. MCP is a standard way for an AI app to use an outside tool; approve the connection’s intended access.
5. Ask the assistant to read the project context before working and save progress at the end. Review its saved account against the actual results.

fenbs is not a system for training models or searching every company document. If you need a large reference library or custom software to find relevant material, choose tools for those jobs. fenbs holds the shared work and decisions that people and supported assistants need to continue.

How do you know the concept is working?

Ask a teammate who missed the last session to explain what is agreed, what supports it and what needs doing next. Then ask their assistant the same questions after it reads the project context. A useful answer names unresolved questions as clearly as completed work.

If the answers expose gaps, improve the record before adding more documents. For how the pieces can be arranged across a company, read the structure guide. The team brain hub covers other ways to maintain shared context as your needs grow.