Mousepower: agents that can’t be measured, can’t be managed. — Maximillian Piras, Yutori
Token counts do not show whether an agent was worth running. Define outcomes and cheap acceptance checks first, then reserve agents for work that is uncertain to execute but relatively easy to verify.
The talk proposes “mousepower” as a mental model, not a literal metric: agent spend should connect tokens to outcomes such as bugs fixed or support requests closed, then to project objectives. Raw usage measures cost but not value.
Choose agent tasks using two questions: how uncertain is execution, and how uncertain is verification? Script low-uncertainty work, avoid tasks where checking requires repeating the work, and favor the **easier to verify than execute** middle ground.
The talk proposes “mousepower” as a mental model, not a literal metric: agent spend should connect tokens to outcomes such as bugs fixed or support requests closed, then to project objectives. Raw usage measures cost but not value. Choose agent tasks using two questions: how uncertain is execution, and how uncertain is verification? Script low-uncertainty work, avoid tasks where checking requires repeating the work, and favor the **easier to verify than execute** middle ground. No universal ROI formula or production framework is supplied. The proposed **two-axis rubric** is a thought starter, and every team still needs domain-specific acceptance criteria that customers understand and trust.
“Mousepower” shifts agent evaluation from usage and output volume toward accepted outcomes tied to project value. Its two-axis rubric also narrows good automation targets to work that is uncertain enough to need an agent but materially easier to verify than execute. This complements architecture-aware and trace-based evals with a task-selection lens, while leaving each team to define trustworthy domain-specific acceptance criteria and ROI.