Team Brain: A Shared Work Record for People and AI
A team brain holds the knowledge that helps colleagues continue each other’s work. Learn what belongs in it, who keeps it current, and how AI assistants can use the same record.
Updated 5 min read
A team brain is a shared, maintained record of what a team knows about its work: its goals, decisions, rules, lessons, and current progress. People and their AI assistants use it to understand what is agreed and where to start next. Tools such as fenbs keep that work record available outside any one person’s chat history.
The term describes a working habit as much as a tool. Saving information helps only when a colleague can find the relevant answer, understand its source, and tell whether it still applies. A useful team brain makes those questions easier to answer without calling the person who remembers everything.
What problem does a team brain solve?
Say a three-person design studio is preparing a client website. The designer knows why the navigation changed. The developer knows which form still needs testing. The account lead knows what the client approved. All three are informed, but none has the whole current picture.
Their assistants inherit those separate explanations. One drafts copy for an outdated navigation structure while another treats a proposed form as approved. A shared record can state the current design, the approval behind it, and the remaining check. Each person can then work from the same agreement.
This is a team application of the broader AI brain concept. It does not mean combining people’s private conversations or training one model on everything the business has ever produced. It means preserving the work another session needs to continue responsibly.
What belongs in the record?
Include information that changes a future action. An old slide deck may explain a project’s origin, but it may not say that the client rejected its main proposal. Keep the current answer close to the work, with a reference to the supporting material.
| Record | What to write |
|---|---|
| Goal | Make it easier for visitors to request an estimate. |
| Decision | The client approved a shorter contact form; link the approval. |
| Rule | A person must approve changes to the information collected. |
| Task | Check that submitted requests reach the correct inbox. |
| Lesson | Test delivery after changing form settings; a success screen is insufficient. |
| Progress | The form is built; delivery remains untested; start with the test. |
Use a glossary for words your team gives a special meaning. If “ready” means reviewed but not published, explain that once. Keep a source link for details that belong elsewhere, such as a design file or contract, rather than maintaining another complete copy.
Separate suggestions from commitments. “We could remove the address field” is a proposal. “The client approved removing the address field” is a decision with a person and evidence behind it. That difference matters when an assistant is about to change the form.
How does it stay readable for people and AI?
Write each entry around one useful question: what was chosen, what remains, or what should happen next? Start with the answer. Add its scope, source, and any uncertainty. A colleague should not need to reconstruct a meeting before understanding the entry.
For example, “Contact form: the shorter version is approved for the website redesign. Delivery has not been tested. Start by submitting a test request” gives a clear next action. “Discussed the form and made good progress” leaves the important facts hidden.
The US Digital Services Playbook (opens in a new tab) asks teams where future members can access documentation and emphasizes familiar, understandable language. Apply those questions to your own record: can someone new find it, and does it explain the work without private shorthand?
In fenbs, connected assistants read Rules first, then Where we left off and current work; the workflow guide explains that starting point.
Give the next teammate a usable starting point
Add the project, current tasks, and the decisions that govern them in fenbs. Ask each connected assistant to read that context before working and save progress before stopping. Colleagues can continue from the same record while roles control who can do what.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
Who keeps the team brain trustworthy?
Give each active piece of work a person who notices when its record needs updating. This does not mean one person writes everything. It means an incorrect instruction has somewhere to go, and nobody assumes an unnamed colleague will fix it.
People remain responsible for decisions. An assistant can summarize a meeting, suggest a lesson, or record a choice someone made. A person should verify that the summary reflects the actual agreement before others rely on it. Useful team norms make that expectation explicit.
Treat access as part of accuracy. A client approval may belong in the shared work record, while unrelated private client information does not. Include enough to guide the task, and check who can open the supporting source. A link does not grant permission to read its destination.
How do you keep yesterday’s answer from becoming today’s mistake?
Update the record at the moment the work changes. When testing finishes, replace “untested” with what was checked and the result. When a person replaces a decision, record the new choice and its relationship to the earlier one so the reasoning remains understandable.
Review recurring problems for lessons worth keeping. NASA’s knowledge services (opens in a new tab) combines learning, knowledge sharing, and lessons learned to support its workforce. Your team can apply the same practical principle at a smaller scale: save an experience in a form someone can use on the next similar job.
Do not turn every conversation into permanent guidance. Keep a lesson when it changes what someone should do, and name the circumstances where it applies. “Check form delivery after settings change” is reusable; a transcript of everyone discovering the problem is usually too much to read first.
How to do this with fenbs
- Create a free account. Use one real project to try the workflow; one person can start free with no credit card.
- Add the project and its current tasks. When colleagues need to share the work, use a team kanban board with members and suitable roles.
- Record the agreed choices in Decisions and rules. Add a short glossary or context note only where the next person needs an explanation.
- Connect a supported AI app using its integration guide. MCP is the standard connection that lets an assistant read and update an outside tool; approve the access you intend to give it.
- Ask the assistant to read the project context before working. At the end, save the tasks’ progress and Where we left off, including the next step and anything waiting on a person.
fenbs is a fit for shared work, decisions, rules, and handoffs. If your immediate need is a long handbook, complex document publishing, or a specialized records system, keep that material in a tool designed for it and reference the relevant source.
How can you tell whether the team brain is helping?
Ask a teammate who was absent to continue a small task. Can they explain the current goal, the decision that constrains it, and the next unfinished step? Then ask their connected assistant the same questions and compare its answer with the record.
If either answer is wrong, improve the entry before adding more information. The test is whether people can use the record, not how many pages it contains. Our team AI memory guide covers ongoing upkeep, and the team brain hub connects the related workflows.