Build a company second brain around decisions people reuse
Contents
Keep the decision and the reason
A shared record people can maintain
A company second brain is a shared practice for preserving knowledge colleagues will need again. It can use a wiki, linked documents or an AI answer layer. The workflow matters more than the name: capture the decision, link the authoritative evidence, assign an owner and update the record when the decision changes.
Start where a future colleague would get stuck
Consider a fictional product team deciding whether to enable automatic retries after a failed data export. The discussion spans a chat thread, a design document and a test note. A newcomer does not need every message before acting; they need the current decision and the conditions that could change it.
Keep the source materials where their owners maintain them. Add a short decision record that points to those sources. This avoids a parallel copy of the design document without pretending the source links explain the decision by themselves.
The completed decision record
The following is an invented example, not a HeyBrain implementation or customer story. Its record identifiers stand in for links a team would supply.
| Field | Completed entry |
|---|---|
| Decision | Do not enable automatic retries in the first release. Show a retry option to the user. |
| Reason | The current export job does not reliably recognize a duplicate request. An automatic retry could create duplicate work. |
| Authoritative references | Design D7 describes the job; test note T3 records the duplicate-request case. |
| Owner and status | Mara, export feature owner; approved for the first release. |
| Revisit when | A revised duplicate-request mechanism has been implemented and its behavior checked. |
Keep summaries and source material in different roles
D14 answers “What did we decide and why?” D7 answers “How does the export job work?” T3 supplies the evidence behind the concern. Linking them does not make one a replacement for the others.
A transcript may contain useful context and can be searchable when transcription and retrieval support it. It may also include ambiguity, rejected ideas or material with a narrower audience. A summary helps a reader find the decision; a source link lets them inspect its basis. Neither requires the claim that transcripts are universally useless.
AI can propose the summary or find related records. The responsible person still needs to check that a proposal reflects the actual decision. Do not publish an assistant’s inference as a team approval.
Run the workflow through its first change
Later in the fictional example, Mara approves design D8 and a new test note T6 for duplicate-request handling. She updates D14 to say automatic retries are approved under D8, records the reason for the change and keeps the earlier entry visibly historical. The current record points to D8 and T6.
A colleague asking why retries were previously disabled can still understand the old decision. A colleague implementing the next release reaches the current one. That is the maintenance job; a connected source does not do it automatically.
If an AI answer layer also imports D14, verify that the current revision reaches its answers. A corrected source and an unchanged search copy are different states. Keep the old decision out of current instructions while preserving authorized history where it belongs.
Give the habit a small, realistic home
Pick one place the team already uses for approved decisions. Capture records when a consequential choice is made, and make the source owner’s normal change process include the related record. A separate weekly ceremony is optional; somebody being responsible is not.
Decide the intended readers before connecting another tool. A broadly visible summary must not expose restricted reasoning through its title, quotation or links. Use an approved summary for a wider audience where appropriate rather than distributing the restricted original.
This example improves continuity through a maintained decision record. It does not promise maintenance-free knowledge or universal connector support. For the technical source-to-answer path, see building a scoped company AI system; for missing expertise that has never been recorded, see institutional knowledge loss.
Prepared by HeyBrain Editorial Team with AI assistance. Examples are fictional illustrations, not observed customer incidents or product tests. This correction retains the original publication date and corrects the earlier account.
