Building and evaluating AI Agents That Matter

[on-hold music] The theme of this conference today is Agents at Work.

Unfortunately, for the next eighteen minutes, you'll be stuck with me talking about how agents don't work very well today and how we can do better when it comes to AI engineering.

So there is so much interest in agents from all fronts, in the product world and in the industry world, in academic labs, in research. If you're someone who doesn't think that companies will be able to scale language models all the way to AGI, then what we are going to see more and more of in the near future

is agents that are not really deployed directly, but function as small parts of larger products and systems. And this is what AI is probably going to look like in the near future.

Six came up with a few dozen definitions of AI agents. This is one of them, where language models control the flow of a particular system.

In fact, even when people naively think of, um, ChatGPT and Claude as models, uh, these tools are actually examples of rudimentary agents at some level. They have input and output filters.

Uh, they can carry out certain tasks. They can call these tools, and so on. So in some sense, agents are already widely used as well as successful.

We've now seen mainstream product offerings, uh, that can do a lot more. OpenAI's Operator can carry out open-ended tasks on the internet. The Deep Research tool can carry out thirty-minute-long report writing tasks on any conceivable topic.

So that's the first reason I think today's conference is timely. But the second reason is that on the flip side, the more ambition-- ambitious visions of what agents can do are far from being realized.

So on the left here is a vision for what agents can do, something out of science fiction films like the film Her. And on the right-hand side are how these ambitious products have failed in the real world so far.

Now, I'm pointing this out not to criticize the specific products on the slide, but to genuinely challenge the audience into the challenge of building AI agents that really work for the people who are about to use them.

And so over the course of this talk, I'll talk about three main reasons why agents don't yet work and what we can do to realize, uh, the potential of agents to get past some of these failures.

The first one is that evaluating agents is genuinely hard. So to begin, let's see some examples of how when people have tried to productionize agents, these agents have sort of failed in the real world.

DoNotPay is a US startup that claimed to automate the entire work of a lawyer. Um, the startup co-founder even offered a million dollars for any lawyer who would be willing to argue in front of the US Supreme Court using DoNotPay i-in an earpiece.

In reality, a couple of years later, in fact, very recently, the FTC fined DoNotPay hundreds of thousands of dollars. The reason for the fine was that the performance claims that DoNotPay seemed to be making were actually entirely false.

Now, you might consider this a case of rushed invention of a small startup making claims that it cannot back. So let's look at some of the work from more well-established companies.

Law firm Nexus-- LexisNexis as well as Westlaw are widely regarded to be some of the leading law tech firms in the US. A couple of years ago, LexisNexis launched this product, which it claimed was hallucination-free in its ability to generate legal reports and reasoning.

But when Stanford researchers evaluated LexisNexis and Westlaw products, they found that in up to a third of cases and at least a sixth of cases, these language models hallucinated.

Um, in particular, in some cases, the hallucinations basically completely reversed the intentions of the original legal text. In others, the paragraphs were made up. Uh, they have about two hundred examples of such errors, um, in leading law tech products.

We've also heard examples of AI agents soon automating all of scientific research. So this is an example from startup Sakana AI. Sakana claimed they had built a research scientist that could fully automate open-ended scientific research.

Now, our team at Princeton wanted to test this claim in the real world, in part because automating scientific research is one of our main research interests. So we built a benchmark.

We created this benchmark called CORE-Bench. The tasks in this benchmark are way simpler than what you might expect from open-ended real-world scientific research. Um, they just try to reproduce a paper's result, even providing the agent with the code and the data needed to reproduce it.

So as you can imagine, this is far simpler than automating all of science.

What we found is that the best agents as of today cannot even automate scientific research reliably. Less than forty percent of the papers can be, um, reproduced by the leading agents.

Now, of course, you can see these models getting better, and even if an agent can automate only forty percent of reproducibility, that is a huge boost because researchers spend a lot of time reproducing baselines from past results.

But on this basis, to argue that AI can soon automate all of science or that agents will ren-render scientific researchers obsolete is way too premature.

In fact, when people actually looked at how well Sakana AI's AI Scientist worked, they found that it was deployed on toy problems, that, uh, it was evaluated using an LLM as a judge rather than human peer review, and that, in fact, once you start looking at the results, they turn out to be very minor tweaks on top

of other papers.

Think undergrad research projects rather than fully automating all of science.

Now, a couple of days ago, as I was preparing the slides for this talk, I came up with another claim, or Sakana came up with another claim, where they claimed to build an agent for optimizing CUDA kernels.

The claims were indeed very impressive. They could lead to a hundred and fifty x improvement over the standard CUDA kernels that PyTorch comes with. The issue, though, was that if you sort of analyze their claims one level deeper, you would see that they were claiming to outperform the theoretical maximum of the H100 by thirty times.

Clearly, this claim was false, and once again, it was because of the lack of rigorous evaluation. It turned out that the agent was simply hacking the reward function rather than actually improving the CUDA kernels.

Once again, the point is not to call out a single company, but rather to flag that evaluating agents is generally a very hard problem. It needs to be treated as a first-class citizen in the AI engineering toolkit, or else we continue risking failures like the ones on this slide.

The second reason why building agents that work in the real world is hard is because static benchmarks can be quite misleading when it comes to the actual performance of agents.

And that's because for the longest time, we focused on building evaluations that might work pretty well for evaluating how well language models do. But agents are not the same as models.

For example, for most language model evaluations, all you need to do is to consider an input string and an output string. Those are the domains where language models work.

It's really enough to construct evaluation. On the other hand, when you're thinking about agents, these agents need to take actions in the real world. They need to interact with an environment.

And so building this sort of evaluation that makes these changes possible, that creates the virtual environments within which these agents operate, is a ma-- way harder problem.

A second difficulty in evaluating agents is that for LLMs, the cost of evaluating a model is bounded to the context window length of these language models. You can basically look at these evaluations as having a fixed ceiling.

But when you have agents that can take open-ended actions in the real world, there isn't any such ceiling. You can imagine these agents calling other sub-agents, there can be recursions, there can be all sorts of systems, uh, maybe just LLM calls in a for loop.

And because of this, cost needs to be, once again, a first-class citizen in all evaluations of agents. If you don't have cost as an axis alongside accuracy or performance, you're not going to really understand how well your agent works.

And finally, when you build a new benchmark for a language model, you can basically assume that you can evaluate every single language model on this benchmark. But when it comes to evaluating agents, these agents are often purpose-built.

So for instance, if there is a coding agent you want to evaluate, you can't really use a web agent benchmark to evaluate it on. And this leads to a second hurdle, which is: How do you construct these meaningful multidimensional metrics to evaluate your agents rather than, um, relying on a single benchmark to evaluate how well it works?

Now, all of these concerns might be thought of as theoretical. Um, you know, you could reasonably ask, why do we care if static evaluations don't really work well for agents?

The reason is that because of these differences with the cost and the accuracy, because of the singular focus on optimizing for a single benchmark, we are basically unable to get a coherent picture of how well an agent works.

So at Princeton, we developed this, uh, agent leaderboard that tries to solve some of these issues. In particular, for example, for the CORE-Bench leaderboard I mentioned earlier, um, you can have multiple agents which are evaluated with cost alongside accuracy.

So here on this Pareto frontier, you can see agents like Claude 3.5, um, scoring about as much as the, um, OpenAI's o1 models. But a Claude model actually costs fifty-seven dollars to run, whereas o1 costs six hundred and sixty-four.

Even if the performance of OpenAI's o1 was a couple of percentage points higher, which it wasn't in this case, by the way, but even if it were, for most AI engineers, the choice here is obvious.

You would any day of the week take a model that costs ten times lesser while performing about as well.

Now, in response to this sort of two-dimensional Pareto, um, I've often been asked, um, are LLMs becoming too cheap to meter? In other words, why do we even need to care about the cost of running an agent if the cost of, uh, querying these models is dropping drastically?

And it is indeed true that costs have dropped drastically in the last few years. If you compare text-davinci-003, which was OpenAI's model back in twenty twenty-two, um, to today's GPT-4o mini, which in most cases outperforms this older model, the cost has dropped by over two orders of magnitude.

But at the same time, if you're building applications that need to scale, this type of approach is still quite costly. And especially from the point of view of releasing prototypes, one of the barriers is, for AI engineers, is you really need to sort of iterate in the open.

And so if you don't account for cost, your prototype might soon end up costing you thousands of dollars.

And finally, even if the cost of, uh, scaling inference time, um, LLM calls continues to drop, what is known as the Jevons Paradox, I suspect, will keep increasing the overall cost of running agents.

So Jevons Paradox is this theory from a nineteenth-century British economist who figured out that as the cost of, uh, mining coal reduced, the overall usage of coal increased, not decreased, along several industries.

The same happened when the ATM machines were introduced all over the US. People expected a loss of jobs for bank tellers. But what happened was the opposite. Because ATMs were so easy to install, the number of bank branches actually drastically increased, leading to an increase in the number of bank tellers employed.

This is also what I expect will happen as the costs for language models keep dropping drastically, and that's why, for the foreseeable future at least, we do need to account for cost when it comes to agent evaluations.

So how do we do all of this, um, in an automated way? Well, with the Holistic Agent Leaderboard, or HAL, uh, we've come up with a way to automatically run agent evaluations on these 11 different benchmarks already, and very-- many more are on the way.

Um, beyond that though, even if we come up with these multidimensional, um, benchmarks, even if we do come up with cost-controlled evaluations, there are still certain issues with this type of evaluation.

And that's because agent benchmarks have sort of become the metric against which VCs fund companies. An example is Cosine, which raised its seed round of funding based on its results on SWE-bench.

In fact, agent developer, um, Cognition raised $175 million at a valuation of $2 billion, driven primarily by the fact that the agent did very well on SWE-bench.

Unfortunately, benchmark performance very rarely translates into the real world. So this is an excellent analysis of how well Devin works. Devin is the agent developed by Cognition, um, from the very impressive folks at Answer.AI.

Um, instead of relying on standard benchmarks, they actually tried to incorporate Devin into the real world, and what they found was that over a month of use, they tried it for 20 different tasks, and it was only successful at three of them.

So this is the other reason why this over-reliance on static benchmarks can be really misleading. How do we get over this? One of my favorite frameworks to think through this is the work by folks at Berkeley called Who Validates the Validators?

On the top is the typical evaluation pipeline, which consists of singular LLM calls against static metrics, which is the, um, sort of broken paradigm for AI evaluations that we just discussed, and at the bottom is what they propose.

They propose having humans in the loop, who are domain experts, who proactively edit the criteria based on which these LLM evaluations are constructed, and that can lead to much better evaluation results overall.

This brings me to the last key takeaway for why agent performance does not really translate into the real world, which is the confusion between what capability is and what reliability is.

So very roughly speaking, capability means what a model could do at certain points of time. For those of you who are technically minded, this means the pass@k accuracy of a model for a very high k.

That means that one of the k answers that the model outputs are correct. On the other hand, reliability means consistently getting the answer right a- each and every single time.

When agents are deployed for consequential decisions in the real world, what you really need to focus on is reliability rather than capability. That's because language models are already capable of very many things.

But if you trick yourself into believing this means a reliable experience for the end user, that's when products in the real world go wrong. So in particular, I think the methods for training models that get us to the 90% of it, what in strict system would be the job of a machine learning engineer, don't necessarily get us

to the 99.999%, what is often known as the five nines of reliability. And closing this gap between the 90% and the 99.999% is the job of an AI engineer.

And I think this is what has led to the failures of products like Humane's Pin and Rabbit R1. It's because the developers did not anticipate that not having reliability in products like these would lead to a product failure.

In other words, if your personal assistant only offers your—orders your DoorDash food correctly 80% of the times, that is a catastrophic failure from the point of view of a product.

Now, one thing people have proposed to fix this sort of issue to improve reliability is to create a verifier, something like a unit test. Um, and on this basis, there have been several claims that if we could improve the inference scaling capabilities of these tools and get to very reliable models.

Unfortunately, what we found is that verifiers can also be imperfect in practice. For instance, two of the leading coding benchmarks, HumanEval and MBPP, both have false positives in their unit tests.

That is, um, a model could output incorrect code and still pass the unit test. And once we account for these false positives, what we have are these inference scaling curves bending downwards.

So rather than model performance continuing to improve, if there are false positives in your verifiers, the model performance sort of bends downwards simply because the more you try, the more likely it is you'll get a wrong answer.

And so this is also not a perfect solution to the problem of reliability. So what is the solution? I think the challenge for AI engineers is to figure out what sorts of software optimizations and abstractions are needed for working with inherently stochastic components like LLMs.

In other words, it's a system design problem rather than just a modeling problem, where you need to work w- around the constraints of an inherently stochastic system. And I want to argue in the last one minute of my talk that this means looking at AI engineering as more of a reliability engineering field than a software or a

machine learning engineering field. And this also brings me to the clear mindset shift that is needed, um, to become successful for, f- from the perspective of being an AI engineer.

If you look at the title slide of my talk, um, this title slide sort of pointed to one such area where we've already overcome certain, um, types of limitations of stochastic systems, and that is with the birth of computing.

The 1946 ENIAC computer used over 17,000 vacuum tubes, many of which at the beginning of this process used to fail so often that the computer was unavailable half the time.

And the engineers who built this product knew that this is a failure from the point of view of the end users. So their primary job in the first two years of this computer was to fix the reliability issues, to reduce it to a point where it becomes well enough, it works well enough to, uh, become usable by

the end user. And I say that this is precisely what AI engineers need to be thinking about as their real job. It is not to create excellent products, though that is important, but rather to fix the reliability issues that plague every single agent that uses inherently stochastic models, um, as its basis.

So this is what I leave you here with today. Um, to become successful engineers, you need a reliability shift in your mindset, to think of yourselves as the people who are ensuring that this next wave of computing is as reliable for end users as possible.

And there's a lot of precedent for this type of thing happening in the past. All right. With this, I'll leave you with the three key takeaways. It was a pleasure being here.

Thank you. [audience applauding] [upbeat music]