Company Brain Architecture for Shared AI Work

Company brain architecture is the structure that connects company sources, approved decisions, access rules and current project work for people and their AI assistants. A useful design gives each kind of information a clear home, then provides the relevant record when a session starts. It helps your team answer both “What do we know?” and “What should happen next?”

fenbs can hold the shared work part: projects, tasks, Decisions and rules, and Where we left off. Original documents can stay in their existing tools. This is a practical arrangement of records and responsibilities, rather than a requirement to build a new model or move every file.

What parts does the structure need?

Start with four parts and a person responsible for maintaining each one. They may live in different tools. What matters is that a teammate can follow the connection from a task to the decision behind it and from that decision to its supporting source.

Think of these as responsibilities, not four folders that must be created. Your document service may already own reference material. The shared work record should point to that material and explain its relevance. Our guide to what an AI brain is covers the broader idea; this page focuses on how the company record fits together.

Which source should own an answer?

Choose one authoritative home for each important fact. If the signed statement of work defines the agreed deliverables, keep that document as the source. A project summary should identify it and explain the current consequence, such as which task is excluded, without becoming a competing contract.

Keep enough source information to check a summary: its title, location, relevant version or date, and the person who reviewed it. Provenance means the record of where information came from. The W3C PROV overview↗ (opens in a new tab) describes how information about a record’s origins helps people assess its reliability.

For example, a hypothetical design studio might record that its homepage draft follows the client-approved layout, with a link to the approved file. If a later draft changes that layout, the assistant should flag the conflict. A source link is useful only when the team also explains which version governs the work.

Keep large research collections separate from the short work summary. The AI second brain guide covers reusable knowledge collections, while the current project record should stay small enough to read before an ordinary work session.

Where do decisions and continuing rules belong?

A source describes evidence; a decision records a choice. Preserve that distinction even when both appear in the same meeting. “People struggled with account setup” is an observation. “We will simplify account setup before adding reporting” is a decision that needs a human decider and a reason.

Record the choice, its scope, who made it, why, and what would justify revisiting it. Give open proposals a visibly different status. AWS guidance on architectural decision records↗ (opens in a new tab) illustrates the value of preserving an accepted decision and recording a later replacement, rather than silently rewriting the past.

A rule is a decision that continues to apply, such as requiring a person to approve changes to client deliverables. Make its boundary explicit: this client, this project or the whole team. An assistant’s summary of a conversation must not acquire the authority of an approved company policy.

In fenbs, people decide and assistants can record their decisions; continuing rules appear first when connected assistants read the AI context.

How should access follow the information?

Draw access boundaries before connecting assistants. A company-wide source collection and a project shared with a contractor are different audiences. Give each person and connection the access needed for the work, then check the actual behavior in every system involved.

This follows NIST’s least-privilege principle↗ (opens in a new tab): limit access to what a person or process needs for its assigned job. Reading and editing deserve separate consideration. An assistant that drafts an update may need to read a brief without being allowed to change the original.

A summary can disclose restricted information even when its source link remains protected. Before putting a summary on a widely shared project, review its contents for that audience. Removing a link does not make copied salary details, customer information or a confidential negotiation safe to share.

Test with a real low-access member, not only an administrator account. Check both what they can read and what they can change. Repeat the test when a collaborator leaves or the project moves to a different team.

What should happen at the start and end of work?

At the start, an assistant should read the project’s rules, goal, current task and saved progress. Ask it to state the next action and any unresolved question before acting. This makes missing context visible while it is still easy to correct.

At the end, save the result, what was checked, what remains uncertain and the next action. Keep a failed test separate from a completed change. “Draft revised; owner review still needed” tells the next person more than “updated,” particularly when they were absent from the conversation.

fenbs keeps that continuation record in Where we left off; the AI handoff guide explains how to make saving progress part of a normal session. For software that carries out actions, AI agent architecture covers the separate question of how the acting system is arranged.

How to do this with fenbs

1. Create a free account and try one active project on a personal kanban board. Use a team kanban board when colleagues need to participate, with suitable member roles.
2. Add the project goal and current tasks. Include the source links that explain the work, identifying the approved version where that matters.
3. Record the choices people have already made in Decisions and rules. Keep unresolved questions open and record the scope of each continuing rule.
4. Connect a supported assistant through the integration guides. MCP, a standard way for AI apps to use outside tools, lets the assistant read and update the work through the access you approve.
5. Ask the assistant to read the project context before working and save progress before stopping. Have another member check that the saved next step makes sense.

fenbs is not a document warehouse or a system for building custom search over every company file. Use a dedicated source or search system when that is your main requirement. fenbs holds the shared work record that explains what your team is doing with those sources.

How can you tell whether the structure works?

Choose a completed handoff and ask someone who missed it to find the governing decision, its source and the remaining action. Then ask their connected assistant to explain the same work. Look for a correct, checkable answer rather than a polished summary.

If the answers disagree, correct the record’s ownership, scope or current status before adding more material. A small dependable record is easier to maintain than a broad collection with unclear authority. For a lighter first rollout, see the startup setup; explore more team examples in the team brain hub.