You're Not AI-Fluent Until You Understand Evals transcript

My smartest AI friends told me, "If you want to call yourself AI fluent, you need to understand evals and how they work." So, I hit up a leading AI researcher at one of the fastest growing AI companies in the world to teach me and you about all things eval mode to god mode. You'll learn what evals are to how to run them yourself. Let's get nerdy. [music] So, let's start at easy mode to understand what eval even are. The way that I think about eval at the simplest level is essentially your agents are already doing work for you.

All you really want to do with an eval is check whether that thing that the agent did is like right essentially. And a bunch of the actual sauce in right comes in taking like what I think right is or like what I think or what my organization thinks right is and encoding those principles basically into software. My assumption is is sometimes eval are easy like was this tool used or was it not used and then I would assume it sometimes is more nuanced if it's like there is not a black and white answer to the question.

There's like some level of agents that you can check a very narrow specific thing and like this can be like a simple Python functions like I have like three examples here. Um one is like okay I have a CRM and I'm trying to add a note to it. This is like a very narrow thing that I can check the before and after state in a database and see like hey like this field was empty and I ask my agent to do something does that field like contain the value now the next thing is did it fill the right thing maybe two years ago we were very like simple with our agent ambitions it was like hey like can you summarize this email for me and like now it's sort of like do this entire company research for me like draft the entire report and then get it ready to send to like all of our leads essentially, right?

And like personalize it to every single company. That's like much more involved to actually evalumize this email for me. So I'm going to just like quickly go through like the easy mode like mental model of usually where customers are starting and like let's say you have no eval, you're just using like cloud code, codecs, deep agents, uh any of these like agent harnesses like how should you basically think about starting with eval?

So um usually where people are starting is they have like some agent in prod or let's call it like semi-pro. So this is usually like some sort of like internal internal use case, right? That agent is interacting with like some external system and that external system might be like uh sticking with this GTM example. Let's just call like Salesforce basically, right? So this is our this is our CRM, right? And then the thing that it's doing is that it's like editing it's reading um it's yeah let's just let's just do editing and reading right so it's like agent editing reading my salesforce right and then what I need to come up with are basically like tasks and tasks are essentially small things that I need the agent to do that I can check the correctness of after.

So like what are common examples of tasks? It's writing an email and updating an entry, right? So this is like very common for GTM folks. It's like you get some data and then you need to respond to some email, right? This is basically like uh finding info about a person across multiple tables, right? So for example, I have a prospect. I know that he works at like acme co uh but like he's not in the like rep's table he's actually in like some other table and I need to like find that information right so these are essentially like tasks that we're creating and then what I have to do is like I need to build some sort of like verifier so like now this is maybe the first like vocab word I'm throwing out which is like okay um I have this task what a verifier is literally supposed to do is just say that task happened was it right or was it wrong right like this is literally the only thing that we have to do and like where do we start we start with like agent agent interacts with the database like salesforce or like gong or something like that I come up with some tasks that reflect what my like real colleagues are doing in the real world which is like they write a bunch of emails or they do a bunch of like person research or like company research and then what I do is like I come up with a way to see did the agent do the right thing.

So like what this might be is like check if the um tags for person include like email sent right so it's for example like I'm sending an email is this like somewhere tagged on that person like yes we've reached out to them let's like check the box right and like this might just be like a Python function or it might be something like um does this email have like three paragraphs, right? So, this is something like the pros of an email or it's like the the length of an email and sort of like your your company brand guidelines on like how communication should be set, right?

So, it's like I have an agent interacts with a system. To measure that system, I need to like come up with some sort of thing that like real people in the real world are doing and then I need some sort of like verifier to to measure whether it's doing the right thing. Originally, when you used the word verifier, it sounded like, and maybe this is the nuance, you said it is a yes or no. Like, yes, the tag was added of email sent or no, the tag was not added for email sent.

Should someone be thinking about it as like I need to be able to codify what my voice is into yes or no questions in order to basically train an agent the right way? >> Let's talk about that in like a little bit of detail. Not everything is immediately verifiable, right? So I can't just like look at something programmatically and be like, "Oh, this is always right or this is always wrong." There is like a ton of work that actually goes into taking like human priors or like human preferences and then putting those into checklists.

And the easiest way to make a checklist is just yes or no. Like this is this is also like backed up by like a bunch of research where like if you try to calibrate an LLM between like a score of like 1 to 10. It is like very susceptible to that like in the middle problem of like it always says seven or always says like eight because like the the data on the internet kind of looks like that. So it's like it loves to hedge but like if you have a binary score it is super hard for you to like you can't hedge like either it is or it isn't.

So like one thing that comes up a lot is taking things that aren't like immediately verifiable and then turning them into checklist. So for example like is this like three paragraphs long like X or yes, right? like um is this like um pulling from the brand guidelines on pros like X or yes or on on pros, right? Um so yeah, it's essentially like some human does a bunch of work up front and they say like okay, this is all the stuff that matters in these like communications.

I'm gonna write them all down and I'm gonna see if an agent that follows this checklist actually does a good job. And then like I sort of do the human review. I'm like, "Hey, this sounds good or this doesn't sound good." If it doesn't sound good, then like maybe my checklist isn't complete enough or like maybe I need to like add stuff to it or like maybe my prompt isn't good enough. >> Awesome. So this is clear. Basically, it's agent needs to do work.

To do work, it's interacting with some system. In this case, that system is Salesforce where it can edit fields in Salesforce or it can read information from Salesforce. There's some set of tasks that the agent can do. In this example, it can update fields after I have a call with a potential client. It can also write a draft email without sending it to that client I spoke with. And in order to feel confidence in the agents ability to do these tasks I just mentioned, you have a verifier which is basically the checks that exist to make sure that the agent has kind of gone through the rubric or the yes or no questions to ensure that it is staying kind of like on track with the specifications we set for what a good versus bad job at the task looks like. >> Yeah.

Exactly. Exactly. And like all of this is sort of like human derived, right? It's like um what makes a good verifier? Well, for like non-verifiable tasks, like let me get the best guy at this job at our company to like write those things down. So then we can we can just like have that for the future. >> Let's go to hard mode. >> Awesome. Let's do it. [music] I'll basically now go into using the language of environments for everything.

Like this is another like vocab word that I'm adding. And the reason why I'm I'm sort of saying like evals and environments interchangeably here is like maybe like four years ago, three, three, four years ago when like chat GPT first came out, basically what we were doing is like we were typing things in a text box and we were just getting like a prompt in and like a response out for for better or worse like we don't do that anymore, right?

Like we basically put in a prompt and we expect a ton of work to actually be done in the real world and that means just like measuring prompt in and like response out just at that like one unit level sort of like isn't enough anymore. And the thing that we're actually building now uh to to like measure the quality of agents is this thing called like an environment. So like let me actually define what an environment is and then kind of like how we talked about in like easy mode which is I have an agent it does work and like I need to measure it.

Let's talk about like how you actually create environments or like where these environments come from, right? So an environment at a very high level is like where an agent does work, right? So today if you download cloud code or you download like codeex or like deep agents or something um you install that and I'm like typing into my terminal and the place where the agent is doing the work is like my computer, right? So it can see my files.

Um, maybe I give it like access to my browser, right? Or like maybe I like log into my email, right? So it can like go and like access that stuff. The totality of all that stuff like my files and my file system, like the apps on my computer, the permissions that I give the agent access to, all of those reflect the environment that the agent is doing work in. Right? So like with my computer it sort of makes sense but like for for companies and like clients that we're building agents for what that actually looks like is like their agent on their data that has like their very specific permissions right so for the GTM example right like we have some sort of like production system right like we we have Salesforce like we use Gong we use like notion we use all these tools so like that has that sort of has like real data in there right and to test my agent it's not cool if I just let my agent go and like edit real production data because like what if it messes up, right?

I like I want to keep my production data like completely separate from that. So what what environments like actually are today is they're like recreations of existing software like existing tooling that sort of mirrors the work that like real agents do. So it's like I have my prod system which is like Salesforce or like Gong or like notion or like S3 for example and then what I have to do is I have to sort of like simulate that and make it look real to the agent but it's not not real so it doesn't like overwrite my data and stuff.

So what that might look like is okay my Salesforce actual tables right it has like these companies in there it has like these drafts in there. Um what I need to do is like look at my real system but don't copy it. just like make the agent think that it's operating in like a real like a real CRM. And then what I do is I like let it take actions in there. So it's like find someone, add a note, create a draft. Like these are all the eval types of tasks that we had in the first like easy mode section, but I have like a completely separate sort of like isolated place where it can't actually like mess with my production data. is the right way to think about this is basically if eval are kind of the the way that you evaluate the performance of an agent and improve that performance over time so that you can trust the work that it's doing.

Environment is the place that that evaluation happens so that you're not messing with all of your like live contacts and live files in your company. It's almost like the training ground. It's the practice area before it goes to the real deal. >> Exactly. Yeah. So it's like a a sort of digital clone or it's like this this training ground area where I can like >> tweak anything about the actual environment to to test like different things in my agent. >> Maybe this is a dumb question, but like if a person if a non-engineer wanted to set up an environment, how hard is that to do today?

How much has like the tooling evolved to let a non-technical person set up an environment to test agents and run evals? >> It's a build versus like buy sort of thing. And like a lot of this tooling is open source. So like you can use it. Let's talk about like how easy it is. So like what we use for everything is this like framework called Harbor. And the things that we actually have to set up when we're building building an agent is like one how do I manage my tasks, right?

So it's like I might have a bunch of different teams and they all have like different tasks. So the the team that the GTM engineering team is doing like those tasks like look very different than like what our what our software engineers are doing, right? I basically need a place that like separates maybe all those tasks by team. Um, but I don't want to like roll it all myself. What's the other thing that I need? I need like some sort of environment that's like specific for my teams, right?

Like again like software engineering tasks like look very different than like GTM engineering tasks, right? And then like I I want the infrastructure to be able to like run these at scale, but I probably don't want to build that all myself. So taking like all of those into account, one thing that we do is like we we use Harbor and like what Harbor basically gives us is a good set of abstractions so we don't have to manage this ourselves but we can go like lowle when we need to.

So like what are the things that like harbor actually gives us? It gives us like some sort of specification for building environments. So it's like an environment is like a it's like a a thing that I can populate with like my specific task information or like my specific simulated data and it gives me some sort of abstraction to do that. It also gives me abstractions like for the verifier, right? I could manage a bunch of Python functions myself and I could like roll all this logic or I could sort of use something that's trusted by sort of like all the Frontier Labs and like all the Neolabs and like all these like agent engineering companies and it's like so it's really nice to have something that like everyone agrees on.

And maybe like one other thing that's really good at is like everyone is still figuring out evals and that means that the more you use these sort of like accepted frameworks the more that we can go and borrow evals from like other companies that publish them. So for example like there's tons of evals in hardware format right and like GTM engineering that's like a pretty common task that a lot of other companies have.

So there's a lot of hardware environments that basically already exist that look like GTM engineering. I can just like download them and sort of like bring them into like bring them into our GitHub or something so I can go and measure some of those things. Like this is a tooling we use. I would say if you're starting out and you've never made an eval before, the easiest thing to do is just like go grab an eval in like Harbor format from an existing like existing data set and then just ask like cloud code or codeex to explain to you like hey like how does this work?

Like does this work from my agent or do I need to like tweak it in some way? So like all the primitives for like environment building, verifier building, instruction building, the infrastructure like running sandboxes like that exists. It's open source. You can inspect it >> and you get like really good community benefits. Uh someone else maybe has done this task before. I think this is like a generally a benefit of open source.

Are there like actual software projects that have kind of like abstracted away all of kind of like the complexity of this where you just have a a UI and UX that lets you do this in a kind of visually appealing and simple way? The dream is essentially to have some sort of abstraction. So I think there's like layers of abstractions, right? So there's like >> there's sort of like the model, right? There's like the weights of the model, right?

Then there's like an agent on top of that, right? And then like I think the same way they have abstractions in like agent world, you also have abstractions in like eval world which is like yes at the base I might have like harbor which has abstractions for like verifiers and like instructions and like sandboxes and things like that but there's a big class of people who do like very valuable work in the world that like they don't want to know what hardware totally like it's also not useful right they just want to do know that their agent is like doing the right thing.

So like we like I work at Langchain. We have like a product. It's like lang engine that helps you basically like make evals at scale. So I think like one thing that comes up a bunch, right, is hey I I ran the agent like I have some sort of agent like I don't really have evals for that agent, but I do know how to say whether an output is like good and bad, right? Or like I'm good at sort of like giving feedback when an output is good or bad.

And I just want to be able to do that in a UI. And I think we see like a big need for this. So like we we built engines sort of for both. So like one is >> like literally like this is on on the right like this is like an actual screen right? So you can like see the types of things it's like suggesting to you. Um you can like go and look at the emails that it's making and you get like highle statistics or like if you want to go and like dive into the code we also have like a length CLI.

So you going to dive into that and I think what what will end up happening is teams will end up using a mix of things. So they'll use like the devs will continue to use like GitHub and like hardware for a lot of things and then like there will be products like Lenman engine that are sort of like built on those primitives and like built on your actual data to make it easier to make those. I talked a little bit about okay so like you build an environment right um how do you know that your environment is correct right so because I think like like everything in like software engineering before usually your first pass is just wrong for one of like a million reasons and you need to figure out how it's wrong right so it's like one thing for building environments and I tell like people who like build agents this as well like my first environment is like never it it it's it's wrong in some ways.

And one thing that like we're trying to just like open source and like share blogs about and just like talk about is essentially like if you build an environment, one way to know that the environment is like good or bad is by running a real agent in the environment and then like seeing what happens. Like if I ask you to like, hey, here's my agent. Can you make my prompt better? like you'll have like some vibe of hey like these instructions aren't clear but like you won't really be confident whether this prompt is like better or worse until you run it on a real thing and like environment design is very similar.

So like one thing that like I sort of like call out explicitly is um one thing that we actually do a bunch is that like we run a bunch of different agents in the environment. So we'll use like GPT 5.6 like soul or we'll use like GLM 5.3 or GLM 5.3 flash or we'll use like a small Quen model and then we'll sort of see how these different agents like behave in the environment and that tells us like hey we we can look for like weird patterns right if like soul is consistently like failing on this environment like Quen is sometimes passing like that's like a little weird like we we should look into like why that's happening.

Another thing that we see is like is our environment like leaking information because like agents if you give them a task they will like cheat and they will figure out any way to solve that task right so if there's like some sort of answer is like hidden somewhere in the environment somewhere like I don't know like one of your database entries says like hey like answer placeholder right like the real world doesn't look like that so like if you run a real agent then you can like see like oh soul found this and I can like review it with a human and see things like that so it's like similar how like agent engineering is like very iterative and like you don't know what happens so you run the agent eval and like environment engineering is also like quite iterative like we we have like a bunch of humans that like go and build them and they they sort of review the outputs with humans there's so many moving parts to doing eval because it's like you have the task and like we use the go to market task right you have like the the logging that a call happened the writing the draft response and like that task that workflow could evolve over time which would require you to run new evals, but then it's also you have all these models and these models are constantly changing and something that we hear constantly um at 10x from from clients and from enterprises is basically like how do we figure out effectively like what is the the optimal model for every given task?

What is the model that is the cheapest but it is the most performant where we're okay with however it performs in this context like how does one figure out that answer and how do you do it in a relatively programmatic way so that like anytime a new model comes out it isn't this like massive project to then basically retest a new model. This comes up because the rate at which the labs are putting out models has only like accelerated in the last year and a half.

And at the same time like o open models that that you can like run yourself or like you can run through like thirdarty inference providers like fireworks, basan, prime intellect like those are smart enough now that like you should consider testing those as well. Every time a new model comes out how do we know like if we should use this or not and if it's going to be cheaper for us essentially, right? So it's like this is literally what we have. we have like this box which is our like evalu that's like built up right so this is like um software engineering tasks this is like GTM tasks this is like code review tasks right so we we have a bunch of tasks like each of these I'm writing them out because we tag them essentially right so like I I want to know like what family each task belongs to so like I if a new model comes out and like I think it might be good for like GTM uh because it's like the the writing and the pros is like really good.

Then like okay, I'll only test it for this, right? But it's like I can minimize the amount of tasks I'm actually like running on. It's just like good for organization. >> And is that what an evaluite is? Is an evalu basically just a list of all of the tasks or all of the evals that you run? Does it also include the verifiers that you were talking about? Like what how do you actually define what an evaluite is? >> Yeah.

So like maybe like let's draw like a single task, right? So it's like I just have like one task and like what are what are the things that that goes in it right? So like this is like single single task right and it has it has the verifier in here which is like how do I check that something is correct. It has the instruction for the agent which is like the the input prompt like uh hey go do company research X for me right?

And then it has like the environment file which is like we don't have to get like too technical but it's like it's usually written in docker and like a docker is like a container right a container is essentially like a sort of like fixed in time uh object that captures like your data um like all the tables for example right like all the tools that are installed right >> cool >> um this is essentially like one task and I'll have like variants of this for software engineering tasks like it be like a Python related task or like GTM task which is a company research and then like my eval suite is essentially a collection of these right like I have a bunch of tasks that I like tag to like software engineering or like GTM like code review we're talking about like a new model was released right like what do I do literally what we do is like we have like a model catalog right and like a model catalog is essentially like the list of models that we might run right and then this might be like opus GLM 5.3 like 5.6 six soul, right?

And then like literally what we do is we will then like run each of the models through our eval built-up suite or like maybe we only run on like the software engineering tasks, right? And then like after that we get like scores essentially, right? And like what's what scores basically tell us is like opus opus gets like a opus gets like a 60%, right? like Opus got like 60% on like right like GLM 5.3 got like I don't know like 55% but like GLM 5.3 is like 3x cheaper right so so now this is like a human decision as well which is like is this task is the 5% more valuable to us or is sort of like the cost and the speed more valuable to us right and it's like the only way to really know what these trade-offs should be is by like having an eval suite that we can like continuously run these different models on and then testing to see like it's all a trade-off like there's a cost versus a speed versus like an intelligence trade-off like this will always sort of be the case but different tasks are like valuable differently to like different users right so like internal task we're like it's fine it's like way cheaper but anything that's like userf facing we're like no like we actually want the top tier intelligence or like we want the top tier speed for them.

So like how do how do we get that? >> Awesome. Super helpful. Um okay, let's uh let's finish this thing up with god mode. [music] >> The hard mode that I talked about is probably where most agent engineering teams are like getting to right now. And I would say like there is one level basically above that which is this like continuous cycle of I run an agent I produce like production data of like that agent operating the real world and I turn those evals into production data or I turn production data like into evals.

So I like continuously improve my agent over time. So I think like this is the actual like dream and the promise of like running agents that actually self-improve. And this is like maybe some sort of a hot take, but I think like if your team is really really good at turning production data into evals, then you can basically continuously improve your agents. And the the reason that is is like literally what you do when you take an agent and you like fit it to an eval is you like alter the agent so that the eval passes, right?

Like the whole reason I have eval is to figure out like where the agent fails and like I don't just want to know that it fails. I need to figure out what I need to change in the agent so that it never fails again. Right? And there's like I talk about this a bunch, but there's like two main buckets that we're seeing. One is harness engineering. So essentially that's like tweak the prompt, tweak the tool definitions, like tweak the tool descriptions, right?

Like tweak your model choice, right? like maybe use like Soul and Opus together or use like GLM5 and like Opus together, right? Like make those choices. The other thing that we're seeing a bunch more on is because open models are so smart now and the infrastructure for like fine-tuning exists like people are like literally taking their task that they use like opus for exclusively and they're using a small model fine-tuned on their production data just for that narrow task and it's like 10x cheaper and it's doing the same as opus like for most of our task like I don't care that like this this fine-tuned model can't do like frontier math like this is a GTM agent like we don't actually need to do any frontier math.

So it's like these are the two categories that we're seeing a bunch. I think god mode essentially comes from collecting a bunch of real production data turning it into these like eval environments that we talked about and then sort of choosing how to improve your agent. So I think like prompt engineering, harness engineering, great place to start because it's like very cheap. But eventually I think we'll see a interest and an explosion in in teams looking at like fine-tuning their own model so they can like own like own their intelligence, right?

It's like I have this specific model for my specific task. >> How do you basically get the loop of improvement to spin as fast as possible where agent go to market agent is helping you with your go to market workflow. It does some output. That output produces some result. That result leads to some learning. That learning makes it even better the next time that it does that workflow. As I think about this loop, the biggest bottleneck here is still the human.

It is the human who has to take the time to update like the verifiers or the rubric. So I guess there's two questions here which is like how do you get this cycle to spin as fast as possible and can you have this like agent improvement loop happen without a human in the loop or so I think like these are essentially the two questions that like underpin whether agents can improve themselves autonomously. It's it's essentially like I need to minimize the contact points for humans uh that are actually like touching this loop.

So I think like there's there's one point which is like what what is the loop right? I think like if you're an organization that's like trying to use agents in practice today like the first thing that you should basically do is like go from agent to like collect trace data because like it is essentially impossible for humans to reason about like what an agent will do. But like when you put it in the real world and you actually see what it does in practice, it's very easy for humans to see like this was right, this was wrong.

But that only comes from actually looking at like live data. I always say it's like just turn on tracing because if you turn on tracing for your agents and you can see what they're actually doing. The more like exciting question that you're asking is >> and wait just one question here because I think this is actually super important for people. People hear traces or trace data they don't know what it means. Um ex just define what traces are and then if I'm a person who's trying to do evals for the first time on my agent to improve it.

How do I actually like turn on traces and where do I keep my traces? Like what? Yeah. What happens with the the whole trace thing as it relates to like a user working with them? >> The easiest way to just explain traces you have like an agent and then like it just does stuff, right? Like whatever the stuff is, right? But that like stuff is essentially like tool calls, right? Which is like uh go and ping Salesforce or go and do web search, right?

Like just just do actions essentially, right? Like and I want to log all of these like tool Traces are essentially like logs of every single action that the agent actually did and like how it like interacted with whatever system it did, right? And it might be like um these messages from agent, right? So it's like you know when you're talking to an agent it's like does a bunch of like web search tool calls. It's like uh then it comes back to you it's like hey I did all this work and like this is the answer to your question basically right so like this is what traces essentially are. um like lang chain we have like lang smith which is a place to like store all of this data across your entire organization like centralized in one place so that's like what what traces are right it's like every single action that an agent is doing stored somewhere so like when we say like turn on tracing like literally what that might mean is like tell cloud code um all of the data that you're outputting that lives somewhere here go take that data and just read it yourself or if you're like a company doing this at scale and you need like permissions management, all that stuff, then like go use like a provider like Langmith that goes and does that for you.

Like there's a lot of value in the data itself, but to like unlock the value from this, you need like agents that are reading data produced by other agents. So this is like kind of like agent for mining traces, right? Right? So the these are like two different agents, right? I think like this is like an important distinction. This is like my GTM agent, right? Which is like doing a bunch of work and it's like doing the actions, interacting with the users, but then I have like another agent that's like reading all the traces that this agent is producing and it's telling me like, hey, like the way that it actually like does search is like super inefficient.

It always like looks at the wrong tables and it's probably because your prompt is like super unclear where all this data actually lives. Or it's like every time a user asks for like multi-comp, it's always just doing single company research and it's like it's losing all that information. Like you have like very specific agents for cheaply understanding this data at scale which then helps you go and like improve this agent, right? to like improve agent and like the only real way to understand like how to improve an agent is by like running the agent like in production to like measure all this stuff or like running on the evalues then become like a proxy for like real world behavior but like this is like the golden piece which is like run data in the real like run your agent on data in the real world and then like see essentially what it does. >> Yep.

And then the last question here is so basically what you're saying is agent runs on real world data. Let's say it there's some outcome or it does something that you don't want it to do. The only way to really know why it did the thing that it wasn't supposed to do is you look at traces which is basically like the receipts of its whole history of every action that it took to do the job. And then by understanding what wrong step it took to do the job, you're basically going to improve the agent to not make that wrong step again.

Now I guess the question is is how do you improve the agent and does a human need to be the one to improve the agent each time? The level of human touch points look like they're diminishing with every model release. Like the models get smart enough that it takes less and less instructions for humans for them to figure out like two things. So like here I'll basically just show like roughly how the workflow looks today but with every new model I would say this shrinks right so like today I have a human which like explains to this agent what to look for right so like I so this is like a human writing a prompt of saying like hey like look for all of these things like this is good behavior like this is bad behavior but this is like mostly happening like upfront with some edits over time because like this instruction is never perfect, right?

And then like once you do this like an agent can look for like failed tool calls or like doesn't follow instructions properly or like doesn't fully follow instructions and then like it makes all of these like proposals for what to do to improve the agent. So like this flow here which is like improve the agent, this gets more and more autonomous every time. So like what this actually looks like is like um new prompt, right? new tool, right?

Like different tool, right? So all these types of things and like agents are getting very very good at figuring out like what to propose to like improve this agent, right? And it's like if you have a good evalu like a good way of like measuring bad behavior in production and you just like let an agent run overnight, it's very very good at doing this. this it's like maybe less good at because every workflow is unique, right?

It's like some human still today needs to encode like what good looks like, but it can be like an upfront task, right? The that's like part one like where where humans come in. Like I think the the second part where humans are still like very very valuable is like this is production data, right? And I want to turn this into I want to turn this into like evals and environments, right? Um this still benefits a lot from human review.

And the main reason why is like it's not that agents can't make environments like from production data. It's like yes they can like observe a failure and they can say like okay I'm going to make a test so that I don't know every time if a user asks for like three company reports it actually gives like three company reports. It's like it's mostly the human review isn't encoding the things that your company actually like cares about, right?

Because there's like a million things that an agent can actually do and like you a bunch of like users actually do like they they might use your agent for a bunch of different things. like human review is still like very valuable here and writing down like I want this agent to be like very very good at like company research and like writing like very succinct reports and updating our Slack with like a with like a summary after all that stuff happens right so it's like yes I have the agent definition but like how do I know like that's the thing that your agent needs to be good at if if I'm an agent like I I might figure that out but the easiest thing is like some sort of like human counsel comes comes down to like they write down, hey, these are the types of tasks I want to create.

Like, let me go and like review them over time. And I think like humans writing down what good looks like is still one of the like highest leveraged things an organization can do. Um, they don't have to write the entire environment by themselves, but like shifting towards review of like this is the stuff I care about is something that like will still continue to be important even though like I'm not writing the code for the environment myself on every iteration. >> Love it, Viv.

This was awesome. I feel like I've gotten so much smarter on evals in the last 45 minutes. So, I really appreciate you breaking down everything from what they are to what environments are to how do you create kind of this efficient loop of running evals in production and then improving uh agents through better evals and through better prompts and all the different levers you can pull to make sure that agents do good work for us.

And um yeah, I think this is going to be the first of many conversations, but really appreciate the master class here, >> dude. Love it. Always love talking to you. Always love talking to you. This is a fun one. Thanks.