AI Engineer World's Fair 2026
Designing Agents (The Floor Is the Frontier)
About this talk
Raindrop CTO and co-founder Ben Hylak argues that production AI agents need a higher reliability floor more than impressive peak capability. He contrasts brittle tool-specific evaluations with production issue detection, fix verification, simulation, local code-aware testing, and Raindrop Workshop's open-source tracing and self-healing workflows. The talk also examines user oversight, harmful autonomous actions, temporal clustering, and MCP-related code mode.
Chapters
- 0:00Raising the floor and questioning continual-learning assumptions
- 3:07Why tool-specific agent evaluations become brittle
- 5:22Raindrop, Workshop, tracing, and production issue detection
- 8:04Evaluation terminology, human oversight, and worst-case agent behavior
- 12:31Local evaluation testing and customer scale
- 17:01Temporal clustering, MCP code mode, and closing remarks
Talk transcript
- 0:00
[on-hold jingle] Uh, thank you all for coming, first of all.
- 0:15
And, um, I wanna talk today about, uh, raising the floor. So it's this kind of a term we use a lot. Um, mainly I want to talk about very, very practical, like what do I actually see?
- 0:30
What do we actually see working in the real world? Um, how do people-- how are people making their agents better? So the first thing I wanna say is like, um, I could just, I could just say a bunch of stuff.
- 0:39
Like, I think, you know, um, the title of this track is like continual learning. I think it's like notable that in the real world there's really not that much continual learning, right?
- 0:49
Uh, if you look at like the labs, if you look at like products that are in the real world, you really don't see a lot of continual learning. So, um, I think it's very easy to-- Like, I could, you know, spend twenty minutes just talking about like, "Hey, here's a bunch of frameworks, here's a bunch of like
- 1:03
really nice terms." But what I would rather do is actually turn this a little bit into a dialogue. Um, this is not just because I procrastinated making a bunch of slides and because Fable was delayed and I was counting on that to make the slides, but also because like the reality is that, um, there aren't really good
- 1:18
standards for these things, right? Like, there, there's not some one-size-fits-all, uh, solution. And so I'm gonna-- I do have slides, believe it or not, but what we're also going to do is sort of like I'd like to hear from you guys, people actually building agents.
- 1:31
Like, where, where have the, you know, Twitter, you know, eval discourse, where has that failed you, right? Where, where is it not working? What are the things you're actually hitting in real life?
- 1:40
I'd like to talk about that. So please, like right now, start thinking about your questions, start thinking about the annoying parts of your flow, um, when you're building agents, and I'd like to keep a lot of time for Q&A.
- 1:52
Um, so the reality is like a year ago, agents barely existed. Like, I remember being at like a speaker dinner here like a year ago, and we're like, "Yeah, do you think like agents will like, you know, what, you know...
- 2:04
Will they like keep getting better? Will they not?" Um, and I think the crazy thing is like, you know, we're at-- we were at this point in time a year ago where everything was like a chatbot mostly, right?
- 2:14
Um, I think people here, people in this room probably, you know, were a little further ahead. Um,
- 2:20
it was, it was a lot simpler then. Uh, if you remember evals, the eval discourse for like a year or two ago, it would be like, "Oh, what is the, you know, capital of the United States?"
- 2:30
And you're like, "Yeah, and you wanna make sure that it returns Washington, D.C." And, um, that was an easier time, right? It was like
- 2:38
chatbots were so much more limited in their sort of flexibility that it was kind of easy to like, uh, to do a bunch of like, you know, fact-checking things.
- 2:48
Like you knew the answer to most questions your users would ask almost is a, is another way of saying that. At least like a, like eighty percent of them or ninety percent of them.
- 2:57
Um, but yeah, we have agents being deployed in finance, healthcare, defense. And, um, I was actually really against the word. One of my like worst takes is like, uh, early agents.
- 3:07
I was like, "Ugh, I hate the word agent." Um, I think there were a lot of people that felt the same. It was like, "Come on, it's an LLM.
- 3:12
It's a whatever." But I, I actually think it's, it's valuable because I think we're seeing that agents are this like almost self-aware entity, right? They kind of like run around their environment.
- 3:21
They have these tools they're using. Um, when they hit, you know, roadblocks, they start getting really creative, right? And that's what makes agents really powerful. But like that's also what makes them like catastrophic.
- 3:31
It's like, "Oh, well, I'll just, you know, I'll just like, uh, uh, decompile this and I'll just, you know, like do this thing that you had no idea that, uh, you could've never imagined."
- 3:40
Um, sometimes those solutions are, are helpful, right? Sometimes they're, they're actually pretty harmful. Um, but yeah. What's very certain is we've come a very long way from like next token prediction.
- 3:49
Like if you think about chatbots, it was literally just like, oh, it was like, you know, it's gonna-- what is the next likely word? It was very easy to reason about.
- 3:57
Um, and I think the thing that, you know, on the evaluation front, I think the reality is like most of the things you'd read, uh, online about evals, um, are really still like stuck in this chatbot era.
- 4:09
It's very like, well, like come up with your like one thousand, you know, eval data set. And it's like the reality is like nobody's doing that. Um, very few people anyway.
- 4:17
Sorry if you are. Um, and uh, you know, I think what teams have seen over and over again is like, yeah, you can do that, uh, but those evals like break as soon as you have a new model, as soon as you like switch harnesses.
- 4:29
Like you have a bunch of like tools that you're like, oh yeah, I'm gonna make sure that I'm gonna write an eval where it has to like call this tool if I ask it this question.
- 4:35
And it's like, oh, then you switch to like Claude Code CLI, and now eighty percent of your evals suck. And it's like, okay, you could keep doing that, but the reality is like the one thing I could promise you is that things are gonna keep changing.
- 4:45
Like we're not done. And so I'd be very careful about, you know, uh, investing, you know, months in some sort of eval set that's gonna, you know, slow you down, right?
- 4:54
I think the whole thing here is like you want more safety, but you, you don't want theater. And I think that, again, I think the evals as has been sort of, uh, prescribed by, uh, what I call like big eval, um, I, I think that there's this reality where it's kind of like, oh, you sh- really should
- 5:10
eval, but then like do you actually delay, you know, uh, including a new, you know, upgrading to the new model in your product, in your products? Do you actually delay it two weeks to update your evals or not, right?
- 5:22
I, I think most people would say no. Um, so, uh, I'm the CTO and co-founder of this company called Raindrop. Um, very quickly is like we find critical issues in production agents.
- 5:34
We verify those fixes actually work without unexpected side effects, and we also simulate changes before they land in production, um, based on past behavior. Uh, we're used by the best AI companies in the world and Fortune one hundreds.
- 5:46
A lot of logos I'm not allowed to put on here yet. Uh, but companies like Vercel, Speak, Framer. Um, and uh, I think what it means is we get this like amazing peek into like, again, what is actually working in the real world.
- 6:00
I think one of our like tenets as a company is that things are changing constantly, and we have to change what we're doing constantly. And so I think, uh, if- We, we try to be very, very honest with our-- both ourselves and our customers, like what works and what does not work.
- 6:14
We try not to sell things that don't work. Um, just again, two, two things. We have this like, uh, open source tool that like thousands of people use, maybe you use it yourself.
- 6:22
It's called Workshop. Um, so that's made by us. It's like an open source tracing tool. It's really, really cool. If you're trying to experiment with like self-healing loops, I think it's the best way to do that because if there's anything it can't do, uh, your agent can just like add it, which is pretty cool.
- 6:36
Um, and so highly, highly recommend it. Like again, I know thousands of people use it. Like people-- anyway, I bump into people all the time that use it. Raindrop is like our kind of hosted offering that does issue detection.
- 6:46
Think of it like Sentry, but detects issues for agents. Sorry. Um, and we also make howtoeval.com. And so I think it's one of the most popular resources on how to evaluate AI agents.
- 6:57
It is-- again, the link is literally in the name, it's howtoeval.com. Um, and I-it's, it's, uh, uh, our attempt at a very, very no bullshit guide at, at what actually works, and I'll be talking a little bit about it today.
- 7:10
Um, I think the like root question that we're trying to figure out today together is how do you make your, your agent better, right? It's not even like what issues does your agent have.
- 7:21
Uh, it is actually how to make your agent better because your agent will have issues that potentially you can't solve or not exactly worth solving, right? Like, um, I think that we saw this, uh, over and over again where it's like, um, you know, you can imagine that, um, th-there are some things that you're like better off
- 7:38
waiting for. Like, you know, we know Fable exists now, maybe Fable, you know-- Like should you train your own like Fable level model? It's like probably not, right? Um, and there'll be benefits, uh, when you can just incorporate that into your product.
- 7:48
Um, and so there's this actual balance, like how do, how do I actually make my agent better, uh, with the tools that I have? When-- The, the way that we start thinking about it with customers is something like this, which is like, are you a benchmark maxer or a floor raiser?
- 8:04
Um, I think that one of the problems when we talk about evaluating agents is that the terms are really confused. Like you hear OpenAI has a new like, you know, uh, eval benchmark and, um, you know, they have evals, they run evals, and then you hear like, oh, well, companies have evals.
- 8:21
There's like online evals and like-- It, it like-- The word eval is like, uh, more or less a meaningless word. It literally is just like you're evaluating something, right?
- 8:30
It's like a test in some cases. It's a-- So it's a little confusing. Um,
- 8:34
I think it's helpful-- Like I think what it means is that like, uh, companies start borrowing like the language that like labs are using and like even copying similar benchmarks, but they're doing completely different things, right?
- 8:46
Like they have completely different tools at their disposal. Like what companies are-- You know, like the companies that are downstream of models, uh, they just have very, very different responsibilities than labs.
- 8:57
Um, like labs are trying to make these super general purpose things. When they fail, at least on like a API level, when I, when I say if they get something wrong, it's like, it, it's just different.
- 9:06
Um, companies are trying to like imbue all this like company specific, uh, domain knowledge. Like, oh, here's the shape of the data, and here's what all this data means, and here's like how to access it.
- 9:18
Um, and so it's very, very different. Um,
- 9:23
we have this like funny quiz on, on the how to eval site and, um, it's interesting, right? Like it's kind of like one, one of the questions we, we would think about is like, oh, are your engineers like...
- 9:33
Or sorry, are your users like domain experts in the thing they're doing? Is-- A-a-again, is it almost like replacing someone or is it augmenting them? Because if you think about like Copilot, you know, autocomplete style or Cursor, you know, tab complete now, uh, if it gets something wrong, like you can just delete it, right?
- 9:49
Even like Claude Code, CLI or like Codex, if you're an engineer, it's like it does do things wrong all the time. Um, but then when you think about products like Devin, it's actually gets more interesting, right?
- 9:59
Like De-- I-if, if something messes up on, on the Claude Code side, it could be that like you don't have something installed correctly on your computer. There's a lot more like user error.
- 10:08
There's a lot-- You leave a lot more up to the, the users to get correctly. Um, and I think when you start thinking about things like AI doctors, for example, it's like, uh, it's a very, very different shape of responsibility as far as like how much responsibility the user has in actually getting things correctly.
- 10:23
Um, so anyways, it's kind of funny. Um,
- 10:26
just kind of breaking this down. So we think about the ceiling as like, what is the best thing, like craziest capability, emerging capability that your, your product or agent is capable of?
- 10:35
Like things that people would just not expect that it could do. And then the floor is like, what is the worst thing your agent can do? Like recommend a competitor or like delete a bunch of data or like accidentally send a, you know, AI slop email to a customer because it like technically had access to like your
- 10:49
email or something. Um, and again, I think that like the floor is very interesting because I think that that is the thing that like breaks user trust. This is the thing that like the reason why people, uh, like if you think about the worst things that could start happening in society, whether that's-- A-and, and things we've already
- 11:10
seen, um, whether that's the, uh, you know, like 40 kind of sycophancy, um, or, uh, things in that vein. A lot of it is more on like the floor side rather than the capability side.
- 11:21
Um, and anyway, so I could talk about that for a long time. Um, I'll kind of skip this.
- 11:28
So the talk obviously is gonna be about floor raising. And, um, the first thing that we're gonna talk about is like offline evals. Again, we'll keep it very simple.
- 11:38
Um, I think that like we said before, things have changed a lot sort of since this chatbot era. The sort of like, oh, you just, uh, you know, like look at, you know, string contains, you know, on the, uh, uh, on like the text output or something.
- 11:52
Or even like the style of eval tools that have like a prompt playground, like this sort of thing. Like, I actually don't know many companies that use some sort of like managed prompt like in the cloud anymore.
- 12:03
There's like one or two I can think of. Um, and the reality is just like the prompt is actually like the whole thing now. It's like all the code.
- 12:11
It's, it's your whole harness. It's like everything you're connect-- Like it's not just like some string where you tell your, the agent what to do. Um, and so what I think that means is the evals themselves actually should look a lot more like code.
- 12:23
In other words, like a lot more like tests, whether that's unit tests, whether that's end-to-end tests. Um, they should look a lot more like tests. Um-
- 12:31
Uh, Sentry has this, uh, a really cool package called, like, Vitest Evals. It's literally just, like, Vitest with, like, some syntactic sugar on top. Um, OpenAI calls this, like, macro evals and, um, again, I don't think it really matters what you call it, but, like, essentially run tests on your agent, uh, locally, uh, is, is, is the
- 12:51
advice. And keep these evals as code. Um, and again, as much as possible, like, the-- I, I don't see a lot of companies using the sort of, like, prompt playground stuff anymore because of how the shape of agents has really changed.
- 13:08
Uh, w- when we think about raising the floor, we think about really, like, three things. One is that, like, discovering all these, like, unknown issues that you have in your app, like things you're just, like, not seeing.
- 13:19
That's one. Two is that for each issue, you really need to know two things. You need to know when it actually started, and you need to know how many people it affects.
- 13:27
It sounds, like, obvious, but I promise you that, like, in the day-to-day of actually, like, having an agent, uh, you're gonna get, like, you know, you already get thousands of people like, "Oh, I saw this weird thing, I saw this weird thing."
- 13:37
So again, the first thing is, like, is this new? 'Cause if it's not new, like, I probably, like, am going to care about it less. If I-- If, if, if I tell you, like, "Hey, look, this issue started yesterday," or, "This issue started, like, three or four days ago," suddenly, like, your mind starts turning and you're like,
- 13:50
"Oh, what did I do?" Like, well, what, what, what changed, right? Did we change the model? Did we change, you know, so-something else, um, downstream? And again, the second one is, like, percent of users.
- 13:59
Like, if I'm, uh, knowing that it happened to three users versus a hundred thousand users just is, uh, critical. Because again, I think agents will have an infinite number of problems.
- 14:09
That's sort of, like, the, the great and terrible thing about them, is like, by-- they're like these little stochastic, you know, crazy things exploring everywhere. And so you just, uh, in order to even start making things better, you, you really need to, need to know these two things, when it started and percent of users.
- 14:24
Um, and I think also, and ag- another question we get a lot is, like, around, like, oh, like, I, you know, what should I be doing? And, like, the first question I always ask people is, like, how many users do you have?
- 14:37
Like, we have customers with millions of users, and we have customers with, like, five. And the real-- and, like, to be clear, like,
- 14:45
uh, th- customers with five users, like, e- especially for-- let's say it's, like, an internal, um, app in an enterprise context where it's like, you know, uh, giving, like, very critical information, like, it could be very, very important to get well, uh, or sorry, to get correctly.
- 14:57
But, um, it does mean you just, like, should be taking a radically different, uh, approach. Like, so for example, on the, like, you know, uh, let's say, like, ten, twenty, a hundred million, you know, messages a day side of things, like, experiments become extremely valuable.
- 15:12
Uh, if you have a free tier, you can, like, uh, uh, run experiments on a very small sample of your free tier, um, and that can just be extremely, extremely useful.
- 15:20
Um, obviously, if you have five or ten users, like, uh, I would not recommend, you know, experiments or A/B tests, et cetera. Um, so, uh, this is one of those things that, like, uh, uh, really, really depends on the person.
- 15:31
Um, what I wanna talk about now before we get into Q&A are, like, three very, very, very, very tactical lessons on the sort of, like, issue, uh, discovery and analysis side.
- 15:44
These are, like, three things that I, I've never heard anyone talk about, like, three things that we've sort of just discovered from first principles as we do stuff at Raindrop.
- 15:54
So any competitors in the audience, please pay attention. This is very important. Um, the first one is that clusters are not issues.
- 16:04
So, um, the sort of, like, naive approach that we've seen either customers or also sometimes competitors, uh, take is like, well, like, you just take all the traces and you just cluster it, right?
- 16:15
And you get these, like, clusters. It could be, like, useful from, like, an analysis, uh, you know, like, Hamel calls this, like, error analysis. Like, the, the, the, this, you know, finding these clusters of things.
- 16:25
It could be useful to see, like, whoa, what's going on in your data, right? Going from, like, a bunch of logs to, like, something. Um,
- 16:33
the problem is that, like, and a- and again, I, I have here, it's useful for one-off analysis, but it just doesn't really scale well. Um, and there's, like, a very good reason why we also, you know, if you think about, like, normal telemetry, we, we, we try to think a lot about, like, normal telemetry.
- 16:46
What are the analogies? There's a reason why you don't sort of, like, take all of your, you know, normal logs and just, like, start clustering it, right? Because when you're building software, you, you need to know, like, when something started, um, you need to know how much it's grown.
- 17:01
Um, those things really matter. So again, with clusters, it's very, very hard to reliably, uh, track over time. Um, like, if, uh, like, again, this is called, like, temporal clustering, and there's, like, research in this, but, like, it's pretty hard, um, to do reliably.
- 17:17
You also just, like, don't have control of boundaries, um, and this also changes a lot depending on your product. Like, um, what you consider to be, like, you know, the same issue or not, um, is actually very, very unique to every company.
- 17:34
And so you sort of will get these, like, kind of weird clusters. Like, you know, you can imagine each of these as, like, oh, wrong price quoted and wrong, wrong refund calculated are, like, actually, like, you'll get a cluster like, you know, uh, uh, you know, price issues or something.
- 17:51
And it's like, yeah, sort of, but, like, actually these could have, like, extremely different root causes, right? So, so price issues is, or, like, you know, uh, issues calculating is, like, you know, as a cluster, it's not really that useful.
- 18:04
Um, and it also, again, doesn't, doesn't really tell you the things that, you know, we talked about needing. Um,
- 18:11
so, uh, yes, uh, last one here is gonna be, uh, code mode actually really scales. Like, you've heard about code mode in the context of MCPs. Um,
- 18:22
I highly recommend just trying to apply this to traces. Like, you can just write, uh, these classifiers, and you can write them, and you can run them in a sandbox, and you can run them at production scale.
- 18:31
Um, we have a, you know, feature that makes this easier, but, like, you can do this, so I highly recommend it.
- 18:38
The last lesson here is that agents are very, very bad at anomaly detection, so don't ask your agent to find anomalies. Uh, ask it to investigate anomalies you've al-already found.
- 18:47
So, uh, what I mean is, like, pull out as many de-deterministic things as you can, like keyword frequency, right? So if you see a spike in, like, a keyword,
- 18:56
it doesn't necessarily mean that there's an issue, but it does mean that you can, uh, it's, like, something more tangible, tractable that you can have an agent actually investigate.
- 19:06
Um, and I'm gonna skip through the rest because we're tight on time, and I lied to you, uh, which is that we're not gonna have enough time for Q&A because I only have a minute left.
- 19:16
But what I'd love if you could do is, uh, find me after. Um, I'll be around for the next hour, and, uh, let's just talk. It's probably a better format than standing up here, and it'll be hard to hear your questions anyway.
- 19:26
So, uh, yeah. Thank you guys so much. [outro music]