Throughout the course, we will get to hear from our guest speaker, Drew Breunig. Drew's a good friend of mine and Context Engineering is one of our favorite topics to discuss. Drew Breunig is the CEO and founder of Compound and he's publishing a book with O'Reilly on Context Engineering. I'm really glad to have him join us for the course to share his insight with us. Drew has thought a lot about context engineering in practice. So after each module of the course, you'll see excerpts from a conversation between Drew and myself. We will cover a number of topics in context engineering, including some emerging topics that will be great next steps for your further study. So I hope you join the conversation. starting with this module's discussion about building more reliable agents. Drew, thanks for joining us today. Thank you for having me. We've been friends talking all about context engineering for some time. For context, we just wrapped up a course with DeepLearning.AI on the topic of context engineering, going through in detail what it is, how to do it. I know you think about this probably more than anybody else that I've met, and at an incredibly deep and philosophical level typically. So there's lots of fun things to talk about, but maybe to sort of give you a seed question as a launching off point, um one of the things I think that's exciting coming down the pipe are new ways of doing context engineering and ways that allow us to build better AI systems, better AI agents, faster, cheaper, more reliably, and using models for their strengths and then like giving models additional tools to work around their weaknesses. Yeah. I know you also are very involved in like the kind of DSPy community and more you know, broadly helping people build agents that are incredibly powerful and reliable. Can you tell us more about the kind of work that you're doing now? Or some of the things you're most excited about, about kind of where the frontier is of people building production-reliable agents? Sure. I think reliability is the key word there. I think the headlines that we see if we're kind of swimming in the AI news and always trying to look at what's coming out next is the, we tend to see the examples of how people achieve incredible results on benchmarks. Yeah. But that is a completely different task than building a reliable agent inside an enterprise, where you're not really concerned as much with hitting theoretical limits of, like, intelligence, But you're like, "Can I do this one simple thing reliably, so that the rest of the people in the org who don't know how to wield this tool can use it with confidence?" Because that's where I see enterprise agents die, is if it's wrong 10% of the time, that's kind of the threshold. where people are like, well, why would I even bother to do it? I'm going to have to check all the work to make sure it's right. I'll just do it myself. Yeah. And so, one of the ways that we see people achieve that reliability, well, let me back up, one of the ways they don't achieve that reliability is they start out, if you are asked to build an agent, we're under pressure to ship, we have a job to be done, and usually budget is pretty robust. We've got some free tokens, or you know, there's the AI mandate, and so we aren't worried about cost or time or anything like that. So we then go and take a prompt and give it to the biggest, greatest frontier agent we can, and we just let it run. We let it figure out and discover that path. And nine times out of ten, it just nails it, and it's great. And now I've built a great demo that I can go show my boss, and they can check that AI box for them and their superiors. Now, the problem with that is as I use that agent, I'm going to keep finding weird edge case bugs because we it's kind of a black box how it's getting those that intelligence out. And as we find those edge case bugs, we're just going to keep adding them to the prompt. Hey, you know, you keep when you get this type of receipt in our budgeting system, log it as a receipt, don't log it as, you know, an invoice. And you keep having to do it, maybe you write it in all caps, maybe you threaten the mother of the LLM or bribe it, you have all these weird hacks. And these are all specific to that particular model. You're kind of overfitting to the model as you build. And pretty soon you have this really fragile prompt that has all of this insight and folk intelligence that you've learned just by using it. and it's really brittle, and it's hard to change. And that's what I call prompt debt, kind of like technical debt, which is you have this product that you've been working on for a long time, and now you have to go back and try to fix, and it's really painful. I see prompt debt all the time. And so people keep adding new lines, keep deleting new lines, maybe they try to start over when they have to go to a new model, and it's just painful. And so one of the things that is like our mission, especially with DSPy and other things, is how do we make AI more boring? How do we make it behave more like software, where I have kind of an expectation and contract, that reliability is critical. And so, when I see teams in prompt debt, when they get through it, they tend to arrive at the same innovations and concepts that DSPy adopts and has been living by as its philosophy for years, which is, "Hey, we need to have some typed inputs and outputs. We need to have some retry logic. We need to have, um, separate and kind of, um, structure our prompt so that it has a little bit of a schema, it has a little bit, um, of uh, of, uh, some contracts and inputs and outputs that are reliable. Yep. And then the other thing that we want to look at is they start to decompose maybe into multiple steps, which is rather than have one big call that does 20 things, hey, we actually see there's a couple things we can chop off and make into more reliable evals that... For anything with, I guess, from my intuition, here is anything with real world... messiness, and kind of assume the real world is like fractally complex, and like, yeah, we do want AI systems that ideally are 99.99999% reliable, because that sort of makes them incredibly useful, incredibly trustworthy, like the human plus AI pair, where, like, the human is continually, somehow in the loop, coaching and giving feedback, and, and imbuing their subject matter expertise, you know, into the model's prompts, harness design, etc., is, you know, at least for the foreseeable future, kind of going to beat, like, an AI-only approach. Well, they're two different tasks. And I think it's really important when designing whatever application you're working on is like, is this a human-in-the-loop application? or is it not? And we see enterprises fall back to human in the loop because they can't get reliability high enough. They're like, "Oh, I can get 9 out of 10. That's really good. I'll put some human there to smooth over the bumps," which is how coding agents work, um, and very much the case. If you just let it build forever, it's going to make a lot of bad decisions and then stack those decisions, and now you've wasted a ton of tokens. - Yep. - But at the other end, the bulk of enterprise use cases where I see AI delivering the most value is the workflow where the human isn't in the loop. Mhm. And it just takes a small enough task that you can make it reliable and encode that. And I think that's going to gain in kind of as we get better at building these workflows and agents.
