Mousepower: agents that can’t be measured, can’t be managed. — Maximillian Piras, Yutori

0:01 [music] Um, well, thanks a lot for your time. Really appreciate you dropping by and it's always a great honor to speak at the World's Fair. So, I'll do my best to

0:21 uh give you guys some valuable insights and um yeah, hopefully make it worth your time. So my name is Maximillian Piros and today I'll be talking about mouse power and this is a talk about

0:32 measuring agents through mental models. But before I get into talking about measuring agents, I'm going to talk through a bit about how I use them every day. And it might seem familiar to you,

0:43 but just to level set, we'll go through it. So I tend to background them like I'm sure a lot of you people are as well. Um, so while my active attention is focusing on one thing, like perhaps

0:53 giving this talk to you, I still want to make some progress on peripheral tasks. So I'll keep my attention focused on giving this talk while my agents can help me explore some designs in the

1:04 background because I think that uh my slides need a bit of work. So you know, I've got my design system already set up. I've got some guidance uh given to my agents. So I'll kick off an agent to

1:14 just try to explore some different directions on the type treatment and the layout and um you know just try to get as many explorations as possible. But of course uh one agent's never enough. So I

1:25 like to kick off a bunch in parallel. You know I've got a lot of slides to get through. So I need all my agents on and exploring it in different directions. And uh hopefully I can get some

1:35 interesting things to make my slides a bit better. and uh hopefully they can finish the job pretty soon because we're obviously kind of up against uh timeline the the uh deadline here. So um this is

1:48 generally how I work. I'm sure it's probably familiar to a lot of you where we're just trying to kick off agents for as much as possible in parallel because it always feels like there's just way

1:56 more research to do. We want to be as thorough as possible. There's way more design explorations to do. So whenever our main focus is on one thing, why not kick a bunch of agents off in parallel

2:07 and just try to maximize your time and it's a lot of fun of course until you get the bill and then you start to wonder was it all worth it, right? Did did you vibe code too hard? Were you

2:20 token maxing too much? Like could you have been more efficient in how you approached uh your sequencing your agents? And so this is what I'm going to get into today. It's it's how do we

2:31 value uh the token cost and specifically how do we help our customers value it. So for the past year and a half I've had the pleasure of working as the founding designer at a company called UTRI and we

2:42 focus on computer use models. These are models that learn to use a computer like a human would. And the use case for them is when you can't get information from an API or an MCP, why not just send an

2:54 agent out to use a computer like a human would? And then we can extract all types of data and manipulate it in ways that uh let us access all the stuff that wasn't uh accessible previously. So

3:04 obviously less efficient than APIs and MCPs, but as a last resort, just have an agent go use the computer and try to get the information. Uh here's the uttory agent using the utori website. Um it's

3:16 checking out its own benchmark. So kind of it's admiring itself in a way. So um yeah, it gets it gets a bit weird. Uh like and a lot of what I do as a founding designer there is talk to

3:26 customers, try to understand how can we make agents as intuitive as possible. How do we figure out the mental models they're using to value uh the use cases they want to send out agents for? And um

3:37 a lot of them do seem pretty confused so far. A lot of people are excited about agents, but the a phrase that comes up quite often is that they feel like they're just scratching the surface. Um,

3:47 it seems like it's not quite intuitive how we can best use them yet. And so in a lot of my uh customer discussions, it's it always comes down to a question of like what is the best way to use you

3:57 uh to use agents? What are the best use cases for them? And how do I think about the trade-offs with regards to token costs relative to value? So, I think we're still kind of building this muscle

4:06 today. And this leads me to the thesis of the talk, which is that I think agents have a measurement problem. And uh, as an example, here's me at work trying to measure some agents, and one

4:17 of my co-workers took this photo and told me I looked like I was trying to solve the mystery of Pepe Silva. So, uh, as you can see, it's it's it's not a it's not an easy task to to measure

4:29 agents. But I'm sure some of you are saying, "Hold on a sec. like what is this guy talking about? I've got a fleet of agents working for me right now. We're building our next million-dollar

4:38 app as we speak and I'm having a totally fine time uh measuring my agents. Uh to which I will agree with you. Uh, but then I will point you to the mandatory Upton Sinclair quote to remind us all

4:49 that everybody in this room is very biased and we're early adopters and we're very excited to explore this new technology, but it doesn't mean that we represent the people that ultimately

4:59 we're going to be trying to help adopt this technology. And so, you know, I think it's important to remind ourselves that in some way or another, we probably are selling tokens, whether it's

5:09 indirectly or directly. And so when we think about our own token usage, uh is it really representative of all the people out there who have never touched an agent yet? Uh some people are still

5:18 copy and pasting into chatbt. I may be married to one of these people and despite how much I tried to get her to try out agents, she's not let me set her up with it yet. And so, um, as a

5:29 reminder, uh, when we think about helping people adopt agents, you know, all the people across the world that we think could get as much excitement and value as as we do when we run off

5:38 parallel agents, let's just remember this quote. [snorts] And um, so it really boils down to the age-old problem of a new technology. And of course, there's tons of history we

5:49 can go to to study how people solve this in the past. We have this really exciting new thing, but we haven't quite figured out the right ways to communicate it. And so for this talk,

5:58 I'll go back to the 1700s and we can take some notes from when James Watt was trying to sell steam engines. And at the time he decided that a great use case for his steam engines was trying to

6:11 replace a horse gin. And these are the was the power source of a mill at the time. So when you're for uh let's say a brewery and you need some power source to to grind your barley or whatever, I

6:22 don't know. I'm not like a big brewery guy, so I don't know exactly how it's made, but you need a power source. And the power source at the time that was common was you hooked a horse up to a

6:30 rotary arm and the horse walked in a circle and that's how you generated your power. Uh, and seems crazy today maybe, but um at the time was common place. And Watt thought, you know, it would be much

6:40 better than a horse is like a very efficient machine. Although he u rightfully acknowledged that one of the big barriers to adopting it would be this cognitive dissonance of trying to

6:50 tell people who kind of think in horses how do you adapt to this to this uh cold machine that's kind of intimidating and scary and perhaps uh somebody's going to say it's going to solve all your

7:01 problems but you you can't quite see the vision yet. So perhaps that sounds familiar to any of us working in agents today. And Watt's solution was that he needed to understand um the mental model

7:12 of these people and specifically to create a metric that would help him uh give some baseline of the relative improvement in efficiency. And so he literally studied uh horse jins and

7:23 tried to get some kind of armchair measurements of of how is like what are the mechanics and the average um performance of it and eventually came to a metric called horsepower which may

7:36 sound familiar. And uh he used this measure to you know this was to quantify the the general power that the horses were were um creating at the time and then he could use as a basis to show the

7:46 multiplier of efficiency that a steam engine could provide. And uh this metric was uh not very scientific at the time. It was not necessarily even accurate you could say. Uh but the main thing it did

7:57 was it communicated an increase in value. And so this let people who who love horses uh let them kind of calibrate their um the the efficiency gains that they could get by by uh

8:10 attempting to adopt a steam engine. So not even necessarily um what you would get when you use it, but what would get you over the limit of trying it out in the first place.

8:20 And uh you know it's it's it's a pretty big feat because like although um he had efficiency on his side with regards to this metric um you know let's be honest regardless of how efficient this was um

8:32 horses just have great vibes. So, like it's kind of hard to beat the vibes of horses. And so, he knew he had to kind of overcome the emotion uh and actually speak to to something that gave him an

8:43 ability to calculate the ROI. And oh, sorry, skipped something. And so, yeah, the le the lesson being um if we're not able to give something that is a tangible ROI um for our customers,

8:55 then it's very hard for us to comm communicate value. And um I think we only need to look to our own industry to see all the examples where other people in the technology sector are failing to

9:06 calculate good ROIs as well. And so we might in this room think this is somewhat of a solved problem. Uh but if you look to the other engineers in the world who are perhaps not as AI pilled,

9:16 uh they're theoretically very smart and should be able to figure out how to calculate this pretty well. But then you get these scenarios where people are blowing through their entire um token

9:25 budget for a year and they're blowing through it in in a quarter or they're like dealing with token leaderboards and such. And so obviously the incentives haven't quite aligned and we haven't

9:35 perhaps got the right measure of value in terms of the technology sector itself. And so how then do we end up scaling past past that and talk to people who have no idea what we're

9:44 talking about but still try to provide them um a measure of like increased efficiency with agents. And so right now I think we're kind of in this doom loop where we're we're

9:54 overspending and we're underusing. Uh this is a term I borrowed from ramp um and they have a great blog post on this. And so it's kind of this vicious cycle where we're just token maxing and

10:04 ourselves into austerity and then kind of dropping out of the loop until we get more FOMO to to get activated enough to try it again. And so I think we have to break this loop and I think the way we

10:14 do that is by getting better measures of that will communicate value. Some people are obviously on the right track. There was this chart floating around on X recently that the Coinbase

10:24 Coinbase CEO posted where they had internally started changing the defaults of what models they will start with and trying to only save the frontier models for the hardest tasks and as a result

10:35 saw some good um saw AI spend start to diverge from token usage and uh this is a good start. Uh RAM also as I mentioned has a great blog post about this. uh but I think the problem is still that it's

10:46 too focused on tokens and tokens are of course uh useful as a measurement of an internal system but at at the end of the day they're just an output and so the tokens need to then be traced very

10:59 cleanly to an outcome. So, how many uh bug uh how many bugs did the tokens uh how sorry, how many um bugs squashed did the tokens that we bought? Um sorry, totally butchered that. Um how many uh

11:13 bugs got squashed with the to with our token spend? How many uh support requests got closed, etc. So, clean outcomes and then cleanly tying those to to progress on our objectives. And so,

11:24 without a very tight measure of ROI, this becomes very hard to do. And I think I'll take this further and um say that it need not even be the broader um technology industry we're

11:35 that's encountering this problem, but also many of us in this room perhaps are. And uh although we're all probably enjoying uh coding with uh with various agents and feeling like it it's it does

11:47 feel like there's something there in terms of the increase in ability and efficiency. Um the problem of course is that we're all kind of dying by thousand poll requests. And so uh even Enthropic

11:56 who has uh some people on the team have claimed to have solved coding uh they have also admitted that they've not solved code review. And so as a result um the the bottleneck is now shifted to

12:08 human review where the efficiency gains from coding agents aren't quite or aren't seen yet because we spend most of the time reviewing the code and we've not figured out how to scale that in

12:17 tandem with uh the generation of the code itself. And so the bottleneck ends up shifting to the verification side and thus we don't have a way to measure value at scale and uh to judge quality

12:29 at at the same speed. And so again going back to the ROI calculations, we generate all this code but how do we know uh we don't know that enough of it is good to justify the spend.

12:40 And of course maybe uh code review was always flawed. Uh but it's just that agents are now exposing it for uh the or exposing the actual problem. Um, but I like this quote by Noah Hine who from a

12:52 a post about how to solve code review where he's mentioning specifically that the assumptions underneath code review are what's now being what needs to be revisited. So we have to check our

13:01 priors to try to figure out a new basis for um how we can code review in the age of agents. And I'm not going to go into how to solve code review. I think that's definitely better uh a talk that's

13:12 better given by somebody else and um is totally different subject. But what I think is important for this talk is why does code review feel like it is solvable. And I think that Noah is

13:21 hitting on something important here which is that as a as a culture uh code review has a very good uh convergence on shared assumptions and that lets you um that lets you uh measure things at scale

13:33 when we can all kind of converge on the measurement and it becomes somewhat of of a clear rubric. And so the task at hand now is we have to adopt uh we have to sorry adapt those assumptions for the

13:45 agentic age. And so uh we can we need to go um if if we're able to do that then we can go from execution at the speed of compute to measurement at the speed of compute.

13:57 And of course the measurements need to fit the mental models of the customers using it. And um I think the lesson here being that if you're going to um think of how to build an agent for something,

14:09 you also have to think about how do you help the customers build or build or at least create a method for verifying that the output is good. And so it's not enough to build it. We also have to help

14:19 them we al we also have to help them get to clear ROI calculations to justify their spend. And so um this brings me to the idea of mouse power which could be the equivalent of horsepower for the

14:32 agentic age. Just as James Walt was able to show a measure of efficiency relative to the horses in in the gins uh in the horse gins uh that were the source of power at the time. We perhaps can also

14:44 figure out how do we create a baseline of efficiency for the way we use computers today and can then demonstrate how much uh better or perhaps more performant on certain vectors an agent

14:54 could be at that task. Um, and of course it's not uh as easy perhaps as easy a task as he had back then where he could just study the horsegen because it's not as if we can create some method to

15:05 measure our cursor movements and like figure out the delta of how much more efficient an agent could move them and thus we can say yeah agents are this much more performant than humans at

15:14 these tasks. Uh, trust me, I've I've tried I had Claude vibe code me this measurement device and I thought maybe if I can figure out the movement uh like the potential movement across the screen

15:25 and measured how fast it went, I could get some clean measure of mouse power. Uh, but of course this is only joking. Um this is of course um like a fool's errand because information space is just

15:36 way too high dimensional and so I think mouse power is of is never going to be a metric of course but it's more so an idea which the idea being if you're going to sell somebody an agent you also

15:46 have to help them with the with the rubric of how do we actually verify that this agent is doing good work and thus we can uh have a good measure of saying that these tokens are worth it. Um, so

15:57 how to do that of course is is really up to you and I won't be able to tell you how do you I don't have any good frameworks for how do you figure out the right measurements to to help provide

16:06 anybody you're building an agent for. Uh but what I can do is give a princip uh give an idea that I've been kicking around which is based um in information theory. So going back to Claude

16:17 Shannon's ideas about measuring entropy in information uh entropy being the uncertainty of a probability distribution and of course very much the basis of how we train agents today

16:28 things like cross entropy and such uh being a big factor in determining how capable an agent is. Um I think that entropy is an interesting idea to think through with regards to not just the

16:37 performance of an agent but also the task that we're setting them out to to perform on. And so uh I put together this matrix which it maps on the x-ax axis the uncertainty in the steps it

16:50 takes to perform a task. And so when we're thinking of building an agent I think it's not enough to just think what would be a valuable task for the agent to do but also thinking about how um how

17:00 much uncertainty are in the steps to perform that task itself. So an example would be uh booking a flight has much less uncertainty than let's say painting a masterpiece, right? Because you know

17:11 there's certain information that has to be that has to happen in the flight purchase. There has to be a departing destination, arriving destination. There's going to be a seat chosen. It

17:20 might be by the person. It might just be random. Uh but these things have to happen for that task to be completed. And on the other hand, there is the task of like painting a masterpiece, right?

17:29 And who knows what the steps are to that. uh and maybe you can get an agent to do it but it would be very hard to figure out how we can actually create a a reg relatively um predictable pathway

17:39 to that. Uh but then on the other access uh is the the uncertainty in the acceptance criteria itself. So not just can the agent perform the task but can we help somebody actually or is is there

17:51 actually a clean rubric for how it's graded. And so thinking about ideas on on these two axes and where they intersect perhaps gives us a better guide for how to build agents and we can

18:02 run through a few examples. Um so if we look at the at the left side your right side um yes um no your left as well. Um then I know the last speaker was also uh confused by um so uh you know on the

18:18 left side uh when uncertainty in the task steps are low then it's a very it's a very predictable outcome or it's a very predictable pathway to achieve that goal and so then you know why would you

18:29 waste tokens just write a script on the other side when uh the t the steps to do perform the task are very high in in uncertainty then you you have very unpredictable information And so it's

18:41 probably at risk of being out of distribution in pre-training and probably has very sparse rewards for reinforcement learning. And so perhaps it's not a good task for an agent

18:50 because it's just much harder to figure out how to actually model that data. And uh so obviously in the middle is is um is so I think I'm out of time, but I'm not getting kicked off yet. U so I'll

19:03 just finish this up quickly. Um so yeah in the middle is is probably the sweet spot but then on the other axis uh what's the uncertainty in verifying that this actually valuable. So when you have

19:11 high uncertainty in the acceptance criteria you pretty much at a spot where verification is indistinguishable from execution. So why would you build an agent for something that to verify it

19:21 was useful a person pretty much has to do the work again. So like waste of tokens obviously and then it leaves that that middle area where you have this interesting intersection of tasks that

19:32 are um they're not too uncertain in that they or they they have um a degree of uncertainty where they're not great. They're not just a a script or they're not out of distribution for training,

19:45 but they have enough uncertainty to be interesting, but at at the same time, they also have a property of being relatively easy to uh validate the uh to check the value of them. And so they

19:56 become in this place where they kind of become the shape of an MP style problem, which means they're easier to verify than to execute. And the reason I say that is because if you can figure out a

20:05 pretty repeatable p pattern for verifying their their work, you can actually just throw agents at that problem as well. And so of course you don't just build the agent, you perhaps

20:14 build the agent that verifies the work of the agent. Um and so yeah, this is uh perhaps uh this is a thought starter mostly kind of h kind of um still in the works. So happy to hear any thoughts on

20:26 it. But if uh with this guidance, I hope uh when you're building your next agent, you can also figure out how to also build its mouth power. And thanks very much.