Do you think it's possible, I guess I'm sort of thinking about like for the builders out there, today, if you have a, task or a set of tasks or a set of workflows that you want an agent to be very good at, I think, like you were saying, breaking that down, adding specificity, adding isolation, adding types, adding tests. Yeah, these are all like very important tools. Not for the person building an agent today, for the person building an agent Uh, if we hazard a guess, and uh, they say that guesses uh, 1 month in the future are easy, guesses 10 month, 10 years in the future are easy, uh, guesses 18 months in the future are extremely hazardous, but let's go there. Um, like 18 months from now, if you were to think about like the Bitter Lesson applied to agent harness optimization, or maybe that's one, one sort of made up term. to characterize these set of tactics that I'm talking about here. Like, do you think that the agent itself will be able to do like self-reflection, not necessarily at inference time, but maybe at like train time, not literal train time, but kind of development time, an agent itself will be able to reflect on, okay, like these are the decomposable skills and tasks and workflows. Oh, we, yes, we should add, you know, typed inputs and outputs for these things. because it's repeatable. Um, yeah, maybe there's some level of... I also wanted to sort of bring up like GEPA optimization. Um, I guess like do we expect, in some sense, the bitter lesson to also come for some of these tactics that you're talking about, which is to say that like the agent itself will do it? Yeah, both, could be at development time, but potentially continuously. Um, I don't know, what are your thoughts? I think yes and no. I mean like this is a... Help pull that apart. Yeah, I think you... the upside, so can agents do this? So, one of the things we've been playing with around RLMs, for example. And when I say "we" in this case, Omar Khattab and Alex just wrote a paper about this. And we had already been playing with this at my company, Compound, which is If, let's take the RLM as an example, when, at the beginning of an RLM pass, when you're giving it new information and, say, you're asking it to explore those traces that you handed in. If I'm asking the RLM to explore those traces, The first maybe four steps it's going to do is figure out what the shape of those traces are. And if I keep asking the RLM new questions about these traces, like it's going to keep doing those same four steps. It's going to keep having to rediscover those. Yeah, yeah, yeah, yeah. And so what you could do is you could take all of those traces and just pass them to a model and say, "Hey, here's a bunch of traces for the model." We don't even have to GEPA this. We just basically say, What are some learnings, or repeated behaviors, that you can derive from these traces that we can pass on to the RLM instructions so they don't have to repeat it? And we've had great success. We even trained a little LLM-as-judge to look at each step of an RLM and say, is it in discovery mode or is it in problem-solving mode? And if we can reduce the number of discovery steps, we're making headway. It can start to spend that budget on synthesis and you know, basically knowledge. And so there is, I think, gains to be had by asking LLMs to make sense of these traces, But even still, I do think you still have to apply the structure for defining what the task is and the rails, which is where RLMs and DSPy signatures come in. Right. So that's kind of the upside, which is I do think If you have a harness that takes care of some of the things like typed inputs, separation of concerns, so what you want to achieve is different from how you achieve it, that's a big lesson from DSPy, then you can do more freedom about generic learning about what the right thing is, even without many metrics to feedback on it. That's the upside case. The downside case is, is if you don't have those guardrails, if you don't have clear task definitions separate from how you're achieving it, you don't have typed inputs and outputs, you don't have retries and management, all these other things, you're going to be spinning your wheels every time a new model comes out because even as these models get smarter and smarter, they're still quirky and they still have weird artifacts that are just the result of training on natural language. Yep. And who's doing the training, and what are the traces that are being trained on. So we were just talking earlier about the GPT-5.5 um, talks too much about goblins and other weird monsters. And this turns out to be an artifact that was buried in the traces of the nerdy voice, which was a option you could choose. You could say, "GPT, talk nerdy to me." And a lot of people chose that when they were building their traces with Codex and doing code, and it kept giving metaphors involving Dungeons & Dragons characters. Mhm. And that made it into the training data, and then made it into the frontier model. And so now you have to smooth that over with your system prompt. You have to smooth that over with your harness. Yep. Um, So this transition to the, digressing back which is separating the task from how you do it is really important because the implementation of how you achieve your task is going to change with each new model. Today you have to say no goblins, yesterday you didn't. What are you going to have to say no to next year? What are the weird tweaks you're going to have to do to achieve your task? But your core task should remain unchanged. Right, what you want. Right. And spending a lot of time defining that is well worth your effort because it's the thing that has the longest shelf life of anything you're creating. I do want to ask you specifically about GEPA. I think it's still an early concept under-known or underrated, so I think like maybe teeing up like, what should the, you know, kind of listeners know about GEPA? Sure. Um, like to what degree is it like the final chapter on this broader, uh, approach? What are its strengths and weaknesses? When should I use it? When should I not use it? Yeah. Help me build that intuition. Sure. So let's back up in the core kind of conceit of GEPA or any prompt optimizer, Mm-hmm. which is, These models are weird. Like I said, we just covered the goblins problem with GPT-5.5. My favorite example, I think it was for GPT-5, is OpenAI had in their prompting guide there was like a little tip callout that said, "Hey, just try using different words. We were building a program and we changed a word and it got 20% better. And so now you're like, I have to sit there with a thesaurus and go through each of the keywords and figure out exactly what I want and figure out how that evokes that model. And guess what? Those words are going to be different for Claude, are going to be different from Qwen, are going to be different from all of those. They all have their quirks. And when you think about essentially brute forcing with a thesaurus your instructions, That sounds like a task for an LLM. Yeah, it doesn't sound like a task for you, the human. Yep. So that's kind of, I would say, precept one. Precept two is that, again, We've talked about how all these like weird hacks people develop when they're prompting. Maybe they'll write in all caps, maybe they'll threaten the LLM, maybe they'll want to bribe it. Yep. Lots of weird tweaks. I, you know, someone ran GEPA a lot on GPT-OSS-20B, and for some reason, the optimal prompt always had "good luck" at the end. No way. And why would that be? We don't know. Like we don't know how these are weird organic modules that are beyond our human comprehension. And so what, we want to do is we want to separate the task you want to achieve versus how you achieve it. And the writing of the prompt, the specifics of the writing of the prompt is the how. And what you want to achieve is actually, you can define that pretty tightly. You can say, I'm going to pass you in an email string, and I want you to identify all of the people being discussed in that email, or I want you to identify the actions that could be taken from this email. That's just a list of types and what have you. And I can build an eval training set, or I can train a very large model, LLM as judge, and build a metric to with data to show you what good looks like for this task. And once I have that eval set, which could be just 100 or 200 records, it doesn't have to be that much, you could go write them over a cup of coffee. Now, I hand that to GEPA, and what GEPA is going to do is it's going to take that example data and it's going to run my task and generate some traces. And then it's going to run those answers through that metric and get the right and wrong scores and a little bit of feedback. And then it's going to pass that package of information to a model and say, "Hey, given all this, write a better prompt." And then it's going to do that in a, you know, almost, you know, evolutionary narrative where you're looking at children and parents and going back and forth, it's kind of to generate that Pareto front. of finding the optimal prompt. And it's going to step through a bunch of mini-batches and all these other fun things, and out comes the optimal prompt for your test and your trace eval data. And why that's really nice is because it's way cheaper than fine-tuning, way faster than fine-tuning, it's immediately interrogable. You can look at the prompt that comes out and you can edit it, that's fine. And you can't do that with fine-tuning. You can't look at how the weights adjust and go in and tweak them a little bit. And oftentimes editing the prompt gets as good of results as fine-tuning. And we've actually seen that fine-tuning plus editing the prompt gets you even better results, 1 + 1 = 3. But the great part about GEPA is that once I have that set up, my eval data, my metric, and my optimizer, if a new model comes out tomorrow, I can test it and see how good it is. in like 30 minutes. Yeah, I don't have to re-edit my prompt. I don't have to go find the quirks of the model. I just let this automated GEPA function, which is spelled G-E-P-A, in case anyone wants to know. Yes. figure it out for me. And so we optimize the writing of that prompt for a specific model. This is, it's, and to go on the evolution theme, you and I have talked a lot about history of science, philosophy, and one of the things that I get annoyed about when people talk about evolution as a metaphor is they say, they quote survival of the fittest, but the full idea is survival of the fittest for the given conditions. And I think that's what GEPA represents, which is: what is the optimal prompt for the task you want to achieve, for this specific model, and you will find that it varies from model to model to model. Mm. Maybe just in closing, like it's always helpful, you're sitting at the edge of this stuff, you're sitting at the frontier, you're obviously thinking a lot about how to enable people building real stuff for enterprises, how to make it work, you know, What topics, we've covered a lot of ground in this conversation, what topics have we not touched on yet that you think the audience needs to know about? And that could be related to your current work or just something you saw on a research paper last week that you're like, that's the future, or other? It's a big chunk. It is, it is. As you learn this workflow of creating AI products, 'cause it's not like software where you can kind of write these deterministic things and then figure it out, you kind of have a discovery, adjustment, workflow. And as you figure that out, I think what is, as you do that, you will start to learn what's worth spending your time on and what's stuff you want to automate out for frameworks. And I think it's important to spend time defining exactly what your task is, really well, like Here's the inputs, here's the outputs, let's type them, let's think about them, let's run it a few times, let's go back to zero, rethink that and figure that out, because that's the thing that's going to have shelf life. I have DSPy Signatures, and you could be using anything, but I use DSPy. But I have DSPy Signatures, which are essentially task definitions, that I've used for 3 years. I haven't changed them since then. And I'm still using them, because I can just quickly kind of mate them to a model using prompt optimization or other things like that. I've separated the the task from how it gets done. The second thing I would spend a lot of time on is defining your eval data and your metrics. get short shrift. Hamel has done a great job evangelizing that people need to create their own eval data, because the only benchmark that matters is your own. And, you know, Thankfully, that's starting to take purchase. People are starting to realize I have to create eval data, and so I think that's wonderful. But I think the second thing is your harness of how you eval, at your metric. What is that metric that understands and judges what good looks like by taking the output of a model and your eval data and kind of giving more information back to the system to guide it, I think that is a art people are going to get better and better at. The third thing that I recommend people build skill understanding is learning when to decompose their agent into multiple steps. I think there are some really clear reasons why you would want to decompose. Over-decomposition is its own curse. Um, you don't want to under-decompose, but I think the recognizing why you might want to break your program apart into several steps. Some of these have to do with performance. So, if I can take this piece and route it to a smaller, faster model. Mm-hmm. That's a big win. But a lot of people don't care about speed or cost these days for some reason. They're only starting to. Yeah, yeah, yeah. Um, but the There's a lot of other benefits that are just as justifiable. One is auditability. So imagine you're building a system that produces recommended diagnoses at a hospital based on the symptoms that get input. Do you want that to be a black-box GPT-5 agent, or do you want that to be a decomposable step where I can actually see what symptoms and how they connected to the recommended diagnoses, and what evidence it was connecting it to, both for the doctor looking at it, but also to explain it to the patient or the person diagnosing themselves? That's an example where you will trade the general flexibility of a big agent for the auditability of a compound agent. I think the other thing, which we were just talking about for evals, is breaking your agent apart into pieces sometimes is worth it because maybe one step is easy to eval. way easier than trying to eval the whole thing. So if you're building a deep research agent, it's really hard to look at the final report and say, Yeah. this is why it's good. Right. But it's really easy to maybe use a model, give it a bunch of inputs and just the the first step where it asks you the clarifying question. Mhm. I could look at that and build a good eval data set for clarifying questions really quickly, just over a cup of coffee and maybe 2 hours. And then if I can do that, now I can optimize it with GEPA or fine-tuning, use a smaller model, make it really fast, because that's when the user is interacting with it, not when the user's waiting. So, these It's important to think about decomposition not only as a way to improve your costs and performance. I think the main reason you want to do it is to drive reliability up. And then the third reason is UX. That's another underappreciated thing, which is making sure— 'cause we talked about how if your agent breaks one out of 10 times, people get frustrated and just don't trust it 'cause they have to read over the whole thing. Right. But if you design the right UX of checking in with the agent, you can build confidence even if you have that same error rate. So, getting good at decomposition, spending time on evals and metrics, and spending time getting your task definition right. Amazing. I feel like I always leave our conversations feeling like this topic is so much more clear and so much less muddy. So thank you for sharing, this was a pleasure. Thank you, Shiv. Thanks for having me.
