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

Maximillian Piras, founding designer at Yutori, starts with a familiar agent workflow: keep human attention on the main task while several agents pursue peripheral work in the background. For this talk, the concrete job is improving the slides. A design system and written guidance constrain the work; multiple agents then explore typography and layout in parallel. The observable result is more design variants produced without taking over his active attention. 0:42

Parallelism feels like free leverage because research and design exploration rarely have an obvious stopping point. But each additional run consumes tokens, and the bill eventually forces a question the workflow postponed: which explorations were useful enough to justify their cost? A pile of generated variants is visible output. It is not yet evidence of value. 1:42

That question is especially relevant to Yutori’s computer-use models. These models operate software as a person would when an API or MCP connection is unavailable. They can reach information trapped behind ordinary interfaces, but clicking through a rendered application is less efficient than calling a structured API. Computer use is therefore a fallback for the long tail of inaccessible systems, not the preferred interface when a direct integration exists. 2:42

Customer conversations repeatedly return to the same unresolved decisions: which jobs suit an agent, what tradeoff to make between token cost and value, and how to tell whether the result is good. Excitement is widespread, but so is the feeling of merely “scratching the surface.” The missing muscle is measurement. 3:42

Experienced agent users can object that they already know how to run a fleet. Piras accepts that experience while questioning whether it generalizes. Early adopters enjoy experimenting, tolerate rough interfaces, and may willingly spend tokens to discover what works. People who have never used an agent—and may still work through copy-and-paste interactions—do not share that calibration. A product cannot explain its value to the wider market by pointing to the habits of its most enthusiastic users. 4:13

The historical analogy is James Watt selling steam engines to people who understood power through horses. A horse gin connected an animal to a rotary arm; walking in a circle supplied mechanical power to a mill. Replacing that familiar arrangement with an intimidating machine required more than claiming that steam was better. Buyers needed a comparison expressed in terms they already understood. 5:43

Watt studied horse gins and developed horsepower as a baseline for expressing relative performance. In Piras’s telling, the early figure was neither especially scientific nor necessarily accurate. Its commercial utility came from legibility: a buyer could translate machine output into a familiar unit and estimate the gain from trying the new technology. The measure reduced the cognitive distance between the old system and the new one. 7:12

The comparison also had to overcome attachment to the incumbent technology—horses, as Piras puts it, had “great vibes.” Efficiency alone does not create adoption when the new system feels unfamiliar or threatening. A comprehensible return on investment gives someone a reason to cross the threshold from curiosity to use. 8:12

The agent industry has not found an equivalent translation layer. Organizations can exhaust an annual token budget in a quarter or turn consumption into a leaderboard, but neither behavior establishes that the spending improved the business. When incentives reward usage rather than useful work, teams can become very good at consuming the resource they meant to evaluate. 9:12

Borrowing a term from Ramp, Piras describes the resulting pattern as “overspending and underusing”: teams maximize agent activity, hit austerity, retreat from the tools, and return when fear of missing out becomes strong enough. What does this cycle make visible? Enthusiasm without outcome measurement does not produce sustained adoption; it produces alternating bursts of consumption and withdrawal. 9:42

The diagram shows the missing link. Spending produces activity, but without an outcome measure the team cannot distinguish productive use from waste. Budget pressure therefore causes a broad retreat instead of a targeted adjustment to models, tasks, or workflows.

Choosing cheaper models by default and reserving frontier models for difficult work can separate token volume from total spend. That is useful cost control, but it still treats tokens as the central unit. Tokens are an internal output of the system. The business cares about what changed afterward. 10:12

The practical accounting chain should run from spend to a concrete outcome and then to an objective. For software work, ask how many bugs were closed with the purchased tokens. For support, ask how many requests were resolved. Return to the slide example: ten agents may create ten alternatives, but value appears only when review identifies a better treatment and that treatment improves the finished deck. Counting variants or tokens stops before the consequential step. 10:42

Coding agents expose the deeper problem. They can generate changes quickly enough to leave teams “dying by a thousand pull requests,” while code review still consumes human attention. More generated code does not automatically create more accepted, deployed, useful software. When generation accelerates but review does not, the bottleneck moves downstream. 11:42

This creates a measurement problem as well as a workflow problem. A team can observe code volume immediately, but it cannot judge quality at the same speed. Until someone reviews the change and decides whether it is good enough to use, token spend has produced a proposal rather than established value. The original bottleneck may have been implementation; the new one is verification. 12:12

Code review nevertheless offers a useful clue because software teams have converged on shared assumptions about what acceptable work looks like. That convergence creates a rubric, even if its assumptions need revision for agent-generated code. Once people agree on what should be checked, parts of the judgment can happen consistently and at greater scale. 13:12

The product requirement follows: building an agent also means helping its user verify the output and connect accepted work to return on investment. Execution at the speed of compute is only half the system. Useful deployment needs measurement that can approach the same speed without pretending that generation itself proves success. 13:49

Mousepower is Piras’s proposed analogy for the agent era: establish a baseline for how people use computers, then express where an agent performs better on the task. The tempting implementation is literal—measure cursor distance or speed and compare human movement with agent movement. Piras even had a prototype measurement device generated for the joke. 14:19

The literal metric fails because computer work takes place in a high-dimensional information space. Faster pointer movement says little about whether the correct source was selected, the right judgment was applied, or the resulting action advanced the user’s goal. Two agents can traverse the same interface at similar speed and produce outcomes of radically different value. 15:19

Mousepower therefore names a product obligation rather than a standardized unit. If a product sells agent execution, it should also supply a rubric for determining whether that execution was good and whether its token cost was justified. Piras does not offer a universal formula for that rubric; it must fit the customer’s task and mental model. 15:49

To narrow the search for suitable tasks, Piras borrows the idea of entropy as uncertainty. The proposed matrix has two dimensions: uncertainty in the steps required to complete a task, and uncertainty in the criteria used to accept the result. This is explicitly a thought starter still in development, not a validated task-selection model or a quantified use of information-theoretic entropy. 16:19

The first axis asks how predictable the route is. Booking a flight has required information and recognizable stages: departure, destination, and a seat selection of some kind. Painting a masterpiece has no comparable sequence that reliably yields success. The contrast concerns path structure, not whether either task can sometimes be completed by a model. 16:49

The second axis asks whether success has a clean grading rubric. An agent might be able to perform an open-ended task, yet still be a poor product if a person must redo the work to determine whether it was valuable. Verification cost belongs in the task-selection decision from the beginning. 17:49

What does the matrix help a builder decide? It places uncertainty in execution on the horizontal axis and uncertainty in acceptance on the vertical axis. Reading across distinguishes deterministic scripts from useful agent work and poorly modeled tasks. Reading upward shows how rising verification uncertainty makes delegation less economical. The promising region is moderate step uncertainty paired with relatively clear acceptance criteria.

The regions imply four practical decisions:

• Predictable steps — write a script. Deterministic automation avoids spending tokens on a path already known in advance.
• Extremely uncertain steps — reconsider the task. The work may fall outside useful training distribution and provide sparse reward signals.
• Unclear acceptance — avoid false delegation. If a person must effectively repeat the task to judge it, little work has been saved.
• Moderately uncertain steps with clear acceptance — consider an agent. The task needs judgment, but its result remains economical to check.

Piras informally compares the final region to an NP-style problem: solving is harder than checking. The important engineering property is the asymmetry, not a formal complexity classification. When acceptance follows a repeatable pattern, another agent can perform part of the verification. The resulting system contains an execution agent and a checking agent, both working against criteria the customer understands. That is how an agent begins to acquire its mousepower. 19:49