How do you build super intelligence inside a company?
Part of the key thing is not to just use AI as a copilot. This is the thing where you use it as the building layer for everything. And you need to start recording all the artifacts.
It's like a shared organizational brain. It's like the closest thing to us being able to connect our brains. If you frame this as a way for everyone in an organization to get better at what they do using the collective skill and instinct of the people they work with, it's incredibly powerful.
Today we have a real treat. We have a special guest, general partner at YC, our partner Pete Koomen. He created Optimizely, which was one of the first and one of the best ways to do A/B testing for apps and websites. And since then he has gone on to create all of our agent infrastructure at YC. So literally all of our harnesses and how we use AI internal to YC. Pete, welcome to the Lightcone.
Thanks, Jared. For the last few years since ChatGPT, YC has been funding mainly AI companies, and we've gone through many different versions of advice for them about how to build AI-native companies that build mainly AI products. And we've gone on a crazy journey with them, learning all of this. I think a lot of people don't realize that internally YC is actually building and using a lot of the same stuff that we're helping our startups build and use themselves. And it's been, I think, a very powerful symbiotic relationship for us to actually be adopting these tools and transforming our own organization, which was started way, way pre-AI, into a super AI-native organization ourselves. And Pete has really been leading the charge for that. And so I'm really excited about this episode because I've actually been wanting to talk publicly about all the stuff that we've built internally, and this is the first time that we're doing it. So Pete, perhaps to start off, you sort of go back to the beginning and talk about there was a particular moment when we really started adopting these AI tools internally. It was really you who got us started down that path.
Sure, happy to tell the story here. And I like framing it that way because it was a project that I and a few engineers got started about a year ago, maybe a little more, but that has since snowballed into just a whole infrastructure layer that's made it possible for us to use AI internally at YC in lots of different ways. And that's actually been one of the neatest parts about this is watching the whole engineering team and many partners also just dive in and contribute to this infrastructure layer. We started building our own harness inside of YC, or kind of YC-specific agents, about a year ago. And the original impetus for the project was some of the work that I and a few of the software engineers at YC were doing with our finance team. Just for a bit of backstory. So YC has, for as long as it's existed, as far as I'm aware, run mostly on our own software. In this era, that's just given us a huge advantage, right? And so with that context, back to this moment maybe a year ago, we were sitting down with the finance team, talking through a set of tools that we were going to build for them, just to help them run through some of their finance workflows, booking journal entries, logging priced rounds, like all the sorts of things that make YC run really. I was seeing kind of two things at once. Like on one hand, we had this sort of loop going internally, right, where we'd sit down with the finance team. The finance team would describe to our software engineers how this complicated financial workflow worked, and then the software engineers would go and build some purpose-built software where there was a deterministic workflow encapsulating everything that they had been told, and then hand it back to the finance team, and so on. And it felt really inefficient. And then at the same time, this was right around the time when agentic coding tools were really catching hold, right? And so you had the first generation, Windsurf and Cursor, that were well established by this point. I think this was right around when Claude Code was introduced. I felt like this was giving me superpowers, right? And then kind of watching this sort of old classical way of building software in YC, and then watching how I was doing things on my own machine, it just felt like a bigger and bigger divide between those things. And so the original impetus was, why don't we try to build some tools at YC that we could use to run agents that would give the finance team control over their own software, right? Like remove the software engineers from this crazy loop where they have to sort of understand these complicated workflows, and give the finance team the tools that they could use to encode their own workflows, not as Ruby, but as English with prompts, right?
I mean, what's interesting is we all funded companies maybe even two or three years ago when LLMs were out, but agent coding wasn't a thing yet. And so the first thing actually was not coding, it was LLMs for writing SQL queries.
Yes. So that's what I remember from the first versions of what you built was how good it was, and how basically it rhymed with these other failed startups that we had funded, like each of us probably funded one at some point. You know, here it was working, and it worked so well that non-technical people, granted very smart people from finance but with no engineering background, could use these tools to ask real questions. I was really surprised too, to be honest. And so we started with this kind of purpose-built thing for finance, and then rewrote it to even more of a general agent loop, right? And this is now, you see these all over the place now. But the first kind of magical moment that I had was we had this agent loop, and we had a tool registry, a shared tool registry for kind of YC-specific tools. And the first tool that really was an unlock for me was, I think, a tool looking back that you actually built, Jared. It gave these agents the ability to run read-only SQL queries against our database.
Right. It was two tools actually. One was running queries against our database, and the other one was the ability to read our model files. I remember I built those tools, and I felt a little bit like I was breaking the rules because initially we started with very limited tools that had very narrowly scoped domains, and I kept getting frustrated because they weren't powerful enough to do the things that I wanted. And so I was like, what if we just gave the thing complete access to the production database where it could just trample on anything? And I sort of surreptitiously pushed it out maybe late at night.
It worked extremely well, right?
Yeah. Perhaps foreshadowing, you know, subsequent things like OpenClaw, where it turns out that the thing that was hampering the world was being worried about security and privacy and all the things that could go wrong. And when you worry a bit less, you're like, oh my god, these things are unbelievably powerful. It's another really good example of this weird split between I'm at work and I'm kind of operating in this really narrow box, and I'm at home using Claude Code or whatever, like OpenClaw, and I can do anything, right? And trying to narrow that gap.
So why was this so useful, this ability to run SQL queries against our database? Sounds really simple. Well, I think this is where it's important to talk about one of the big advantages that I think YC had coming into this experiment, which is that we run on our own software, and all of that software sits on one Postgres database that has everything that's important to YC's world in it. You know, every company that we funded, there's a companies table, there's a founders table, right? There's tables for our financial transactions. There's tables for the notes that I leave in our little internal CRM, right? All of these functions that I think a lot of other companies farm out to third-party SaaS tools, we've built our own. And as a result, we have this database with every important piece of context that I can now ask questions like, hey, show me all of the investors who invested in a space-related company in the last four batches, right? It just turns out when all of that context is in one place with a little bit of additional information about how the schema is laid out, an agent can go and answer arbitrary questions about our business.
That was a magic moment for sure when I first saw that.
Yeah.
The cool thing for me is that it didn't just make it easier to answer questions. It dramatically increased the number of questions that we would ask, and dramatically increased the scale and complexity of the questions that we would dare to ask. Where like, you know, in the old days back when we were using BI tools to ask a question like that, you know, like what investors have invested in space-related companies, that would be like several hours of writing SQL. And so like, unless it was really important, you just wouldn't bother. It's just another example of this instance of Jevons' paradox that you get when you remove the amount of back and forth between different teams in order to get a thing done, right? If in order to ask some kind of complex question about YC, I have to go and knock on the data science team's door and wait for them to get it through their backlog, I'm just going to ask far fewer questions.
I mean, there are people out there watching this who work in places that still use it. The majority of people live in that world still, and it's 2026, which is a little unfathomable, actually.
There's a long way to go, I think, which is really exciting.
I guess one question is how do companies that live in that old world get sort of wings to move so quickly? Because the magic for us was, as you said, everything, the context was in one place that made it easy. You know, if you think about data science historically, one of the first things that the Googlers had to figure out was Bigtable, right? And Bigtable was, you know, instead of schema and joins, you have one big table that can be map-reduced.
And so I think that's happening again. And I would argue that that's happening now with Karpathy-style knowledge LLM wikis, with GBrain. I mean, that's what I'm seeing anyway. Like, you know, obviously I have OpenClaw. It has access to lots of systems, and then I'm normalizing it to my own schema that's relevant to me and the things that I care about. And it is like denormalization. You're taking data and you're putting it into a format that is more or less optimized for OpenClaw or Hermes agent, like that particular type of harness to be able to ask questions. It needs retrieval, it needs RAG, it needs graph RAG, it needs, you know, hybrid RRF, like there's re-ranking in there, like, you know, all the things that everyone has learned about retrieval is now inside GBrain. And then when you give the agents a soul and you give it the data and it knows you and what you care about, like suddenly these things have insane wings. Like I just kind of can't believe how it sees around corners. And you might ask a question and it'll even sort of interpret what your question was about and give you a thing that frankly, like, it would take a human who really knows you well to answer. All that's possible now. And so, you know, your question is like, all the data is everywhere. My answer from the OpenClaw Hermes experience with GBrain is like, yeah, you basically have to take that, you're going to denormalize it, and you're going to put it in a format that is optimized for agent retrieval and understanding. You could wrap it in an MCP, but for whatever reason, I just like intuitively I'd be worried like it's still sort, you know, these things are really good at working with MCP and CLI, like they're a little even better with CLI. It seems like you have to denormalize and do the big table thing, but, you know, specifically for the agent.
Looking back over the last year and a half, it feels like we're still kind of in the single-player era of agents, where the harnesses that have gotten really popular, right? Claude Code, Codex, Pi, OpenClaw, Hermes, they're all designed to be used by a single human running on a single machine. And it makes a lot of sense, right? Because in that environment, these agents can do just about anything, right? And they make you incredibly powerful. They're a lot of fun to use. I think one of the big problems that I don't think has been solved well yet by anybody is the multiplayer harness, right? It's enabling that kind of superpower, but on a team or an organizational level, right? And that's, I think, been the interesting thing to explore with the infrastructure that we've built at YC, is watching which primitives that we've created that have enabled individuals and teams to use agents. You asked the question about if you're working inside of a kind of a legacy organization, which is like anyone who's more than two years old, what are the things that you can focus on in order to help enable everybody at your org to use AI to do more? And we talked about kind of this common context layer, right? And so a data warehouse where just as much of your internal important context lives, it just turns out is extremely useful. There are many tools for connecting individual agent harnesses to other MCP tools, other sources of truth. But just like a coding agent inside a monorepo just tends to be much more efficient, watching our agents operating on our single database that has everything in one schema tells me that there's a lot of value, at least, in getting all of the context into one place. Having an internal tool registry. This is, I think, the other really important thing that we've built. So in the beginning, like we were talking about, it was just the whole system was really simple. It was like an agent loop and a simple tool registry and, you know, a few other pieces, right? Like a model router underneath. The tool registry is where most of the YC-specific stuff lives, right? The tool registry is what turns these agents into something that's useful at work. And we had like 20 tools at the beginning, including this magical ability to query our SQL database. But over time, teams have added more and more tools. Every time we kind of come upon some piece of work at YC that we think could be improved with an agent, we can just add tools. And there's more than 350 today. I just checked, right? Every team is adding their own tools. You know, I can do things like manage my office hours. Our finance team can, you know, book journal entries, right? We can help manage the events that we run. There's tools for all of the important work that we do at YC. And now once these all exist in one place, you can make them available to these internal agents that we've built, but you can also make them available to Claude Code, you know, running on our individual machines. So those things above all, I think, were the important pieces that we built that if I were working in any other organization, I would focus on building.
I mean, honestly, inspired by what you guys did with tools like this idea of skillify in OpenClaw, and then actually the most important, the last part of skillify. Skillify is like this meta-skill that I made in OpenClaw where it's like you just do anything in OpenClaw on Hermes. Hermes actually already has skillify. They call it something. It's like it makes skills automatically. But the most important thing I think is actually like plugging it into the resolver, which is like your agents.md with like the list of things that the agents can do, and then like it links to the markdown entry point that like lets you use a tool basically. And so like this thing keeps coming up in all these different contexts. Like Claude Code has a skill, the skill registry in Claude Code is actually a resolver. Our tool registry is actually a resolver. And then the weird thing that you have to do on top of that is actually, I have a meta-skill called check resolvable that I call all the time. So I'm always like, I do something that's new or different in my agent, and then after it does it and I like it, I say skillify it, and then it becomes basically like a tool call or method call. And then I run check resolvable, which is like, you know, look at all of the other skills and tools that exist, and is it, you know, DRY, don't repeat yourself, and is it MECE, which is, you know, I'm embarrassed to say a McKinsey term or the consultants use for making really good slide decks. Mutually exclusive, collectively exhaustive. That's like how you're supposed to do slides if you're a McKinsey consultant. But it's useful because it's like an additional layer on top of don't repeat yourself, DRY.
And like the models just seem to know what those things are. And so if you have a DRY and MECE resolver table anywhere, it's actually like the optimal resolver. Like it's bad to have 10 skills that do all the same thing. It's good to have one skill or one tool that has parameters that then let you call them. So I don't know. I think it's like this is like the wildest time to be alive as like an applied computer scientist because it's like simultaneous discovery of the same useful applied concepts over and over again. And I wonder if like when people are, you know, developing the first versions of Unix or something, it's like discovering a stack and a heap. It feels like we're right at that moment today. Like we're just coming up with the new primitives for what an agentic system actually is. And you can see it in the parallel sort of development of like we're just trying to do a thing and it might be in Claude Code or it might be in our own internal harness or it might be in OpenClaw, it might be in Hermes. Like these things just keep coming back over and over again.
YC Startup School is back. We're hand-selecting the most promising builders in the world and flying them out to San Francisco for July 25th and 26th to discuss the cutting edge of tech and startups. Apply now for your spot.
Yeah, it's really interesting to look at how some of the other companies that are building this stuff have built their infrastructure because you see a lot of these same primitives in each of them, right? Like there's the agent loops, there's tool registries, there's skill registries. Looking at the way that we're using skills now at YC. So if you think of skill as a simple abstraction layer over tools, we have a handful of sort of shared skills that we all have access to through this agent system. And it's been interesting to watch. I think you've talked about this, where this progression of like in the beginning you were kind of writing your own system prompts and then skills emerged and so you started writing your own skills and then you would start meta-prompting where you'd have the agent write a skill.
Exactly. Improve the prompt.
Yes. Seeing us kind of do the same progression internally where we have a couple skills and now we've gotten to the point where we have these sort of autonomous self-improving loops, right?
Auto-research from Karpathy again, you know, or SLG goal now in Codex, like they've incorporated it too.
