# Your company brain will leak secrets: how we stopped it for big banks — Tanmai Gopal, PromptQL AI Engineer · 2026-09-03 Tanmai Gopal explains how to build a company brain: a single shared wiki of markdown files holding all context, with per-file read/write scopes. The agent proposes facts and scopes; a human accepts or rejects each change, with their name attached so leaks have an owner. Two use cases: personal recall (security questionnaire) and multiplayer debugging. Credentials are injected per user at the HTTP and SQL layers, never stored in the sandbox. Keep the summary between 500 and 800 characters — over that, it's rejected outright. ## Questions this episode answers ### What does a healthy company brain's daily edit curve look like? Tanmai Gopal expected a burst of enthusiasm followed by neglect, but plotting his own brain showed daily updates steadily increasing. His reading: a system that works gets taught more — first querying data, then interpreting results, then acting — and each skill adds its own steady rate of corrections, so a rising edit count signals health. [5:15](https://aiengineer.podhood.com/62957d30-1948-463b-8f64-89aa14a94fb4?t=315000) ### Why won't people write shared skills in GitHub for each other? Tanmai Gopal argues nobody naturally documents knowledge for a colleague they have never met and aren't connected to. After answering a painful security questionnaire, your security person will not go update a shared skill repo; people can barely curate their own memory and context, so this approach fails in day-to-day work. [12:43](https://aiengineer.podhood.com/62957d30-1948-463b-8f64-89aa14a94fb4?t=763000) ### What is the third option for structuring a company brain that doesn't leak? Tanmai Gopal puts all context in one company-wide wiki of linked markdown files, gives each file read/write scopes, and refuses to let the agent auto-add memory. The agent suggests facts and scopes, a human accepts, and the change carries that person's name so any leak has an owner to hold responsible. [14:55](https://aiengineer.podhood.com/62957d30-1948-463b-8f64-89aa14a94fb4?t=895000) ### How do you secure multiplayer agent use, like collaborative incident debugging? Tanmai Gopal says never store credentials in the sandbox. Instead, inject each user's credentials at the HTTP and SQL layers when tools execute, so the AI behaves as the human in each interaction. This lets people with different privilege levels — debugging, deploying to staging, deploying to prod — share one context safely. [23:43](https://aiengineer.podhood.com/62957d30-1948-463b-8f64-89aa14a94fb4?t=1423000) ## Key moments - **[0:00] Why brains leak** - [0:13] Tanmai Gopal: if you build a company brain, it will likely leak company secrets - **[1:06] Hasura to PromptQL** - [1:13] PromptQL's creators built the Hasura GraphQL engine, deployed at Apple, Meta and JP Morgan - **[2:03] Customer types** - [2:12] Three customer types for a company brain: AI-native startups, tech-forward firms, and Fortune 100 banks - **[3:14] Modeling the brain** - [3:31] PromptQL's own company brain is about 5,000 interconnected wiki pages - **[3:41] Edit curve poll** - [5:15] Q: What should a healthy company brain's daily edit curve look like? - **[5:16] The climbing line** - **[6:37] Two use cases** - [8:35] Tanmai Gopal was shocked his company brain's daily edits kept climbing — a trusted system gets taught more, not less - **[9:50] Grow, don't build** - **[11:09] Security questionnaire** - [11:11] Two company brain use cases: personal recall for a security questionnaire, and multiplayer incident debugging - [12:03] Q: What is a company brain? Shared markdown context plus access-control rules for a coding agent - **[12:33] GitHub skills** - [12:43] Tanmai Gopal: nobody writes shared skills in GitHub for a colleague they have never met - [13:54] A team brain that auto-saves its own memory is just another silo, like per-channel memory - [14:55] The fix: one company-wide wiki of linked markdown files, per-file read/write scopes, and no agent auto-writes - [18:10] Every wiki change must carry a human's name, never 'Claude added this', so a leak has an owner - [20:00] Multiplayer debugging: two engineers arguing in Slack creates the highest-quality company brain knowledge - [23:10] Never store credentials in the sandbox — inject each user's credentials at the HTTP and SQL layers ## Speakers - **Tanmai Gopal** (guest) ## Topics Agent Memory ## Mentioned PromptQL (company), Claude (product), Codex (product), GitHub (product), Hasura (product), Hermes (product), Slack (product) ## Transcript ### Why brains leak **Tanmai Gopal** [0:13] Alright, um, everybody can see? Hey, everybody. Um, thank you for being here. I'm going to talk about, um, the fact that if you go ahead and build a company brain, it will, um, likely leak company secrets, which is kind of the big fear that we have about building a company brain anyway,right? Which is this case of, like, intern joins the company and then suddenly gets, like, comp details and everybody kind of situation,right? You want to, you want to guard against that. Um, this has kind of been, I guess, pretty much the biggest thing that's been holding us back from just deploying Open Claw and Hermes all over the place,right? It's also kind of the reason it's like this big opportunity that Claude Tag had with its recent launch a few days ago, where, like, it was going to be the company brain, but then everybody's like, well, it's not, um, it doesn't look like it's going to be the company brain,right? So I'm going to talk about kind of what makes it challenging. So before we get into that, let's, let's kind of understand and dissect this company brain business a little bit,right? Um, I'm Tanmai, I'm the CO cofounder of PromptQL. ### Hasura to PromptQL **Tanmai Gopal** [1:13] Um, you can check PromptQL out, um, later, but, uh, the, our background as a team building this is, we come from, um, the Hasura Graph, we're the creators of the Hasura GraphQL engine, which is a very popular open source project in the GraphQL space, uh, where we solved a lot of data access problems. Um, we deployed everywhere from, like, Apple to Meta to JP Morgan, etc. Uh, and, um, and that kind of gave us a lot of these, this grounding, uh, for, uh, and, and, you know, kind of like a love-hate relationship with, uh, data and data security. Um, alright. So I'm going to show you stuff that we've been working on over the last year and kind of what we've learned from that so that you can kind of take that and exercise that and try it out for yourself. Um, and of course, at the end of the talk, happy to exch- kind of exchange notes and see what works or what might, what might not work for you. Um, over the last year, we've only partnered with a small set of people who've exhibited some kind of spike on scale. ### Customer types **Tanmai Gopal** [2:12] Um, 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 kind of looked at three different types of set of people with very different needs,right? You have AI-native companies that are willing to just do whatever as long as it works. You have kind of tech-forward companies,right, folks like Instacart, who, um, like best-of-breed technology,right? Um, 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, uh, who have, like, a fuck-me level of security. Uh, 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. Um, so they have a lot of security rules. Uh, thank you so much. Uh, but we're deployed in places like those as well, um, with kind of the beginnings or, like, the frontal lobe of a company brain,right? So we'll kind of talk about those kind of learnings. Our own personal usage of kind of, uh, building out our company brain, um, it kind of is about 5,000 pages. So we model it as a wiki. Uh, you can model it however you want. You can model it as a set of markdown files on GitHub. ### Modeling the brain **Tanmai Gopal** [3:18] You can put it into a, remember, Graph RAG? Uh, you can model it in a know you can model it in knowledge, in knowledge graphs. You can do whatever you want. Um, so you can, you can place it wherever you want, but, like, it's about 5,000 interconnected pages for us. Um, question for you folks. So suppose you had a company brain that was working. It was working well. It was all set up,right? Um, there would be a kind of daily number of updates that would happen to this comp to this company brain,right? ### Edit curve poll **Tanmai Gopal** [3:44] Because it was learning stuff from everybody in the company,right? From finance to HR to, um, your engineers to everybody. So if you were to plot the daily number of updates happening to the company brain, what would it sort of look like? Would it sort of look like, uh, roughly downwards? And, like, all of these are, like, random graphs, but would it, would it sort of, like, start and then go down? Would it kind of be steady going up and down as updates spike, or would it kind of steadily increase upwards? Um, so to kind of think about, like, what would the commit history to your shared skills repo look like,right? How many updates are happening to a healthy company brain,right, um, every single day? What does that trend look like? Um, anybody for option A? Anybody thinks it's option A? Okay, cool. Uh, option B? Okay. Option C? Oh, that's nice. Um, and, and, and so that's so when I kind of plotted our thing,right, to see what a healthy company brain looks like, um, 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. Somebody 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 kind of steadily adding more and more comments. It kind of goes up and down depending on who has enthusiasm,right? Um, and then when I plotted our history over just the last, uh, two months, and this is a little bit outdated now, this is what we got. And I was kind of shocked. I was like, "Why is it continuously increasing?" ### The climbing line **Tanmai Gopal** [5:30] Like, 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 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 " So people, like, will continuously add more. But because everything is an agent where no amount of learning is perfect, everything has its own kind of steady rate as well,right? So the rates kind of even your steady rates kind of 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 kind of peter out eventually. Maybe it'll start to look more like option B. But a healthy brain, of course, the overall size keeps increasing, but even your daily updates per day kind of 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 brain is 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? ### Two use cases **Tanmai Gopal** [6:55] Um, and 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 are, that is coming to me. Second use case of a company brain is kind of similar to what, uh, Claude Tag is, is a, this idea of multiplayer. And if you've been putting agents inside Slack in places where multiple people can interact with it, it's kind of being using, using it as a shared AI,right? To s like, get stiff stuff done. Um, and an example of that could be collaborative incident management,right? So for example, you want to say, like, "Hey, I want to fetch logs. I want to investigate the there's an incident. Go fetch some logs. Investigate the code, codebase. Raise the PR. Deploy to staging. Deploy to prod. Set up an alert,"right? You want, like, multiple people are doing things with the company brain. So those are kind of two use cases of the company brain. One is kind of this, like, shared collaborative knowledge use case, and one is, like, shared AI use case itself,right? Both of those have a huge, um, security kind of problem,right? Um, so to start to secure it, let's kind of 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 for, um, because I'm speaking, so I can define whatever I want. Um, 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 a 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? Kind of similar to the, um, uh, a little bit of the previous talk that you folks might have heard, which is this idea of, like, "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, like, return the tweet back to you. But, like, essentially, Claude code being used for everything. Claude cowork 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 gigantic knowledge graph, knowledge base for the company and then trying to secure it. That anyway doesn't, hasn't worked, won't work. Um, so in terms of how we want to approach designing the company brain,right? Should we build a company brain? So if you're 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." ### Grow, don't build **Tanmai Gopal** [10:03] That's not going to happen. You can't build a company brain for an organization that's, like, 100 years old,right? You can barely build it for your own family,right? Which might just be months or years old,right? So, 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 kind of constraint number two that I'm putting. One was the definition of the company brain. And second is how the approach that we want to take for how a company brain is built. I like kind of 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, like, let it, let it come together. The system needs to come together. Otherwise, it'll, it'll, it's not, it's not possible to build. Alright. Um, broadly, we want to let each person self-serve their bit of the company brain. Um, and so these are kind of, like, the various steps that you want to follow. I'll come back to this in more detail if we have time. But let's start with a particular use case,right? So in this particular use case, what I have is this kind of situation where this is kind of the tangible example I want to take for you folks. Um, I got an email. ### Security questionnaire **Tanmai Gopal** [11:14] This is a security questionnaire example,right? "Hey, I got an email, um, from Dave at Stitchfix, um, and that has a bunch of questions I want to answer,"right? So it pulls up my email. It says the email is a screenshot of their security onboarding. And then it starts to kind of answer those questions,right? Um, I have no idea how it knew. I was kind of very surprised to see that it answered all of the questions on, like, "Hey, this is our trust center. This is how our security stuff looks. Um, they have a gateway,right? It does something." All of this is kind of coming from the company brain,right? Which is the answer to that. And then kind of 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 goes and sends that email. Really simple example of what I want to do. Now, the challenge here,right? And the issue is that how do we build a system,right, which somebody else can contribute to that a third person kind of 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, a 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, um, let's try obvious thing, uh, number one,right? Which is that everybody writes shared skills for each other on GitHub. ### GitHub skills **Tanmai Gopal** [12:43] So the first time the security questionnaire was answered by your security person, everybody visualized, like, 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. Like, that is not, that is not something that is natural to us,right? In the day-to-day of doing work, we don't suddenly decide that, "Ooh, 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, like, curate my own memory and my context. I do not have the time to send it to somebody else, um, 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 kind of use one more shared silo where you can do this,right? So build an agent and have it kind of saved to memory itself,right? Um, and that's kind of the architecture that I, I'm guessing a lot of you folks have with maybe something like a Hermes added to Slack. Does anybody have kind of a team, team brain situation going where you have an AI that multiple people use that auto-saves memory and auto adds context? Does anybody have kind of, like, 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. Um, this is nice, but the problem is it's still not a company brain because it's still isolated,right? So it's like one more silo,right? Like, for example, um, if this gets, like, with Claude Tag, um, it, 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 that channel, it would work, but otherwise, it wouldn't work,right? Um, 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, all context, instead of saving it inside a folder or siloing it, you put it in a markdown file, or 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? You can't we're, we're back to kind of the same world where some stuff is getting added, and as long as you're 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 kind of being auto written by the agent,right? It's kind of the sweet spot where while you are working, you pop it up, suggest theright 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 there's personal scope. Let me show you an example UX of what that might look like. This is what we do. So this was a recent email that I got, um, from one of our sales reps adding me onto a call. I looked at that email, helped answer it, and then, and then I got a little box that suggested a bunch of bullets that told me what is going to add,right? And when I hit add to wiki, and, and so 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 that the agent takes care of. 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, 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. Alright. 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, like, 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, like, "Your AI agent added this," or, "Hermes added this." No. Tanmai added this. That, that name needs to be there so that you can tie it back to, "This is the person who screwed up and, like, allowed everybody to see, like, everybody's comp,"right? And, like, whatever. Now you can take remedial action, uh,right? Whatever that is. Put them on a pip. Um, you didn't know how to edit a wiki. So, so that is very, very important. And rule number two, once you decide that, you can then go to the second scope of, like, okay, you've got to make it easy for them to do that, which is where this business of scopes come in, where you want to scope each file according to who gets access. You need to build kind of a system around it. This is what an architecture diagram of that looks like, where you have users, um, users talk to the agent. Uh, 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 theright part of the wiki. Um, alright. I'm, um, I'm 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, like, this is the 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, like privilege levels at the same time,right? And these are kind of the these are the these are the interactions 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, um, what it looks like for us. Um, so this was a case from an SRE situation where, um, somebody was like, "Hey, our auto learning, our wiki learning, uh, fairly meta, 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 tries, like, "Bro, don't do this. Please use this OpenTelemetry span name." It used 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 like query. You're, you're a you're a dumbass. This is Opus 4.5. Um, like, like, don't do this,"right? So then he's like, "Don't use a like query. Use an equals-to query,"right? And then it does an equals-to query, and it surfaces some details, and it 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? Um, so it offers these learnings that you can choose to accept. So he kind of went dug in deeper, um, into what the problem was. Somebody else joined the conversation,right? And. **Guest** [22:00] Yes. The technical decision that is made here is wrong. Why is this happening? **Tanmai Gopal** [22:06] 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, whatever the thing is, that creates the highest quality context to be added to your brain because the previous suggestion was to say, uh, 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. But and so, so that's kind of what you want here. But the challenge is that the privilege privilege escalation around this becomes very, very serious. If you 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? Like, the people who are debugging, deploying to staging, setting up an alert, and deploying are not the same. But, but being the same has a lot of value because that's where all the knowledge is,right? And so that kind of 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 of that, 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? Um, so there's interesting details here. Um, but that is what allows a shared AI to work with shared context,right? And those are kind of the two, um, key pieces to work with. So I would summarize, and you'll this architecture is not particularly complicated, but it's very simple to work back from these two rules. Do not store credentials in the cloud sandbox. And second, virtualize all interactions with real data. Proxy it, virtualize it, whatever word you want to use, and let users control them. So the user who adds a particular tool should control who gets access, uh, to that particular tool. So you can derive this entire thing if you just kind of follow these four principles and work backwards from that. There's only one architecture that is possible that makes sense, uh, in how you manage context and what constraints you set up and how you manage tools and what security rules you set up. Um, that is my time. Um, and, and so, um, happy to chat more, um, after the talk. Um, we have a booth as well, so happy to chat more through that on what the nuances inside this architecture are. I'm Tanmai Go on Twitter. Um, we're called PromptQL. Um, do check us out. Um, at the end of the day, um, with the AI engineering community, we're going to do a product launch. Uh, and so I would love to share that, folks. Share that with everybody. I'm going to take a picture with everybody on stage so that I can, uh, I can share that. And so let me let me do that while I'm here. Alright. Do folks want to say cheese? Thank you so much. Um, so watch out for that. Um, it's our approach to, um, Claude tag, which is PromptQL tag, which is very similar to, uh, with the ideas that we chatted about here, except that you're not stuck to Claude. You can use GLM, and you can use GPT, and then SOL comes out, and we can use that and have a lot of fun. Um, so do check that out. And otherwise, I'll see you folks soon. --- This library is powered by PodHood (https://podhood.com), the podcast website platform.