Overview
The central obstacle to deploying a company-wide AI brain is not knowledge retrieval but safely sharing context and capabilities without leaking sensitive information or enabling unauthorized actions. The speaker defines a company brain as shared context, access-control rules, and tools made available to a general-purpose coding agent. Rather than attempting a centralized, multi-year knowledge-base project, organizations should let employees grow one interconnected company wiki through their normal work. Agents may suggest facts, links, and access scopes, but a named human must verify and approve every contribution. This balances the impracticality of manually writing shared skills with the opacity and risk of automatically saved agent memories. At retrieval time, the agent should use the requesting user's claims so it can only read context that person is permitted to access. Collaborative agents introduce a harder problem because participants may have different authority to investigate code, deploy software, or access production systems. The proposed answer is to apply the same identity principle to tool execution: keep credentials out of cloud sandboxes, inject the acting user's credentials at mediated HTTP or SQL boundaries, and let tool owners control access. In short, a useful company brain is a governed, continuously evolving system in which humans remain accountable for knowledge publication and authorization remains attached to every read and action.
Sections
Higher-Level Implications
Patterns implied by the proposed governance and architecture.
- The central security boundary is not the model itself but the combination of knowledge publication, identity propagation, and mediated tool access.
- Contribution velocity can become self-reinforcing: useful knowledge encourages more use, and successful use reveals additional knowledge worth teaching.
- A shared brain does not require shared authority. Context can be structurally unified while every retrieval and action remains constrained by individual permissions.
- Collaborative incident threads are especially valuable capture points because debate converts undocumented assumptions into verified operational rules.
Security and Adoption Risks
Failure modes that can undermine confidentiality, integrity, or usefulness.
- A broadly privileged agent could expose compensation, finance, security, or other sensitive information to unauthorized employees.
- Storing credentials in an execution sandbox creates a path for unintended or malicious use of production systems.
- A multiplayer agent can collapse separation of duties by allowing a participant with debugging access to trigger production deployment.
- Automatic memory capture can silently preserve incorrect conclusions, sensitive facts, or inappropriate scopes.
- Team-specific memories and channel-local context create additional knowledge silos rather than a company-wide brain.
- Manual GitHub-based documentation places too much effort on contributors and is likely to suffer from poor adoption.
Lessons for Building a Company Brain
General principles derived from the speaker's deployments and internal use.
- Organizational knowledge should emerge from everyday work rather than from a standalone, centralized knowledge-construction project.
- The best contribution workflow lies between labor-intensive manual documentation and uncontrolled automatic memory.
- Humans should review semantic facts and access scopes while agents handle document placement, links, and formatting.
- The identity used to retrieve knowledge and execute tools should always remain traceable to the human authorizing the interaction.
- Verified conclusions from collaborative debugging are more valuable than unreviewed observations captured early in an investigation.
Proposed Architecture
Concrete storage, authorization, and execution mechanisms described in the talk.
- Represent shared context as one interconnected company wiki, potentially implemented as linked Markdown files.
- Attach read and write scopes, owners, and human attribution to individual wiki pages.
- Have agents propose knowledge changes and scopes, then require explicit human acceptance or rejection.
- Resolve every context read using the requesting user's credentials and authorization claims.
- Keep credentials out of cloud sandboxes and inject user authorization at HTTP or SQL mediation layers.
- Proxy or virtualize interactions with real data so tool access can be centrally enforced without placing durable secrets inside agent execution.
- Let the person who adds or owns a tool define which users may access that tool.