You wake up, whatever problem you have in your life, why can't you solve it with AI? And just like start there. I think the CEO needs to be the chief AI officer. Like it's not an engineering team thing, it's not like a product team thing. It's like you have to understand the bounds of a technology better than anyone. I think a good proxy for how to spend your time is what are things that only you can do, the models cannot do. You have to sort of refound the very concept of what the company's self-identity is.
Welcome back to another episode of the Lightcone. Today we're joined by Pedro Franceschi, co-founder and CEO of Brex. Pedro started Brex in the Winter '17 batch and built it into one of the most important fintech companies of the last decade. He's here today because Brex has gone deeper on AI than almost any enterprise company we know. And Pedro's own AI setup is so compelling that when he came to YC for lunch, it sent our entire team down a rabbit hole of building on their own. So Pedro, welcome to the Lightcone.
Thanks for having me. Excited to be here.
Thanks for changing our lives.
Yeah. Oh god, that lunch, I'm like, I think the model company should be sponsoring me for the token consumption increase I generate. We, you know, supposedly generated on that lunch. That was the precursor of GBrain, I guess.
I was still working on GStack. I was still a 2013 Web 2.0 engineer who time-traveled instantly to the AI tools of January 2026. I was, you know, probably half a million lines of Rails code in and created GStack because of that to like help me make a software factory. Yeah. And then after I met you,
I realized everything is about freeing the claw.
Free the claw. I knew you were going to say that.
Let it rip.
The craziest thing was realizing like what I had gotten wrong, that I think actually most people in software are still getting it wrong is they've been treating the LLM like this very precious thing that's very expensive. Yeah. And so as a result, you have to literally put the agent inside a Foxconn factory. And it's like, can you imagine? Like, I mean, that's what the half a million lines of Rails code was for me. It's like, no, no, no. I need to control what the LLM sees because it's about really, really, like I only want the context like from here and let me write like all the if statements to make sure like, you know, like a Foxconn engineer, you're waking up at 6:00 a.m. and you know, if you don't, you're going to get electroshocked. I mean, like it's just like this terrible thing that you do to agents.
And they want to be like at the Esalen Institute, and that's what OpenClaw is.
Exactly. And it's funny because I feel like every single good AI product you've used is an agent loop with tools. That's it. Like there's no, you try to sort of over-engineer the harness and then do certain things, but at the end of the day it's skills, tools, and a model. Like there's not really much else.
Maybe we start earlier because one of the things we'd love to kind of, you know, get down as a part of lore is like how did you get so AI-pilled and like all the way to the edge?
Well, I'll tell you my encounter with LLMs, which was so... So I remember in the pandemic, um, there was someone, someone gave me an API access to GPT-3 and uh, and I was playing with it and I was like, okay, this is, this is really cool. This is, there's, there's something here that could be, could be special. But it was the kind of thing that was like, yeah, it feels like a research project, the kind of thing that Google used to release and you play with it for 10 minutes and you stop. Uh, Chat came out and I think everybody was sort of interested in it. Where I think it got interesting was uh, when you started to see reasoning models and of course tools. But I think everything else was sort of a blip until December. Um, and the way I describe it to my team is like, you know, electricity was invented in December. Uh, and I think electricity was Open 4.5 and sure, open models and, you know, OpenAI models got better and better since then. But to me that was the tip of the spear where you could say, yes, like coding harnesses actually work. And, you know, Claude Code existed for probably a year before, uh, but it wasn't that valuable yet. And I remember, you know, during the holiday break I was playing with it and it was pretty shocking, probably similar reaction that everybody here had. And I think the question becomes, you know, if you sort of, if you think about, you know, you're sort of standing, you know, looking at 200 years of history and then you imagine you are, we're now in May, you're sort of five or six months after electricity was invented and most people are still playing with candles and, you know, questioning, you know, what can you do with candles and fire and, you know, like
Who needs light so bright?
What about all these lanterns and what can you do with it? And, uh, and you know, the steam engine is like, I don't know, maybe like 20 years away still, but you know, electricity already exists. That to me was the sort of the fundamental light behind it. And I would say I think since then OpenClaw was kind of an interesting sort of next step, which is I think when we realized that, uh, you know, the reality is good AI products are agentic loops with tools. Uh, and we started doing this in our own product at Brex, but then on the personal side I started spending a lot of time understanding, okay, what is at the frontier of using OpenClaw? And I think the insight was just, um, yeah, like markdowns can take you really far, just like configuring and automating a lot of the things in your life. It's kind of funny. I remember I had this experience of like buying a movie ticket entirely in OpenClaw using like a Brex card. It was provisioned through an API. And then I showed it to my team and they were like, "Oh, but like you can go online and like book it in 10 seconds." And I'm like, "That's not the point. You're missing, you're completely missing the point." Uh, but anyway, and then I went obviously very deep into this rabbit hole and started spending a lot of time thinking how to change the fabric of the company and the way we build the products and
Tell us more about your personal OpenClaw journey because I, before you came for lunch, I had it like in store, but I was like way too scared to do anything with it. We were all scared.
Yeah, don't get me wrong, like we deal with financial services data. We spend a lot of time figuring out how to be mindful of security and protection. But and yet, uh, I think people are a little bit more risk-averse than the technology probably requires them to be given where the technology is. And when we started using OpenClaw personally, I started doing it in a lot of my own personal setup. Basically what I did in the v1 was I'm going to give it read access to everything and just create like OAuth tokens to my email, to Slack, and to everything to just literally not write. And I was kind of shocked how far it got me. Um, and then the next question that we spent time on at Brex was, okay, like how do we actually get it to write into our systems? And everybody in Google's security team was, well, we cannot do that for all the reasons that we know. And then basically where I spent, I don't know, probably four weeks of my time was, okay, let's solve the hardest problem, which is security. Uh, and we ended up realizing that the only way to actually do something about it was to do something in the network layer. Uh, and if you treat the agent like, you know, the agent has its own wills, desires, and, you know, they go to the Esalen Institute for agents and, uh, you know, they have
Instead of Foxconn's factory.
Instead of Foxconn's factory, they will try to do things at a network boundary that could not be the right ones. Um, and we decided to actually just focus on that. So a lot of folks were, you know, and we saw Nvidia and others on Nemo Claw, let's build these like open-source forks that have controls over, you know, what tools the model calls. And the reality is, yeah, you can do all that, but you can also just make an HTTP request wrong. So we focus on that layer and then we build this thing called Crab Trap, which we open-sourced probably about two months ago, which is actually the way we use to secure agents at Brex in production. And the basic premise is you analyze, you HTTP proxy the entire network boundary of an agent. And the idea is when a request goes through, that becomes auditable, and you basically can use another agent to analyze the traffic and create a policy to let traffic go through or not. And surprisingly or unsurprisingly, because these models are trained on, you know, hundreds of billions of web documents, HTTP traffic is actually, I would say, probably the way the models reason more so than anything else because they just literally learn on the web.
So the ability of the model to watch like a thousand requests and make sense of what's happening was way higher than we anticipated. So we actually built that, put that in production at Brex. And after you record a traffic of an agent operating for a day, you can build a pretty good policy that, you know, sets things that should be automatically approved. And for things that the agent isn't really sure, you can just use an LLM as a judge, and the LLM determines is this request something that should be approved or not based on the policy for what that agent should be doing. So for example, we have like a recruiting agent at Brex called Jim. We have a policy for Jim, and, you know, all the traffic goes to that same policy. And 98% of requests go through automatically, 2% use an LLM. So we sort of got that problem solved to a degree that we got comfortable experimenting much more aggressively and sort of freeing the claw on the enterprise, which is really hard inside a regulated company. So I would say if we found a way to experiment with these things, and granted we don't do the most aggressive things with this stuff yet, we don't use it on, like, you know, customer data to the degree that we want one day to do, and there's boundaries to how we do. I don't see any reason why a YC company shouldn't be at the bleeding edge of this stuff.
Yeah, I mean, I think your intuition around like the proxy at the network level ended up being quite prescient. Like I think a lot of the stuff that I'm seeing kind of around the OpenClaw ecosystem at the moment, at least, or just agent ecosystem, is essentially doing that. Like we're seeing that like with credentials, credential brokering, like Agent Vault is doing a lot of that. I think you had mentioned the first version of Crab Trap included like credentials vault. Why did you decide not to include that?
I think it was just let's just do one thing really well. Um, and, you know, at the end of the day, I think there's going to be a lot of solutions that do that. You could do credential brokering and other tools already, but the LLM as a judge was for us the determining capability to say do you trust us in production or not? And our security team at Brex, very rigorous and very good at what they do, for a long time were, well, you know, not really. Uh, to getting them to a yes, we actually believe this is enough, was a big unlock for us. And look, I always say this, like we're not in the business of building HTTP proxies. We are in the business of being at the bleeding edge of what you can do with AI. And to get to the bleeding edge required us to build this proxy. That's why we did it. Hopefully someone's going to build a YC company. Hopefully we're going to build a better version and we're just going to go use it. But at the end of the day, um, that's the journey that took us to just sort of being at the bleeding edge in that way.
And how much was you sort of pushing this forward and like how much resistance did you get internally and just how did you like
I mean, AI adoption, I think there was a lot of excitement about it, but the way I describe AI adoption inside most companies is I think there's like sort of three tiers. There's tier number one, which is your token maxers, like your engineers that are pushing a bunch of code and typically living inside coding harnesses. And those are sort of well known, we know who those are. Then you have the sort of average engineer that is building a few things, but, you know, not sort of token maxer to the same degree and probably, I don't know, a tenth of the productivity. And then you have like the entire rest of the company. And the entire rest of the company typically is interacting with AI in what I call like Google search mode way, which is a chatbot with a few MCPs, um, or a Google Workspace equivalent. Like, yeah, you have a few tools from Google, but at the end of the day, it's really just like a search. And I think where our thesis was, if you think about the value that AI creates for like a token maxer, for example, a lot of the value comes from the harness. And the thesis was how to actually build an equivalent harness for other teams that are non-technical. And our whole sort of thinking behind it was like that's a lot of what OpenClaw, you know, created, which is this ability that you can self-bootstrap a lot of the capabilities of the agent by the way you edit your skills and markdowns and sort of set up the environment around the agent. Uh, and how far can we get this ability for the agent to self-bootstrap a capability without anyone actually going and coding it by hand? So the analogy we use internally for I would say the sort of the company-wide adoption of AI is we don't believe in the, yes, like give people a few MCPs and let them go, because I think what people really want is, uh, in my opinion, is really a way of saying, okay, this is actually a virtual employee almost that has, you know, it's on Slack, it has an email, I can actually invite it to a meeting, can join a meeting, take notes, and you're trying to replicate that as much as possible. So how do you build the infrastructure to support that kind of use case? And I think the harness, because it will look a little different, probably more like OpenClaw than a coding model.
Pedro and I just did this this week for the first time where we installed Aqua voice and then you open Telegram with the claw, or actually we have it in Slack now, and then basically it was like me and Pedro and like three engineers and someone from the events team, and we're trying to put together, um, how do we put together 60 dinners with, uh, 20 people each of attendees from Startup School with 21 partners and visiting partners at YC.
Sounds like a great problem.
And then we just basically started talking about it, and then I picked that up, and then I pressed enter, and then, you know, our claw just started doing it. None of us opened Claude Code, like it just sort of built a bunch of markdown. It did the analysis and
Yeah, people forget that Claude Code isn't magic. It's just literally a harness around the same models you can use in an API, right? So I think that's the unlock of... And by the way, there's a few things that Claude Code is doing that I think are really cool.
And yet, uh, it's just a harness. Uh, and
And the claw can use Claude Code.
And Codex, right? It really prefers to use Codex these days.
Exactly. It really does everything, actually.
I don't know why, you know. Exactly. But ACP helps on that. So, yeah.
Why do you think the adoption of token maxing hasn't really taken off? The thing that we found very curious working with a lot of startups early on is a lot of founders are very shy about burning tokens. I think you really get to experience this when you really go all the way.
Garry mentioned this point, which is tokens are expensive. And I think there are, you know, I'm in a fortunate position to be able to spend on tokens. But I would say I keep trying to picture myself. Imagine if I was like 14 or 12 when I started coding for real and I had the technology we have now. I would be token maxing in the cheapest way possible. And there are people doing that. You know, you look at the Chinese models, for example, like they're pretty decent.
There's a huge hobbyist community where they, you know, build a gaming rig, but then they try to build like local LLM, and then that is like totally reasonable way to do it.
100%, 100%. I have a friend that has the exact same setup. He has his like little GPU farm in his house. And first time I went there, I was like, "Wow, heating's on here. It's really hot in here." And he's like, "No, no, no, it's my GPUs." And I was like, "Great, like, you know, power efficiency all the way through." It's funny because at Brex, and we should talk about managing token cost and spend management for tokens, which is a topic we're spending much of our cycles on now. I think that the cost part is one, but even if you take the cost part aside, you know, the first symptom is a lot more people should be complaining about the max plan limits. And you know, you see how, what's the percentage of Twitter that probably complains about it? Like 0.1%.
So I think people are probably still early. To me, there's this like the AI pill test, in my opinion, is whatever problem shows up in your life, do you default to AI first or not? It's like, of course, mechanically you can do it, but there's a point that it becomes like second nature, and then your whole like brain gets rewired, and you cannot think in a different way. And there's the whole topic about AI dependency, human-machine interaction. Yeah, there's all these things that we can talk about and put in the corner. It still sort of surprises me how many people you go talk to about a problem, and I'm like, it's so cheap to intimately understand the bounds of this problem now. Like, why haven't you done that yet and come in with like a much more digested view on the problem? And I think the second thing is, I think if you have the luxury of building a company now, the fabric of the company from day one can be built in such a different way that I think if I were to start a company today, I would say, okay, the premise is why can't it be just me? Like, and then you start from there, and your token consumption is probably going to be a lot higher than if you said, well, I'm going to have like three people or five people or seven people. And I think the fundamental constraint isn't as much in my opinion, like AI as a cost savings or I'm going to be more efficient. I think the unlock is like the fabric of the company just looks very different when the boundaries become type systems, interfaces, agents talking to each other versus people. And I think people still didn't fully grasp like, okay, what does it mean to build code with new agents, like, and the new technologies we have. I think that's like well understood. But how to live in a world where intelligence is on a tap and your default answer is let me actually solve this problem with AI first, even if you feel suboptimal, and then from there saying, okay, how do I actually make it optimal? Because I think for the majority of problems, there is a way to solve it with AI that is probably better, and your job is to figure that out, even if it's going to take you more time, because that will compound.
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.
When you started Brex, I mean, like it's well known, like your like MVP had no web UI, right? It was just like all terminal, like super scrappy. Today would have because no one needs HTML. It's just tests anymore. Like, was it actually still the right approach to just have a really simple MVP and test that anyone would work, or would you have like a way more fully featured?
So I have this controversial view, which maybe you all will disagree, which is like I actually think if I look into a pattern of companies that succeed, I think there's a really interesting pattern, which is minimal surface area. And the problem is with AI, I think you see like, look at Stripe for example. Stripe early days was like literally an API. Brex early days, no UI, just like literally a terminal. You look at Airbnb, it's like the website was a form, and the form was just like literally where you put what you needed, and then someone somehow went there and figured out how to actually make the booking happen. Like DoorDash in the early days, similar, right? Like it was just like literally, so the surface area was so small with the customer, and so much of the bandwidth of the founders were spent nailing this one single interaction pattern. And I think the risk with AI is that the agency behind choice goes away. So you have this, you have this, this lack of discipline on what matters to solve. And I think people tend to believe that I can just experiment a lot of things, and that's absolutely true, but that doesn't preclude you from actually choosing what matters. I always tell people like, I think if you don't, if you can't minimize your surface area and solve the problem with a very clear set of boundaries, you haven't found the right problem to solve. And I think that's, and you can of course find how to compress the problem into a smaller surface area using AI, and that's really valuable. But I don't think you should use it as an excuse to not do that, which I think is, well, I can just build so many other things. But you know, I always tell this to people like, intelligence is compression. So when someone comes to pitch me an idea in the company, I'm like, it has to fit in a napkin. Like, great ideas fit in a napkin. What's your napkin? And then someone comes with this, and I'm like, I don't know where you buy napkins, but the ones in my house are not this size.
How about the step before it then? Even I, like, actually a lot of the pivot advice I give founders during the batch comes from you talking about how you found the Brex idea. And if I, like, the approximate view I remember is that you thought about it as like two-week cycles, and like you're either in like exploration or exploitation mode, and you're like trying a bunch of things, but then you want to like hone down. Like, would you still use that pattern now?
100%. I think one of the hardest things of building a company is talking to customers, and not just having the conversation, but how to extract the sort of unspoken signal from these conversations. And I think to me, the can AI solve this lens, like whatever problem shows up in your life, can AI go solve that? And you think about like building a successful company, like why can't you prompt your way into that? And the reason is very simple, is because there's signal that the models weren't trained on. And the signal is when you go talk to a customer and they tell you about a problem they have, they're not going to tell, they're not going to give you the answer shaped into a prompt that you can put into an LLM, and that LLM is going to go and output the product that's going to win and be a billion-dollar company. They're going to tell you a very sort of local optimum answer based on their worldviews and their constraints and the way they see things. And I think a lot of the job now is to have the wisdom to choose what you want. And because before, the wisdom was not just to choose, was to choose and know how to execute it. The execution is out, right? The execution is gone, and the model's going to do that better. The wisdom to choose is still, I think, the missing bottleneck. And to me, that all comes from which signals are not in the models.
So say like pre-AI, you had personal bandwidth to explore like three ideas in parallel. You're saying like now in AI world, you'd still do three in parallel. Would you do like 30 and let the models try and
The way I would probably approach it is like, let's pick a broader universe of things to do, sort of an early initial exploration. But to me, the lens is, okay, why can't AI solve it? And like, which signal is not in the model? And I think the signal is typically the customer. And then when you go talk to the customer, I think I wouldn't parallelize that. Probably I would be, okay, let's try to get in the headspace of this person. And I think it's so easy. And we did a lot of exploration with like synthetic customers and building customer role models and things like that. And those are really valuable once you know a lot about the customer. But when you don't know enough yet, I think there's this like very basic thing, which is even at Brex, for example, like one of the hardest things for us as a company was we initially sold to founders. We are founders. We knew about ourselves. We knew about our problems. And then as the company got bigger, we were selling to finance teams. And finance teams are different. So building that mental model of like what's the value system, like of course you can eventually make the model represent that and have that worldview. But there's an intangible that I think is where a lot of the alpha still comes from. And I think to me is like the, I think a good proxy for how to spend your time is what are things that only you can do? And even in the company of one, what are things that only you can do and the models cannot do? And that to me is like one of them.
I think that's so on point. I think a lot of founders like you that successfully navigated a pivot have this loop. Basically, there's this book, "Others in Mind," from psychology, that has to do with people that have very good emotional connection with people are able to simulate what the other person is thinking and what the others... and others' mind.
And I think the founders that get that and have the empathy to figure out what the customer is not verbalizing is what is, I think Garry says this, make the implicit explicit.
of what are all those desires.
And they're very subtle signs a lot of time because they're murmurs as founders go through them and figure out the insights that, oh, is this really a thing? But how do you know when to poke for it? And the problem with relying on models right now, which is I'm still very optimistic that there's still a lot of job for founders, definitely, is you don't even know what the right incantation or set of prompts to ask the model, because you don't even know what to ask. There's like another meta layer.
Yes, it's the whole like Elon thing of like, you know, which question is the universe the answer for kind of. And of course these are generalities, right? But I think what I've seen is you have to remember that LLMs are not magic. Like LLMs are trained on a very specific corpus of information optimizing for a very specific set of benchmarks and outcomes. And I think the biggest pitfall of LLMs is you have no sense of how much training data the model has seen for the exact thing that you're asking it. So imagine if like every time you asked an LLM a question, it gave you like, yeah, like the sampling frequency of this in my dataset was, I don't know, X, and on this other answer was 0.00001X. You would trust it very different, right? The distribution is so different.
Oh, I would pay for that. That's a great startup idea.
Exactly. Someone should do that.
We need to do a model that does that.
Yeah, 100%. I would pay for it.
Yeah.
Well, because it's fascinating, because then like anything that's out of distribution, you just go and like fill that in for use. I mean, actually, as an applications engineer on top of the LLMs, that's actually a huge like blind spot.
And that's what Merkore and a lot of the other data companies are doing. Like a lot of the jobs for them is to say, well, where are the blind spots for LLMs? And it's funny, like I think a lot of the data labeling companies right now are trying to understand the pitfalls in the models. But the problem is in order to do that, you have to be an expert to know what the gaps are in the answers. But the problem as a founder, when you're looking for an idea, is you know nothing about it. So there is a curse of knowledge and a curse of not even knowing what the bounds of knowledge are, which I think can make you believe that you understand something that you actually, in order to model, actually understand.
