Y Combinator Startup Podcast
00:29:42 · Paul Copplestone, Garry Tan
[00:29:42] S0: Oh, man. I quite like that. [00:29:43] S1: We talked about before this, like, there's just a bunch of things that you've been doing that, like, really make agents like you better, like error messages. You know. You know, what was that key insight? And, like, are there a bunch of other things that you're doing that kind of obvious on the one hand, on the other hand, like, nobody's doing yet? [00:30:01] S0: Yeah. So, like, the error messages... Yeah. I was at a DevToom Center last night, I was surprised that this wasn't so obvious. But we really dug into our error messages so that you can take a use case like, oh, I want to build an application. And generally, like, developer tomb error messages of like 500 something basic. And you just know there's a problem, but now you actually want the agents to, like, remedy themselves. So inside the error messages, you are literally telling them how to fix this error or to go and read some docs to fix the error. So a lot of it is just picking your use case and just trying to do these loops on improving your own error messages so that you can one shot basically anything that you want. [00:30:45] S1: Yeah. That makes sense. Basically, you know, if you're being used by an agent, the agent will encounter a error message. In the past, a human would have to go Google that and do a bunch of stuff. But here, you can just say, oh, like, you're just, you know, out of inode, so you should probably go do this.
00:30:45 · Garry Tan, Paul Copplestone, S3
[00:30:45] S1: Yeah. That makes sense. Basically, you know, if you're being used by an agent, the agent will encounter a error message. In the past, a human would have to go Google that and do a bunch of stuff. But here, you can just say, oh, like, you're just, you know, out of inode, so you should probably go do this. [00:31:02] S0: Yeah. Because there's, like, two stages to winning the agents. The first is being picked by the model. And then the second is, like, if they get stuck, you don't want them to switch away. So guaranteed they'll get stuck at some point. You just want to give them the tools to to remedy. So it's not actually that complicated. They're smart enough now that they can figure out a lot of stuff, but you do have to reengineer a lot of what previously was just for humans and developers for agents. [00:31:31] S3: Do you test your project... Your product for agents? Like, do you have agents, like, try to use Supabase and then, like, report all the places where they had trouble?
00:31:31 · S3, Paul Copplestone
[00:31:31] S3: Do you test your project... Your product for agents? Like, do you have agents, like, try to use Supabase and then, like, report all the places where they had trouble? [00:31:39] S0: Yeah. Yeah. Yeah. All the different models. We got an eval's website where we see which models are building the best and got our own eval suite internally. We eval as well which ones are best just with Postgres, so that's interesting for the industry and build skills around it so that they can adopt them and actually develop with Postgres. So, yeah, it... It's a lot of testing. And in fact, pretty much now a lot of our engineering effort is going into, like, testing specific use cases rather than the building. We wanna think through how people are building and build suites around that. [00:32:16] S3: Garry, when you built g Brain, you built it on top of Supabase. Can talk about, like, how did you decide to build it on top of Supabase? Well, how was it like for you to be a user?
00:32:25 · Garry Tan
[00:32:25] S1: Yeah. I guess, I mean, g brain was like a distillation of a bunch of stuff I wrote. Like, I first worked on Gary's List, which is like agentic. It was like an agentic newsroom. And I had to build up, like, basically a research system for rag and for like policy and papers, and it would like read every newspaper article about a given topic, and then try to synthesize. And then I took that and then distilled it into open source retrieval for OpenClaw. Because the idea was like, okay, I had it in Rails, and that was kinda like a Foxconn factory for agents. It's like, I treated every LLM call as very expensive and incredibly dangerous. And then when I saw OpenClaw, it was this, you know, it was kinda like Esselen. Was just like a very different way for, you know, you to work with AI, because then it's like, oh, the AI's smart. It's not trying to hurt you, and then you should just let it, like, do stuff, and you should just give it data and capabilities. And so I recognized a million tokens is actually an incredible working memory. Like, most human beings only have, like, seven plus or minus two things that they can keep in their head, whereas, like, a million tokens is, like, basically, like, three Harry Potter books. But then even that is, like, a little bit limiting for the agents. Like, keeping the correct three Harry Potter books in your context at any given time is a real challenge. So it felt like there was this thing in between. For a company brain or, like, my personal stuff, it's like, I have half a million Markdown files on, like, every communication I've ever had. And so this thing really does have context on me and everything that I care about. But then at any given moment, like, the agent, they might need like two pages or something. It's it's a retrieval problem. And so at that point, you know, at many, I think it's like 30, 40 gigabytes, You need p g vector, you need Postgres, you know, you can do graph databases very easily in SQL. And so that's what g brain is. It's like, you know, rag retrieval plus like a a graph database that creates, like structure out of unstructured data. And so it's like dynamic schemas. Like a little bit like what I remember Palantir was back in the day. Yeah.
00:34:41 · Garry Tan, Paul Copplestone
And then, you know, entire idea is that agents are much more powerful when there's sort of this intermediate thing where the agent can just say, like, this is what I'm looking for, and it'll traverse the graph. It'll do all of the, you know, vector search, and it'll come back and say, like, here... Here's a report, and, like, load this into context. And so that's what g brain is. And then Supabase was just, like, very straightforward. It's like, I need I need hosted Postgres, and I need it to be able to support, like, a 50 or a 100 gig or 300 gigabyte, you know, database corpus Yeah. Really fast. And it's been great. Like, you know, the auto scaling works really really well, and now the funniest thing is, like, with browser use, like, I use a side browser now for browser use, and it's like, oh, yeah, like, OpenClaw can go into Supabase and, you know, use the database or the new APIs you made, and it just like managed it itself. It can like self manage. [00:35:40] S0: Were you having to prompt it to like figure out the data structures, like graphs or or, like, rag or anything like that? Or... [00:35:47] S1: I mean, what's funny is, like, I I remember going into Claude Code and just saying, like, use Exa and download every... Download and diarize every paper you can find in AI research. Today, I could use, like, Alpha Signal or something. [00:36:02] S0: Yeah. [00:36:02] S1: But it's like, go and find every piece of research about Rag [00:36:06] S0: Yeah.
00:36:06 · Paul Copplestone, Garry Tan
[00:36:06] S0: Yeah. [00:36:06] S1: And graph databases, and, like, you know, text retrieval, and then summarize it for like my use case, which is like, how do I help an agent get access to this stuff? And then after it did that, it's like, oh, okay. Well, here's here's how we're gonna do it. [00:36:21] S0: Yeah. I was at a dinner the other night on like the future of databases, and one idea was like, databases essentially are, like, a retrieval mechanism Oh, for data. And, you know, you can put indexes so that they'll search across the data in certain formats, so a graph or or reg. And then one of them, was super interesting, was just, like, putting an agent on a loop to create the perfect data structure for the search. Like if you're searching this dataset this many times and it's taking ten seconds, then why don't you just put an agent on a loop to create a new type of index or, like, find the best index for returning that in less than a second?