Evaluation Precedes Evolution: Rubrics as the Load-Bearing Infrastructure of Self-Improving Agents

Thank you. A year ago, shipping an agent was the work. We all did it. Writing the prompts, wiring the tools, hardening the failure models, pushing it until it actually held up in production. And many of us have lived through that. That problem isn't solved, but the recipe for that is almost with us. Customer support, coding, document processing, data extraction, like pick your domain.

But this year, the work has moved one floor up. Your agent doesn't just run anymore, it rewrites itself while it runs. So the techniques that are mentioned here, like genetic Pareto optimization, memory accumulation, simple prompt optimization, swarm self evolution, all of this, these are different names for the same shape, is your agent improves itself in production with or without you in the loop, depending on what you're going for. Now, it's important for us to understand what this iteration is happening upon. The agent is hill climbing on a rubric.

And here's what nobody's talking about. Over the last twenty months, frontier model capability has gone seven times has gone up seven times faster than frontier model reliability because we optimized for that. And it made sense to do that. Right? But then we have to be very mindful of what we are optimizing for. That's why today I'm going to discuss, like, how to ask for the right thing.

How do you define the rubrics while you're building your agents? In a lot of production systems, I see the rubric looking like this. It's either a paragraph or it's a vibe check, like give me a score from, like one to 10 on helpfulness. How do you iterate on a metric like that? Well, you don't. Every round of self improvement makes it more confidently wrong, if you're iterating on the right in the on the wrong thing. More compute, more iterations, and it gets worse.

That's the paradox of self evolution. You wired an optimizer to a rubric that does not either mean anything or it's not wired to a business metric or it's wired to something that you don't really care about. And the optimizer is gonna find exactly what you asked for. That's why evaluation precedes evolution.

Before you build the self evolution loop, build the rubrics. So I spent the last year staring at a lot of production rubrics across different domains, and I've come up with this mental model of what's the shape of the axis of what are the axes that you need to score your agents across in order to design your rubric?

So these access are basically like, I use them to describe the shape that the rubric has to take. The first one is verifiability. So basically, agent lies somewhere along these three access. So what's verifiability? That is, can you check correctness without a human? For example, a coding agent has like mid to high verifiability, and l to s q l has high verifiability, whereas a marketing agent has very low because you like, there are there's a lot of subjectiveness in there. Even though with low verifiability, you could define a rubric that distills what you want out of it.

So that's something we'll discuss. Horizon. How many steps does the agent take before you can get either a final output or before you score it? That's horizon. For example, a simple classifier, that's step one step. Right? Invoice processing, that's mid to long horizon. An autonomous agent that does research, that's generally long horizon.

The last one is stakes. Well, what happens when the agent is wrong? Is it recoverable or is it absolutely unfixable? That's also very important and it defines the verification budget. For example, in invoice processing, a refund issued I mean, sorry, an invoice that's paid to a wrong vendor, it can it can invite some audit risks. So that's like that's the risk.

Whereas if you reject a right invoice, that leads to an angry vendor. So think about like what where your agent lies in it based on the agents you've built. I'm gonna walk one agent, which is invoice processing, which we built through all of these three axes and give you examples of how to design the rubric, what are the principles around it.

Quick picture of invoice processing. A PDF lands in the system. It's usually an invoice accompanied with an email or a work authorization form. The pipeline classifies the document. It extracts the information that it needs out of it, does some validation, runs some checks against business rules, and then decides one of three things. Either pay it, reject it, or escalate it to a human.

Alright. So verifiability. Verifiability of invoice processing is split down the middle. You can see there is a deterministic check that runs before we hand it over to an LLM. Why is that? Well, in order for us to find out if this invoice is being it's a fake invoice, let's say, right?

You can run a set of deterministic checks. You can do an ABN checksum. You can make sure that the line items sum up to the subtotal. There's another thing that we can do is we can look at the vendor list. Is it in the list of the approved vendors?

Like all of these are checks that we run deterministically first before anything is handed over to the LLM. Because if the invoice doesn't pass these checks, there's no way that we're paying it. These are checks that can be run using regex or one basically these are like one line Python, like there's no compute, there's not a lot of compute required for this.

But then other things that need some semantic basically, things that are semantic, you need LLMs to verify. For example, is the line item going to be classified as emergency or labor? Does it actually verify with the work authorization form the line item correlate with the work authorization form?

So all of these things, for that you need an LLM. If we skip the deterministic layer, we're going to drive up our cost, and we're going to use LLM for things we don't really need. So principle one, deterministic checks always before semantic ones, before using LLM as a judge. Think about what can you quantify, like what are some of the deterministic checks in every domain that you're writing rubrics for.

The second one is horizon. Horizon for invoice processing is mid to long, and it runs through multiple stages. Now, it's important for us to break down what the agent does into components so that we can write rubrics for each component. It also some sometimes affects how you design the system.

So one thing is having a rubric for each step. It's very important because if the final output is wrong, you don't have a way to figure out where it went wrong. Rubrics that reflect the signal, which can be given to your self evolution loop, that's very important. The other thing is dimensionality of the rubric.

So we've discussed verifiability of discuss horizon. I want to take an example, brand compliance. Brand compliance, you can either ask an agent or ask an LLM to say, Okay, this is what brand compliance means to me in a prompt, and score it from one to 100. That won't give you the right signal as compared to you breaking down what brand compliance means.

Are the colors right? Is the copy right? Is it using the words that I really want? Or is the output like, are the words that I want not on brand? So there's a dimension so for long horizon agents, you break down the agent steps, score them. The other thing is if it's a short horizon, if it's like one step, you in fact break down the rubric itself.

So you build a multidimensional rubric. So it's all about breaking it down. So principle two, name the failure modes and score them on every stage, every dimension. The third principle is asymmetric verification. It comes in the axis of stakes. Well, what's the cost of a wrong pay versus a wrong reject?

So the way we designed the system, we made it really hard for it to go to a wrong pay. We made all deterministic checks according to that. And then if the invoice processing if the invoice is going through the wrong if it's compliant, like if it's passing all the deterministic checks, we're almost sure that we want to get it through to the next stages. But then there's a wrong reject, so the invoice processing system says that I need to reject this invoice because of some issues, we run more checks.

Why is that? Because there's a cost to that. The cost is human cost and relationship cost with vendors. So that's why you can see the asymmetry in the budget here. If the validation agent that's running, it says it looks compliant, we let it pass. But if it raises a problem and it says that it like a violation, we run it three times and we run it independently. And then if it says it passes even once, we let it pass. And like this I'm not saying this is the right design. Right? The right design depends on your business and your stakeholders and what they want from it.

Right? What are the expectations of SMEs? But here, we did not want a human to be alarmed. This would cost us actually more than letting the invoice pass by because we had some downstream checks that were taking care of the rest of the things. So principle three, design your rubrics according to the verification budget, and then like a lot verification budget according to the risks and the costs that are associated with which are generally asymmetric, think about it.

Then the other thing I want to talk about is business metrics. So two, three years back, I used to think that business metrics and a proxy for tech for that business metric is enough. Like a technical proxy for business metric is enough. But if you think in this example, compliance can be a technical proxy for a business metric.

But if the agent is optimizing for high compliance, it's going to raise everything, escalate everything to a human. And it gets high compliance. But then that also increases the cost. So actually, we found out the metric that we really wanted to optimize here for was invoices needing no manual intervention, and that was the metric that the business really cared about.

So it took us some iterations to find to figure that out, And that leads us to principle four, which is tying everything that you do and tying your rubrics to business metrics. Because if your agent is in a self evolution loop, it's going to evolve according to the business metric. And that's very important. So all of these principles wired in this slide.

There is an open source link to it. We've open sourced the code. It's actually in the ADK samples repository, the Google ADK samples repository. And you can go to invoice processing agent to see all of this code. The same principles we can apply in a different domain. The domain is NL to SQL. Principle one, deterministic checks first.

Course, you don't want to run an LLM if the queries are matching. The LLM output matches the ground truth. Principle two, naming the failure modes. So here we have a six category scorecard, which is weighted according to the failure modes. A column and a table selection is a schema failure, like if there's a wrong column selection or a wrong table selection, and that's weighted higher than the others.

There's operators and predicates failure, function failure, values failure, if the logical structure doesn't make sense, joins and ordering and syntax failure. Now one way to use this you know, rubric is, let's say I'm writing an NL2SQL agent to surface the output of this to an analyst, and it's not autonomous.

Right? So the way I would design the rubric and the way I would think about the business metric would be how much time does it take for an analyst to rewrite it or to check it. So almost their query takes less time, whereas a completely wrong query will take more time. So that's where principle three asymmetric verification and business metric come along in the same in a different domain, which is NL to SQL.

Alright. With that, we come to the end of my talk. Here, I've put up all the four principles. And if you want to connect with me, there is there are QR codes. So this work was done in collaboration with one of my colleagues, Puya. So his QR code is also up there. And thank you so much.

One of the curiosities with this conference is we don't have time for questions, but we do. I have a question. When you're preparing, especially a short talk, we've got eighteen minutes per speaker, you're gonna miss something out. So what would you love to have filled in that you didn't get a chance to?

I wanted to talk a little bit about agent tool call reasoning, like trajectory evals, which I didn't get a chance to talk about. I think those evals are really tough, and then it's hard to get them right sometimes. Yeah, just like that could have been a talk on its own as well, but I didn't get a chance to include that.

We've still got a couple of minutes. I unfortunately can't open the floor to the questions because I don't have an array of the mic. Can you take us through a little bit more of that just to

Yeah. Sure.

You do have time.

Okay. Great. Thanks. So sometimes, like, when we're evaluating the agent, we're evaluating the final output a lot of the times, right? And it's difficult to figure out where exactly it went wrong. And it ties back to second access, which I was talking about. So we can look at, okay, whether the two calls are working right or not. But sometimes, even if the two calls are right, the reasoning of the two call may not be right, like why was that invoked. And if, let's say, the reasoning is right, maybe the order isn't right.

Some in some cases, the order also matters. So I've manually did some iterations on some of the agents that I've built, especially the ones which have more tool calls, and then arrived at a decision that I probably need to split the agent, have a multi agent architecture, have sub agents, access to only some tool calls. So all of these decisions, if you want a self evolution loop to autonomously take, I think it's important to define that.

What's the right flow of the agent? Why do you want one tool call first? What's the reasoning behind it? All of that, right? So to evaluate that, there are many ways you can evaluate it. You can define the tool call sequence and make sure that it's it's happening. But then there is obviously some probabilistic you can't really rely on it all the time.

So I think that's a very it's a very complex system when you have multiple root cause and multiple agents and which one needs to be called. And then it's very good to define. So what I'm generally doing now is I define the state machine that I'm looking for, the workflow that I'm looking for. And I either enforce it at my routing level, where I call this agent, then this agent, then this agent, and for this agent, just call these tools in sequence.

And that generally works really well. You just define it, define your own workflow. But it takes some iterations to get there. So yeah, that's

So I'd see that as an extension because you started showing deterministic calls first before you throw to the agents. I guess if you know what to expect out of each agent, you know which order to run them in according to the context in which you're operating.

Absolutely.