# Your Company Brain Will Leak Secrets: How We Stopped It for Big Banks

Tanmai Gopal, PromptQL | AI Engineer World's Fair 2026 | 26:25

Source: https://www.youtube.com/watch?v=0uC6u0lJJl4
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/your-company-brain-will-leak-secrets-how-we-stopped-it-for-big-banks
Published: 2026-09-03
Tags: enterprise, human-in-the-loop, memory, privacy

## TL;DR
- A company brain should grow from each person's work instead of being built as a large central project.
- Shared knowledge belongs in one linked wiki with file-level scopes, suggested changes, and a human approver for every edit.
- Shared agents should use each user's credentials at the data and tool layers, while credentials stay outside the sandbox.

## Summary
Tanmai Gopal describes a company brain as shared context stored in linked markdown files, together with access rules for data and tools used by a coding agent. PromptQL spent a year deploying early versions across 15 to 20 organizations, including AI-native companies, tech-forward firms, and Fortune 100 banks. Gopal argues that a useful brain grows through daily work. In his experience, people add more knowledge after the system starts helping them, and the edit rate can keep rising. He rejects two common designs: asking employees to maintain shared skills in GitHub, and giving each team an agent with its own memory. Both approaches either depend on unnatural extra work or create silos. His design uses one company-wide wiki, scoped per file, where the agent suggests facts and access scopes but a person approves the change. For multiplayer work, user credentials are injected at the HTTP and SQL layers. Credentials never sit in the sandbox, and users control access to tools and data.

## Key ideas
### A healthy company brain can receive more edits as people trust it
[03:21](https://www.youtube.com/watch?v=0uC6u0lJJl4&t=201s)
Gopal asks the audience what a healthy company's daily edit curve should look like. He contrasts an initial burst followed by neglect with a system that fluctuates around a steady rate. When he plotted PromptQL's history over two months, the number of updates kept rising. His explanation is that useful systems invite more teaching. Someone first adds how to query data, then how to interpret it, then how to act on the result, and later how to run A/B testing. Since each learned behavior still needs correction, the rates add together. He calls the rising overall size and rising daily update count signs of a healthy brain, while admitting the system is still early.

### The company brain is shared context plus access rules for a coding agent
[08:11](https://www.youtube.com/watch?v=0uC6u0lJJl4&t=491s)
Gopal defines a company brain as shared context kept in markdown files, along with access-control rules for the data and tools available to a coding agent. It is not a general knowledge graph or a general-purpose AI that happens to make tool calls. His example is using a coding agent to answer a security questionnaire from company knowledge, then send the approved email. He compares this architecture with Claude Code, Claude Cowork, and the Codex app, which he says use coding agents to solve general problems. The system's purpose is to give that agent the company's relevant context without trying to secure one enormous knowledge base.

### Companies should grow a brain through everyday work instead of building it as a project
[09:45](https://www.youtube.com/watch?v=0uC6u0lJJl4&t=585s)
Gopal says an enterprise cannot realistically spend two years building a complete company brain for a large, old organization. Each person should own the part of the brain related to the work they do. Their contributions can come together over time. This is why he prefers the phrase "grow a company brain" to "build one." The approach lets people self-serve their portion of the shared context while the system gradually accumulates useful material. PromptQL's own brain contains about 5,000 interconnected pages, but Gopal presents that as something that grew through use rather than as a project that could have been completed upfront.

### Writing shared skills in GitHub asks employees to do work they do not naturally do
[12:33](https://www.youtube.com/watch?v=0uC6u0lJJl4&t=753s)
Gopal rejects the idea that every employee should update shared skills in a GitHub repository after completing work. His example is a security and compliance employee who has just finished a large questionnaire. Expecting that person to write a reusable skill for an unknown colleague adds another task at the end of an unpleasant job. Gopal says people often lack time to curate even their own memory and context, so they are unlikely to document knowledge for someone they may never meet. The design depends on voluntary maintenance that does not fit ordinary work habits.

### A team agent with its own memory creates another silo
[13:52](https://www.youtube.com/watch?v=0uC6u0lJJl4&t=832s)
A second proposal is to give a small team an agent that automatically saves its shared memory. Gopal says this can help the team, but it is still isolated from the rest of the company. He compares it with per-channel memory: knowledge saved in one Slack channel works for people added to that channel, while others cannot use it. The result is another silo rather than a company brain. Knowledge from a security team, for example, remains trapped in that team's agent unless someone manually moves it elsewhere. The system needs a shared location that different agents and people can access under explicit rules.

### One linked wiki can combine company-wide context with file-level scopes
[14:59](https://www.youtube.com/watch?v=0uC6u0lJJl4&t=899s)
Gopal's third design puts all context into one shared wiki made from linked markdown files. Each file can have read and write scopes, so sensitive finance material and personal material can have different owners and access rules. The agent does not silently add memory. It suggests the facts to add and the scopes for each page, then a person accepts or rejects the proposal. The human reviews the facts rather than manually choosing files and links. Gopal presents this as a middle ground between GitHub's full authoring and review process and uncontrolled agent-written memory. The wiki can grow broadly while each page keeps its own access boundary.

### Every wiki change needs a responsible person's name
[18:30](https://www.youtube.com/watch?v=0uC6u0lJJl4&t=1110s)
Gopal gives two rules for the shared wiki. Everything should go into one company-wide wiki, and every change should carry a human name. The record must not say only that Claude or another agent made the edit. It should identify the person who approved it. If incorrect permissions expose compensation information, the organization can trace the decision to that person and take remedial action. The human approval step therefore controls both the content and the accountability for its scope. Gopal also says the interface must make review easy, with a short list of proposed facts and the ability to choose scopes for each page.

### Multiplayer agents need per-user credentials during reads and tool execution
[20:06](https://www.youtube.com/watch?v=0uC6u0lJJl4&t=1206s)
The hardest case is a group debugging an incident through one shared agent. Gopal says the argument between engineers often creates the highest-quality knowledge because it exposes undocumented technical decisions. In his example, a discussion about a failed wiki lookup produces a rule against using a prefix that causes production lookup problems. The security problem is that the same agent may be asked to inspect code, open a pull request, deploy to staging, set an alert, or deploy to production, even though different people should control those actions. His answer is to keep credentials out of the sandbox and inject each user's credentials at the HTTP and SQL layers. The agent then acts as the user in that interaction.

## Notable quotes
- "A healthy brain, of course, the overall size keeps increasing, but even your daily updates per day kind of keep increasing as well." (06:14)
- "We're going to grow a company brain. We're not going to build one." (10:38)
- "The core idea is that you want to get the agent to suggest a change instead of doing the change." (18:30)
- "Do not store credentials in the cloud sandbox." (24:34)

## Tools & references mentioned
- PromptQL
- Hasura GraphQL Engine
- OpenClaw
- Hermes
- Claude
- Claude Code
- Claude Cowork
- Codex app
- Instacart
- Apple
- Meta
- JPMorgan
- Stitch Fix
- OpenTelemetry
- Opus 4.5
- GLM
- GPT

## Who should watch
- You are considering a shared AI agent for company knowledge and need a design that limits leaks between teams.
- Your team already has per-channel or per-team agent memory and wants to avoid creating more isolated silos.
- You are building agents that can both investigate incidents and take production actions, and need user-level permission boundaries.

## Related talks

- [Every company should have a Brain](https://aietalks.com/talks/every-company-should-have-a-brain) (Garry Tan, Y Combinator, 21:08)
- [Agents' Next Frontier: Agent-to-Agent and Network Effects](https://aietalks.com/talks/agents-next-frontier-agent-to-agent-and-network-effects) (Jean-Denis Greze, Town, 21:17)
- [Wearing the Agent: From Group Chats to Glasses](https://aietalks.com/talks/wearing-the-agent-from-group-chats-to-glasses) (Sai Krishna Rallabandi, 19:09)
- [What If Your Chip Design Team Moved Like a Single Body?](https://aietalks.com/talks/what-if-your-chip-design-team-moved-like-a-single-body) (Abduallah Mohamed, AIDAChip, 16:46)
- [What the Best Agents Share](https://aietalks.com/talks/what-the-best-agents-share) (Mardu Swanepoel, Flinn AI, 10:21)