Grow a Company Brain. Never Let It Write Itself.

AI Engineer · Tanmai Gopal, PromptQL · Video ID 0uC6u0lJJl4 · September 3, 2026 · 26:25

An intern joins, and compensation details appear in the agent. Tanmai Gopal treats that scene as the actual deployment blocker, not a thought experiment. It is, he says, what has been holding back putting OpenClaw and Hermes everywhere. It is also why a recent Claude Tag launch looked like it would become the company brain, then did not. The leak is not an argument against a shared brain. It is an argument against letting the brain write itself.

Gopal is co-founder of PromptQL. Before that, his team built the Hasura GraphQL engine, an open-source data-access layer he says ran at Apple, Meta, and JPMorgan. He calls the residue a love-hate relationship with data security. The talk is a vendor talk: over the last year PromptQL partnered with a small set of people, about 15 to 20 folks who had already shown some kind of spike at scale, and is now opening up. There is a booth, and a launch of Prompt Tag as PromptQL’s approach to Claude Tag. Treat the bank deployments, the 5,000-page wiki, and the rising edit curve as speaker-reported. The architecture he is willing to defend in a Fortune bank is the part that matters.

Three customers, one intern problem

The year of deployments sorted into three appetites. AI-native companies will do whatever works. Tech-forward companies — he names Instacart — want best-of-breed, will tolerate breaking things, and still need the result to be really good. Fortune banks have what he is grateful to call serious security, because that is where his money lives. He does not want vibe-coded agents running inside a bank. PromptQL is deployed there anyway, he says, with the beginnings of a company brain: the frontal lobe, not the whole organ.

Their own brain is about 5,000 interconnected pages, modeled as a wiki. He is not precious about the store. Markdown files on GitHub, a memory graph, RAG, a knowledge graph — put it wherever. The load-bearing property is interconnection, not the brand of database.

A healthy brain edits more every day

He asks the room to plot daily updates to a working company brain — finance, HR, engineering, everybody teaching it — the way you would read commit history on a shared-skills repo. Option A slopes down after a burst. Option B oscillates with whoever still has enthusiasm. Option C climbs.

Option A is the familiar funeral. Day one, day two: assign someone to build the shared-skills repo, scrape Slack, scrape email, stand it up. Then nobody cares. Option B is an auto-learning agent, maybe an internal Hermes, adding comments in fits that track mood. When he plotted PromptQL’s own history over the previous two months — a chart he flags as a bit outdated — he got a gentle, continuous climb, and it shocked him.

His reading: a system people trust gets taught more, not less. Teach it to query data, then to interpret the result, then to act, then to A/B-test the action. Each new skill is an agent skill, so no amount of learning is perfect, and each one carries its own residual correction rate. Those steady rates stack. Overall size grows, which everyone expects. Daily updates grow too. That stacked correction, not a one-time ingestion, is what he is willing to call health.

He does not overclaim the curve. This is early. It might peter out and start looking like option B. A rising edit count is the sign he has now, not a law he can prove.

The brain is for a coding agent, not a knowledge base

Two jobs create the leak surface. First, a person uses the company brain inside their own agent: a customer security questionnaire lands, the agent looks it up, drafts the answers. Second, several people use a shared agent at once — the multiplayer case he associates with Claude Tag, and with agents dropped into Slack. Collaborative incident management is the example: fetch logs, investigate the codebase, raise a PR, deploy to staging, deploy to prod, set an alert. Shared knowledge in one case. Shared AI in the other. Both, he says, have a huge security problem.

His definition, offered as his because he is the one speaking: a company brain is shared context in a set of markdown files, plus access-control rules for the data and tools given to a coding agent. It is not knowledge stuffed into an LLM that then makes tool calls. It is not a general-purpose chatbot. It is the same bet as Claude Code used for everything, Claude Cowork, and the Codex app: a coding agent that will take whatever problem you throw at it. The trivial case is “write me a tweet.” You could have the agent write a script that calls another model. You do not need to. The agent can just return the tweet. The brain is for that architecture.

What he refuses to build is a gigantic company knowledge graph, then a security layer around it. That, he says, has not worked and will not work.

You cannot build one. You can grow one.

If you are paid to twiddle your thumbs in an enterprise, a two-year project titled “build the company brain for JPMorgan” sounds like work. Gopal’s claim is that it will not happen. You cannot build a brain for a hundred-year-old organization. You can barely build one for your own family, which might be months or years old. Constraint two, after the definition: each person who does a bit of the work owns and builds their part. Self-serve, or it does not come into existence.

We're going to grow a company brain. We're not going to build one.

Dave at Stitch Fix, and the knowledge that had to travel

The tangible pull-through is an email from Dave at Stitch Fix. It includes a screenshot of their security onboarding. The agent pulls the mail, answers from the company brain — this is the trust center, this is how security looks, they have a gateway — and Gopal, surprised it knew, tells it to send the draft. Simple, until the question underneath: how did that security knowledge get into his agent?

Presumably someone else had already suffered the questionnaire. Maybe they had a Hermes agent. Maybe memory auto-saved. Maybe somebody wrote a skill. That piece has to arrive in a third person’s agent without becoming everyone’s compensation spreadsheet.

Shared skills on GitHub

Obvious move one: everybody writes shared skills for each other in GitHub. Visualize the security and compliance person. They have just finished a gigantic Excel questionnaire, which already sucks. Now they open GitHub, update a shared skill, and write it for a colleague they have never met, in a future they cannot see.

“Many of you are fortunate to work with people who are modeled after our Lord and Savior Christ,” Gopal says. Most people will not. Nobody is going to write skills for another person in GitHub. It is not natural in the day-to-day of doing work. He can barely curate his own memory. He does not have time to write it down for a stranger.

A team brain is another silo

Obvious move two: forget the company brain, give the security team one shared agent that saves to its own memory. He guesses a lot of the room already has this — Hermes added to Slack, an AI several people use, auto-saving context. A few hands go up. Nice, he says, and still not a company brain, because it is still isolated. One more silo. Claude Tag, in his telling, saves per-channel memory: it works if you were added to that channel, and is locked there if you were not.

One wiki, scoped files, no silent writes

The third option is the one he will not back down from. All context goes into a single shared wiki: a gigantic folder of markdown files that link to each other. Each file carries scopes for who can read and write it. And the most important rule:

You don't let the agent auto add the memory.

If it auto-adds, you have no idea what happened. You are back in the world where some stuff is getting written, and you are lucky if you happen to be inside that agent’s memory. Instead the agent suggests what to add, and with what scopes. A human accepts or rejects.

That is the sweet spot he is selling: not as heavy as writing a shared skill, opening a PR, and waiting on review; not as yolo as the agent auto-writing memory. While you are already working, a box pops up. You review. You add.

The human is not reviewing which markdown file received the paragraph, or which links the agent chose. The agent can take care of placement. The human is reviewing whether the facts are correct, and which scope they belong to. Finance wiki, finance scope. Personal note, personal scope. The person who can see the thing takes responsibility for the write.

He shows a sales-rep email adding him to a call. After he helps answer it, a box of suggested bullets appears. If the facts are right, he hits Add to Wiki and chooses scopes per page. His example of a scoped page is the wiki for how his emails are prioritized: who gets access, who the owners are, what the access control is. The system’s surface can vary. The core idea cannot: get the agent to suggest a change instead of doing the change.

Every change carries a human name

Two rules, and he tells the room not to back down from the first: everything goes into one companywide wiki. Second: every change is backed by a human’s name. Nothing in the wiki that says Claude added this, or the AI agent added this, or Hermes added this. Tanmai added this. The name has to be there so that if everybody’s compensation becomes visible, you can tie it to the person who allowed the write — remedial action, a PIP, “you didn’t know how to edit a wiki.” Anonymous agent writes are how the intern problem becomes unaccountable.

Once those rules exist, make the scoped write easy. The read path matches. Users talk to the agent. When the agent reads context, it uses that user’s claims. Solving a finance problem with the finance wiki uses the finance claim, because that user had access. Every time. The agent always reads as the user, with the user’s credential, against the part of the wiki that credential is allowed to see.

The argument is the knowledge. That is also the breach.

He is short on time for the second use case and still calls it the big one. It is no longer one person answering an email. It is several people, with different privilege levels, using shared context at the same time. These are the interactions, he says, where the most company-brain knowledge is created.

The live example is an SRE thread about their own wiki auto-learning failing — “fairly meta.” Someone asks what is going on. The agent starts investigating, has no skill for it, and fails. A human tells it to use a specific OpenTelemetry span name. Slightly better, still slow. The human looks at the code: it is using a LIKE query. “You’re a dumbass. This is Opus 4.5.” Switch to equals. The equals query surfaces details, then a line of code where the error is coming from. The agent offers learnings to accept: use equals, not like; a custom prefix on wiki page names can cause issues.

Then a second person joins and says the technical decision is wrong. Two people argue. That argument creates knowledge, because the actual problem was an undocumented decision. The first suggested write was that pages have a prefix, and that this can be a problem. After the argument, the thing worth storing is different: pages should not have a prefix; if they do, lookup issues show up in production. Highest-quality context, he says, looks like a Slack thread in which two people solve a problem together. The wiki should receive the conclusion of the argument, not the agent’s first guess.

The same conversation is where privilege escalation gets serious. An engineer was allowed to do the PR work. The same agent can now be used to deploy to prod. That is too scary. You cannot have a conversation that both debugs and deploys securely — especially in a bank, where the people who debug, deploy to staging, set an alert, and deploy to production are not the same people. And yet being the same has a lot of value, because that is where the knowledge is. He does not reconcile the contradiction. He names it, and changes the credential path.

Credentials never sit in the sandbox

The second architecture is the first idea applied to tools. User credentials and claims were already used to read context. Also use them when code executes tools. Never store credentials in the sandbox. At the HTTP layer and the SQL layer, inject the user’s credentials so the AI behaves as that human, in that interaction. That, he says, is what allows a shared AI to work with shared context.

Work backwards from a short list and, in his view, only one architecture survives. Do not store credentials in the cloud sandbox. Virtualize every interaction with real data — proxy it, virtualize it, whichever word you prefer — and let users control those interactions. The person who adds a tool controls who gets access to that tool. Combine that with one companywide wiki and a human name on every write, and the read path, the write path, and the tool path all run as a particular person. The implication is that there is no ambient agent identity left to leak through — that last step is the reading, not a property he measured.

Prompt Tag is the product. The constraint is the write.

He runs out of time, points to the booth, and names himself on Twitter. PromptQL’s launch for the AI engineering community is Prompt Tag: the same ideas he just walked through, aimed at Claude Tag, except not stuck on Claude. GLM, GPT, and whatever arrives next — he mentions Soul — can sit underneath.

Strip the launch and the remaining claim is sharp. A company brain that is a two-year knowledge-base program will not get built. A company brain that is a GitHub skills repo will not get written. A company brain that auto-saves in a channel will not travel, and will not have an owner when it does. The design that can stand in front of a bank is smaller and stricter: grow one wiki of linked markdown, scope every file, let the agent propose, require a human name on the accept, and keep credentials out of the sandbox so the intern never inherits someone else’s claims. If daily edits start climbing, that is not hygiene debt. In Gopal’s telling, that climb is the system working — and the reason the write path has to stay human.