Your company brain will leak secrets: how we stopped it for big banks — Tanmai Gopal, PromptQL
Description
Tanmai Gopal plotted the daily edits to his own company brain expecting the usual shape, a burst of enthusiasm followed by neglect. The line kept climbing instead, and it surprised him. His reading is that a system people trust gets taught more, not less: teach it to query the data, then to interpret the result, then to act on it, and each skill adds its own steady rate of correction on top. A rising edit count is what health looks like. Gopal cofounded PromptQL and before that built the Hasura GraphQL engine, and his team spent a year deploying an early company brain across 15 to 20 organizations, from AI native startups to Fortune 100 banks. Their own brain runs to about 5,000 interconnected pages. The obstacle is that a shared brain leaks. He dismisses two common answers before offering his. Nobody writes shared skills in GitHub for a colleague they have never met, and a team brain that saves its own memory is just a fresh silo, the same trap as per channel memory. His third option puts everything in one companywide wiki of linked markdown files, scopes read and write access per file, and refuses to let the agent write on its own. The agent proposes the facts and the scopes; a person accepts, and their name goes on the change so a leak has an owner. For the multiplayer case, where several people debug an incident together and the argument itself produces the best knowledge, credentials never sit in the sandbox. They are injected per user at the HTTP and SQL layers. Timestamps: 0:00 - Why company brains leak, and what holds deployment back 1:06 - From the Hasura GraphQL engine to PromptQL 2:03 - Three kinds of customer, from startups to banks 3:14 - Modeling the brain, and 5,000 linked pages 3:41 - A poll: what does a healthy edit curve look like 5:16 - The line that kept climbing 6:37 - Two use cases, personal recall and shared work 9:50 - Grow one, do not build one 11:09 - A security questionnaire answered end to end 12:33 - Why nobody writes shared skills in
Summary
Generated by gpt-5.6-terraAt-a-Glance
- Verdict: Watch fully
- Core thesis: A usable company brain must be grown through human-approved, access-scoped knowledge contributions and must execute every read or action under the interacting user's own identity rather than through a broadly privileged agent.
- Why it matters: This is a concrete architecture for avoiding the two failure modes that block enterprise agent deployment: accidental secret exposure through shared memory and privilege escalation when collaborative agents act across systems.
- Best use: Use it as a design review for OpenClaw-style company knowledge and shared-agent systems, especially the memory-ingestion approval flow, page-level authorization model, and per-user credential propagation pattern.
Executive Summary
Tanmai Gopal argues that the central obstacle to a company brain is not retrieval quality but security: a system that aggregates company context will eventually expose information to people who should not see it unless knowledge itself is access-scoped and all agent activity is performed as the current user. He frames a company brain narrowly as shared operational context plus access-control rules provided to a general-purpose coding agent, rather than as a monolithic knowledge graph or autonomous AI.
His proposed knowledge architecture is a single company-wide wiki of linked documents, with read/write scopes attached to each page. The critical governance mechanism is that agents may propose additions, including suggested scopes, but cannot silently write memory. A named human must review the facts, choose the access scope, and accept the change, creating accountable provenance without requiring employees to manually author and merge skills in GitHub.
For individual work, this lets an agent reuse knowledge such as completed security-questionnaire answers while retrieving only the material the requesting employee can access. For collaborative work such as incident response, Gopal extends the same principle to tools: the agent should not hold persistent credentials in its sandbox, but should receive the relevant participant's credentials at the HTTP or SQL layer for each operation.
The strongest insight is organizational rather than technical: company brains cannot be delivered as a centralized two-year documentation project. They must emerge from work already being done. The most valuable durable knowledge is generated when multiple people investigate, debate, and resolve a real issue; the system should capture the final decision and its operational rationale, not merely auto-save raw agent observations.
Key Takeaways
- Claim: A company brain should be treated as an access-controlled context layer for coding agents, not as a giant enterprise knowledge graph that must be built and secured upfront. | Evidence: Gopal defines it as shared context, such as linked markdown/wiki pages, plus access-control rules for the data and tools available to a coding agent. He points to Claude Code, Claude Cowork, and the Codex app as examples of the broader pattern of using coding-agent architecture for general work. | Implication: Ken should separate the company-context substrate from the agent runtime: keep knowledge inspectable and policy-bound, then let agents solve tasks against the subset each user is entitled to use. | Caveat: This is an architectural framing, not evidence that knowledge graphs are universally ineffective; his claim is that a centralized, all-encompassing knowledge-base project has not worked for this operating problem.
- Claim: A healthy company brain is grown by employees during normal work rather than built centrally or curated manually as a shared skills repository. | Evidence: PromptQL's internal brain is described as roughly 5,000 interconnected pages. Its daily update rate rose over a two-month period as people who found value in one learned capability added adjacent capabilities, such as moving from data querying to interpretation, action-taking, and A/B testing. | Implication: Adoption should be measured not only by corpus size but by whether use generates increasing, attributable contributions from operational work. Avoid a top-down 'build the company brain' program. | Caveat: The rising-update pattern is early and anecdotal; Gopal explicitly says it may eventually flatten into a more variable trend.
- Claim: Neither manual shared-skill authoring nor auto-saved team memory solves company-wide knowledge sharing safely. | Evidence: He argues that employees will rarely finish work such as a security questionnaire and then voluntarily document a reusable skill for unknown future colleagues. Conversely, Slack/channel agents with auto-saved memory create isolated per-team or per-channel silos and can accumulate opaque, unreviewed knowledge. | Implication: Do not rely on either heroic documentation behavior or autonomous memory writes. Design a low-friction contribution path that is global in storage but constrained in visibility. | Caveat: Team-local memory can still be useful for narrow collaboration; the limitation is that it does not become safely reusable company context on its own.
- Claim: The practical control point for knowledge ingestion is agent-suggested, human-approved updates with page-level scopes. | Evidence: In the demonstrated flow, after helping with an email, the agent presents a compact list of proposed facts for addition. The user reviews factual correctness, accepts or rejects the update, and selects who may access each resulting wiki page; the agent handles file placement and links. | Implication: Implement a memory write policy in which the agent drafts structured changes and recommended classifications, but a human owner explicitly commits them with least-privilege visibility. | Caveat: Human approval adds friction and requires a usable review experience; if the suggested changes or defaults are poor, employees may rubber-stamp them.
- Claim: Every knowledge item must have a human accountable for its presence and its visibility; AI-generated attribution is insufficient. | Evidence: Gopal's two explicit rules are that all context belongs in one company-wide wiki and that every change is backed by a person's name—not 'Claude added this' or 'Hermes added this.' He uses the compensation-leak scenario to illustrate why a responsible actor must be identifiable for misclassification. | Implication: Ken should require immutable provenance for additions, edits, approvals, and scope changes, including the responsible human identity and the authorization context under which the change was made.
- Claim: Shared agents become dangerous when they combine collaborative context with standing, broad tool privileges; tool execution must also run under user-specific authorization. | Evidence: In the incident-response example, the same collaborative workflow may fetch logs, inspect code, raise a PR, deploy to staging or production, and create alerts, even though the people permitted to diagnose, approve, and deploy are different. Gopal recommends never storing credentials in the agent sandbox and instead injecting the relevant user's credentials at the HTTP or SQL layer per action. | Implication: Treat identity propagation as a non-negotiable control-plane capability: an agent may coordinate a workflow, but each retrieval and side effect needs authorization against the appropriate human principal rather than the agent's aggregate permissions. | Caveat: The transcript only sketches this execution architecture and does not address difficult operational details such as delegated approval, multi-party authorization, audit retention, service-account use, or recovery when identity propagation fails.
- Claim: The highest-quality company knowledge comes from resolved multi-person operational debates, not from raw agent traces or initial troubleshooting guesses. | Evidence: In an SRE investigation, the agent first suggested superficial learnings about query choice and page-name prefixes. When a second person challenged the underlying technical decision and the team identified the real root cause, the durable lesson became a specific policy: page prefixes should not be used because they can cause production lookup failures. | Implication: Knowledge-capture workflows should prioritize the final decision, rationale, constraints, and confirmed remediation from collaborative threads, while keeping preliminary hypotheses clearly separate or disposable.
Detailed Brief
Concrete operating model: one global corpus, selectively visible
- Claims: The proposed answer to siloed team memories is not separate security, finance, engineering, or Slack-channel brains; it is one linked corpus whose documents carry distinct read/write scopes.; An agent answering a task should retrieve context using the requesting user's claims, so a user solving a finance task sees finance material only if that user has finance access.; The speaker positions the review interaction as a usability compromise between burdensome GitHub-style documentation/PR workflows and ungoverned autonomous memory.
- Evidence: His simple end-user example is drafting and sending an answer to a Stitch Fix security onboarding questionnaire using knowledge previously contributed by someone else.; He describes a personal page for email prioritization that can have separate owners and RBAC settings.; PromptQL says it has worked with roughly 15-20 organizations over the preceding year, spanning AI-native firms, technology-forward companies such as Instacart, and Fortune 100 banks.
- Caveats: A single logical wiki is not automatically a single physical store; the talk does not specify how document indexing, embeddings, caches, backups, or downstream model prompts preserve the same access boundaries.; Suggested scopes are only safe if defaults, classifications, and reviewer understanding are reliable; the presentation provides no measured error rate or evaluation method.
- Implications: The effective design unit is a policy-bearing knowledge object, not an unclassified chunk in a shared vector index.; For regulated deployments, authorization must be enforced consistently across raw documents, retrieval indexes, agent memory, generated citations, and exports—not only in the wiki UI.
What the talk does and does not establish
- Claims: The presentation is a field-informed architecture argument rather than a formal security proof or product-independent reference design.; Its useful contribution is the linkage of knowledge provenance, retrieval authorization, and action authorization into one operating model.
- Evidence: Gopal grounds his credibility in the Hasura GraphQL team's history of data-access deployments at organizations including Apple, Meta, and JPMorgan, and in PromptQL's recent enterprise work.; He runs out of time before fully explaining the second, collaborative shared-AI architecture and offers only the essential credential-injection principle.
- Caveats: There are no benchmarks, penetration-test results, incident statistics, permission-model specifications, or demonstrations of resistance to prompt injection and indirect data exfiltration.; The transcript contains repeated passages, likely from transcription duplication, and the final technical section is abbreviated.
- Implications: Use this video to shape architecture and review questions, not as sufficient validation of a vendor or security posture.; Any implementation based on this model needs explicit threat modeling for malicious documents, prompt injection, retrieval leakage, confused-deputy tool calls, and approval abuse.
Notable Concepts & Terms
- Company brain: Gopal's term for shared company context plus the access-control rules that govern what a coding agent may read and use.
- Grow, don't build: The operating principle that distributed contributors should add knowledge as they work, rather than a central team attempting a complete enterprise documentation project.
- Agent-suggested memory: A human-in-the-loop ingestion pattern where the agent proposes reusable facts and scopes, while a person accepts or rejects the write.
- Page-level scopes / RBAC: Per-wiki-page read/write permissions intended to allow one global knowledge corpus without making all company information globally visible.
- User claims: The current user's authorization attributes, used by the agent at retrieval time to determine what context it may access.
- Credential injection: Passing the acting user's credentials into HTTP or SQL requests at execution time instead of storing broad credentials inside the agent sandbox.
- Shared AI: A collaborative, multi-user agent interaction such as incident response, where context and work are shared but operational privileges differ among participants.
- Confused-deputy risk: The implied security failure in which an agent with aggregate or standing privileges can perform an action a particular interacting user should not be allowed to perform.
Operator Notes / Why Ken Should Care
- Define a memory-write contract for company agents: proposed content, source links, proposed sensitivity/scope, approving human, approval timestamp, and immutable revision history.
- Audit whether any current agent memory, vector store, cache, or shared Slack agent can retrieve content using its own service identity rather than the end user's effective permissions; prioritize eliminating those paths.
- Require a policy decision for every tool call: identify the acting principal, delegated authority if any, target system, requested privilege, approval requirement, and audit event.
- Run a focused red-team scenario around compensation, HR, finance, legal, and incident data: test retrieval leakage, citation leakage, generated-summary leakage, cross-channel memory leakage, and escalation from read access to tool actions.
- Capture resolved incident and decision threads into durable knowledge only after a designated human confirms the root cause and final policy; do not promote preliminary agent observations as organizational truth.
- Ask PromptQL or any comparable vendor for implementation specifics absent from the talk: enforcement across embeddings/caches, prompt-injection defenses, scope inheritance, multi-party approvals, break-glass access, and audit/export guarantees.
Source/Metadata
- Title: Your company brain will leak secrets: how we stopped it for big banks — Tanmai Gopal, PromptQL
- Transcript words: 4692
- Duration seconds: 1585
- Timestamp note: No usable timestamps or chapters were present in the supplied transcript.
Transcript
. All right. Everybody can see. Hey, everybody. Thank you for being here. I'm going to talk about the fact that if you go ahead and build a company brain, it will likely leak company secrets, which is the big fear that we have about building a company brain anyway, which is this case of intern joins the company and then suddenly gets comp details on everybody situation, right? You want to guard against that. This has been, I guess, pretty much the biggest thing that's been holding us back from just deploying OpenClaw and Hermes all over the place, right? It's also the reason, it's this big opportunity that ClaudeTag had with its recent launch a few days ago, where it was going to be the company brain, but then everybody's like, well, it's not, it doesn't look like it's going to be the company brain, right? So I'm going to talk about what makes it challenging. So before we get into that, let's understand and dissect this company brain business a little bit, right? I'm Tanmay, I'm the CEO co-founder of PromptQL. You can check PromptQL out later, but our background as a team building this is we come from the Hustler GraphQL, the creators of the Hustler GraphQL engine, a very popular open source project in the GraphQL space, where we solved a lot of data access problems. We deployed everywhere from Apple to Meta to JPMorgan, etc. And that gave us a lot of grounding for and a love-hate relationship with data and data security. All right. So I'm going to show you stuff that we've been working on over the last year and what we've learned from that so that you can take that and exercise that and try it out for yourself. And of course, at the end of the talk, happy to exchange notes and see what works or what might not work for you. Over the last year, we've only partnered with a small set of people who've exhibited some spike on scale. It's about 15 to 20 folks so far, and now we're just starting to open it up to other people. But over that course of time, we've looked at three different types of people who have very different needs, right? You have AI-native companies that are willing to just do whatever as long as it works. You have tech-forward companies, right, folks like Instacart, who like best-of-breed technology, right? So they'll move fast. They'll be tolerable to breaking things, but it just needs to be really, really good, right? And then you have Fortune 100 banks who have a fuck-me level of security. Thank God that they do, because they're my bank. I definitely don't want Vibe-coded AI agents running inside a bank, because that's where my money is. So they have a lot of security rules. Thank you so much. But we're deployed in places like those as well, with the beginnings or the frontal lobe of a company brain, right? So we can talk about those learnings. Our own personal usage of building out our company brain, it is about 5,000 pages, so we model it as a wiki. You can model it however you want. You can model it as a set of markdown files on GitHub. You can put it into a, remember, graph frag? You can model it in knowledge graphs. You can do whatever you want. So you can place it wherever you want, but it's about 5,000 interconnected pages for us. Question for you folks. So suppose you had a company brain that was working. It was working well. It was all set up, right? There would be a daily number of updates that would happen to this company brain, right? Because it was learning stuff from everybody in the company, right, from finance to HR to your engineers to everybody. So if you were to plot the daily number of updates happening to the company brain, what would it look like? Would it look like a roughly downwards trend? All of these are random graphs, but would it start and then go down? Would it be steady, going up and down as updates spike? Or would it steadily increase upwards? So think about what would the commit history to your shared skills repo look like, right? How many updates are happening to a healthy company brain, right? Every single day, what does that trend look like? Anybody for option A? Anybody think it's option A? Okay, cool. Option B? Okay. Option C? Oh, that's nice. And so that's... So when I plotted our thing, right, to see what a healthy company brain looks like, if you look at number one, it's basically saying, we had a lot of enthusiasm. We built the company brain on day one, day two. We gave somebody the task and said, build all the shared skills repo, scrape all the Slack, scrape all the emails, build it, and we'll all use it, and then nobody cares, right? Or you have a system which is auto-learning, maybe you have a Hermes that's deployed internally, something like that, where it's steadily adding more and more comments, so it goes up and down, depending on who has enthusiasm, right? And then when I plotted our history over just the last two months, and this is a little outdated now, this is what we got. And I was shocked. I was like, why is it continuously increasing? It's a gentle curve, right? But why is it gently just going up? Why is the number of updates per day increasing? And that was fascinating for me to see, because what I realized was that if you have a system that starts to work, what happens is people start to teach it a lot more. It's like saying, if I taught you the skill for querying data, then tomorrow I'm going to teach you the skill for interpreting that data. And then the day after tomorrow, I'm going to teach you the skill of how to take an action based on that. And then after that, I'm going to figure out how to do A-B testing based on it. So people continuously add more. But because everything is an agent where no amount of learning is perfect, everything has its own steady rate as well, right? So the rates, even your steady rates, keep adding up. And that's what I started to notice in our thing as well. This is early, so who knows if it'll peter out eventually. Maybe it'll start to look more like option B. But in a healthy brain, of course, the overall size keeps increasing. But even your daily updates per day keep increasing as well. So that's a sign of a good brain that you built, right? A healthy brain that you built for your company. Awesome. The use cases for company brains, how we start to analyze how we build a system that won't leak secrets, right? So two use cases. The first use case is there is a company brain. I want to use it in my AI, agent, whatever, to get work done, right? I'll show you an example of that, right? It's like I got an email with a security questionnaire I need to answer from a customer. And I talk to my AI and I'm like, look up the company brain and help me answer this security questionnaire, right? That's a totally valid use case of a company brain. Second, very useful use case, right? Because it's other people's knowledge that is coming to me. Second use case of a company brain is similar to what Cloud Tag is, this idea of multiplayer. And if you've been putting agents inside Slack in places where multiple people can interact with it, it's been using it as a shared AI, right? Like get stuff done. And an example of that could be collaborative incident management, right? So, for example, you want to say, hey, I want to fetch logs. I want to investigate there's an incident, go fetch some logs, investigate the code base, raise the PR, deploy to staging, deploy to prod, set up an alert, right? You want multiple people doing things with the company brain. So those are two use cases of the company brain. One is this shared collaborative knowledge use case. And one is shared AI use case itself, right? Both of those have a huge security problem, right? So to start to secure it, let's define that a little bit more strongly, right? So what exactly is a company brain? And this is my definition of it, right? It's shared context that you'd put in markdown, that you'd put in a set of markdown files, right? And it's access control rules for the different data and tools that you want to access as given to a coding agent. So that's what I'm calling it, because I'm speaking, so I can define whatever I want. That's my definition. So I'm not saying this is knowledge that is pulled into You want multiple people are doing things with the company brain. So those are two use cases of the company brain. One is this shared collaborative knowledge use case. And one is shared AI use case itself, right? Both of those have a huge security problem, right? So to start to secure it, let's define that a little bit more strongly, right? So what exactly is a company brain? And this is my definition of it, right? It's shared context that you'd put in a markdown, that you'd put in a set of markdown files, right? And it's access control rules for the different data and tools that you want to access as given to a coding agent. So that's what I'm calling it, because I'm speaking so I can define whatever I want. That's my definition. So I'm not saying this is knowledge that is pulled into an LLM that will do tool calls, right? It is not an AI that is doing general purpose stuff. It is an AI that is a coding agent that is solving whatever problem you throw at it, right? Similar to a little bit of the previous talk that you folks might have heard, which is this idea of, can we just use a coding agent to solve general problems? It's that, right? So in the most trivial case, if you say, hey, write me a tweet, you're writing a small script that's making an AI call to write a small tweet, right? You probably don't need to do that. The AI itself can just return the tweet back to you. But essentially Claude code being used for everything. Claude co-work is the same architecture. The codex app is the same architecture, which is this realization that you can use coding agents to solve general purpose problems. So we're building the brain for that. We're not building a gigantic knowledge graph, knowledge base for the company and then trying to secure it. That anyway, it doesn't, hasn't worked, won't work. So in terms of how we want to approach designing the company brain, right? Should we build a company brain? To be in an enterprise and you're paid to twiddle your thumbs, then you like this idea of building a company brain because you're like, yes, let me take on a two-year project and I will build the company brain for JP Morgan. That's not going to happen. You can't build a company brain for an organization that's a hundred years old, right? You can barely build it for your own family, right? Which might just be months or years old, right? So the idea and the way that we want to build the company brain is we want each person who does a little bit of the work in the company to own and build their part of the company brain, right? That's the way we should build it. So that's constraint number two that I'm putting. One was the definition of the company brain and second is the approach that we want to take for how a company brain is built. I like this way of phrasing it, which is that we're going to grow a company brain. We're not going to build one, right? We're going to let it come together. The system needs to come together. Otherwise, it's not possible to build. All right. Broadly, we want to let each person self-serve their bit of the company brain. And so these are the various steps that you want to follow. I'll come back to this in more detail if you have time, but let's start with a particular use case, right? So in this particular use case, what I have is this situation where this is the tangible example I want to take for you folks. I got an email, just a security question and example, right? Hey, I got an email from Dave at Stitch Fix and that is a bunch of questions I want to answer, right? So it pulls up my email. It says the email has a screenshot of their security onboarding and then it starts to answer those questions, right? I have no idea how it knew. I was very surprised to see that it answered all of the questions on, hey, this is our trust center. This is how our security stuff looks. They have a gateway, right? It does something. All of this is coming from the company brain, right? Which is the answer to that. And then go ahead and I'm like, hey, just go ahead and send this. I like this draft. Go ahead and send this draft to Dave, right? And then it goes and sends that email. Really simple example of what I want to do. Now, the challenge here, right? And the issue is how do we build a system, right, which somebody else can contribute to that a third person uses? How did this knowledge about what our security thing is come in? Presumably somebody else had been working on the same security questionnaire, right? So they had, let's say, Hermes agent or whatever. They were working on it. You auto-saved some memory. Maybe somebody wrote down a skill. Somehow that piece has to come to my AI agent. How are we going to make that possible, right? Now, let's try obvious thing number one, right? Which is that everybody writes shared skills for each other on GitHub. So the first time the security questionnaire was answered by your security person, everybody visualize your security and compliance person in your head, right? Now, imagine that they, after answering the questionnaire. It sucks to answer questionnaires. After answering this gigantic Excel sheet of a questionnaire, they then went to GitHub and updated a shared skill, right? Many of you are fortunate to work with people who are modeled after our Lord and Savior Christ, who are so nice, who will go and update shared skills in a GitHub repo, right? Most people will not. Nobody is going to write skills for another person in GitHub. That is not something that is natural to us, right? In the day-to-day of doing work, we don't suddenly decide that this might be really useful for somebody else I don't even know, I'm not connected to in this situation in the future. Not happening. I can barely get it to curate my own memory and my context. I do not have the time to send it to somebody else, to write it down for somebody else. Second, instead of having a company brain, why don't you do a team brain? Why don't you all just use one shared? Why doesn't the security team use one more shared silo where you can do this, right? So build an agent and have it save to memory itself, right? And that's the architecture that I'm guessing a lot of you folks have with maybe something like a Hermes added to Slack. Does anybody have a team brain situation going where you have an AI that multiple people use that auto-saves memory and auto-adds context? Does anybody have a skill that does that already, just for a small team? One. Anybody else? Okay. Okay, a few of you have that. That's cool. This is nice, but the problem is it's still not a company brain because it's still isolated, right? So it's one more silo, right? For example, if this gets like claw tag, it has a per-channel memory, right? So in every channel it gets saved, but now it's another silo in that one channel, right? So now it's again locked into one place that can't be used anywhere else. So if somebody got added to the channel, it would work, but otherwise it wouldn't work, right? And so this is the third option. The third option is saying all context goes into a single shared wiki. A wiki is a set of markdown files and markdown files can link to each other. So imagine a gigantic folder. The folder has lots of markdown files, right? And markdown files can link to each other. So all context, instead of saving it inside a folder or siloing it, you put it in a markdown file, the equivalent of a markdown file, and you let it link with each other. The second thing that you do is you allow each file to have scopes on who can have read-write access to that file. The third thing that you do, which is the most important, you don't let the agent auto-add the memory. You don't let it auto-add, because if it auto-adds, you have no idea what happened, right? We're back to the same world where some stuff is getting added, and as long as you are in that agent's memory, you're lucky, right? So the third thing that you do is instead of letting the agent auto-add, do something that allows your agent to suggest what is added with what scopes, and then have the human accept or reject. So it's not as heavy as GitHub, where I have to go and write this, update a shared skill, do a PR review, and then get it merged. But it's also not as YOLO as the memory just being auto-written by the agent, right? It's the scopes on who can have read-write access to that file. The third thing that you do, which is the most important, you don't let the agent auto-add the memory. You don't let it auto-add, because if it auto-adds, you have no idea what happened, right? You can't. We're back to the same world where some stuff is getting added, and as long as you are in that agent's memory, you're lucky, right? So the third thing that you do is, instead of letting the agent auto-add, do something that allows your agent to suggest what is added with what scopes, and then have the human accept or reject. So it's not as heavy as GitHub, where I have to go and write this, update a shared skill, do a PR review, and then get it merged. But it's also not as YOLO as the memory just being auto-written by the agent, right? It's the sweet spot where, while you are working, you pop it up, suggest the right scopes, and let somebody add it. So now what happens is, with this very simple addition, right, you are able to let people add to a gigantic wiki, but you let that person take on responsibility for what they can see or not. So if I'm adding something to the finance wiki, I want to make sure I'm adding something that's sensitive. I want to make sure it has a finance scope. If I'm adding something that's personal, I want to make sure that that's personal scope. Let me show you an example UX of what that might look like. This is what we do. This is a recent email that I got from one of our sales reps adding me onto a call. I looked at that email, helped answer it, and then I got a little box that suggested a bunch of bullets that told me what it's going to add. Right? And when I hit add to wiki, now it's much easier for me to review what is getting added. I don't care. I don't care if it gets added into this markdown file, that markdown file, what links. The agent takes care of that. What I care about is, are these facts correct? If these facts are correct, I'm going to hit add to wiki and I'm going to be done, right? And during the time of add to wiki, I can choose what scopes need to be added per wiki page or not, right? So each wiki page itself can get a certain set of scopes that you want to decide who gets access to what, for example, right? So, for example, my email, this is the wiki page that I have for my emails and how my emails are prioritized, and I can now decide who gets access to this, who are the owners for this, and what the RBAC for this is. So whatever the system looks like is up to you folks, but the core idea is that you want to get the agent to suggest a change instead of doing the change. All right, so two rules. One, make sure that everything goes into one company-wide wiki. Don't back down from this rule. Second, make sure that, as a part of that, every change is backed by a human's name. Nothing should be allowed inside the wiki that is Claude added this, or your AI agent added this, or Hermes added this. No, Tanmay added this. That name needs to be there so that you can tie it back to this is the person who screwed up and allowed everybody to see everybody's comp, right? And whatever. Now you can take remedial action, right? Whatever that is. Put that on a PIP. You didn't know how to edit a wiki. So that is very, very important. And rule number two, once you decide that, you can then go to the second scope of okay, you've got to make it easy for them to do that, which is where this business of scopes comes in, where you want to scope each file according to who gets access. Build a system around it. This is what an architecture diagram of that looks like, where you have users. Users talk to the agent. Agent, when it's reading context, uses that particular user's claims, right? So if I am reading something for solving a finance problem, it's using the finance claim to read as me, because I had access to the finance wiki so I can read it. And that is done every single time, right? So the agent is always using the user's credential to read the right part of the wiki. All right. I am fairly out of time for the second use case. So what I'm going to do is give you a quick flavor of the second use case, but extend this idea. This is the daddy use case. This is a big daddy use case. This is a really complicated use case because now it's not just one person answering an email. It's a bunch of us using the shared context to solve a problem with various different escalation, privilege levels at the same time, right? And these are the interactions in AI where the most amount of company brain knowledge is created, right? For example, I'm going to show you a quick real-life example of what it looks like for us. So this is a case from an SRE situation where somebody was like, hey, our auto-learning, our wiki learning, was failing. It wasn't working. What's going on, right? And then it starts doing the investigation, and it sucks because it didn't have a skill. It failed. So it's like, bro, don't do this. Please use this OpenTelemetry span name. Use an OpenTelemetry span name. It did a slightly better job, but it was still really slow. So he looked at the code and he's like, oh, you're using a query. You're a dumbass. This is Opus 4.5. Don't do this, right? So then he's like, don't use a query. Use an equals-to query, right? And then it does an equals-to query and it surfaces some details, and then he says, oh, dig deeper into this. And it says, whatever, this is a line of code where the error is coming from. Simple stuff, right? This is now where it surfaces some knowledge and says, aha, I learned that I should use equals-to and not like, right? I learned that if you have a custom prefix added to wiki page names, it can cause issues, right? So it offers these learnings that you can choose to accept. So he dug in deeper into what the problem was. Somebody else joined the conversation, right? And said, the technical decision that we've made here is wrong. Why is this happening? And now two people start to have an argument, right? They have an argument saying, hey, it should not be like this. It should be like this. But why is it like this? But it should be like this, right? That argument creates knowledge because the actual problem was that somebody made a technical decision that was not documented, right? When they decide to fix that issue and they observe that that is indeed the root cause, and they decide that this is the way it's going to be fixed. Hey, we should remove this prefix that's causing a problem. Whatever the thing is, that creates the highest-quality context to be added to your brain. Because the previous suggestion was to say, pages should not, pages have a prefix. But the fact that pages have a prefix is a problem, right? So now the thing that you're documenting in the brain is pages should not have a prefix. If they have a prefix, it can cause lookup issues in prod. This happens when multiple people talk to each other, right? And solve problems together. This is what happens in a Slack thread when two people talk to each other and solve a problem. It creates the highest-quality context. And so that's what you want here. But the challenge is that the privilege escalation around this becomes very, very serious. If you're building an agent that can do everything surrounded by multiple people, that's scary. Because the engineer was allowed to do the PR work, but now I can use the same agent to deploy to prod. That's too scary. I can't have a conversation where I debug and deploy securely, right? Especially if you're in a bank, right? The people who are debugging, deploying to staging, setting up an alert, and deploying are not the same. But being the same has a lot of value because that's where all the knowledge is, right? And so that brings us to the second architecture, which I'm not going to get into too much detail with. But think of it as the same idea where user credentials and claims were used to read context. Instead of that, also use user credentials, right, when the code is executing tools. So never store credentials in the sandbox. Instead, at the HTTP layer, at the SQL layer, inject the user's credentials, allowing the AI to behave as the human in a particular interaction, right? So there are interesting details here. But that is what allows a shared AI to work