The Verification Bottleneck in Agent Work

Executive Summary

The practical constraint on AI agents is increasingly not whether they can generate work, but whether a team can verify it cheaply and confidently enough to act on it. A cluster of talks from AI Engineer converged on that conclusion from different angles: agent economics, design control, and multi-agent coordination. The important shift is away from measuring activity—tokens, tasks launched, screens filled—and toward building explicit acceptance criteria, shared context, and interfaces that make results inspectable.

What Happened

In “Mousepower: agents that can’t be measured, can’t be managed”, Yutori’s Maximillian Piras made the clearest version of the case. Token use is not a useful proxy for value, he argued; spending needs to trace to a verifiable outcome, such as a bug fixed or a support request resolved. That makes task selection central. An agent can be useful where execution has uncertainty but the definition of done is clear. Where checking the result is effectively as hard as doing the work, autonomy has not removed the real cost.

This is a more useful framing than the familiar question of whether a model is “good enough.” It asks whether the work has a legible rubric, whether evidence can be attached to the outcome, and whether the reviewer can make a decision without replaying an opaque process. Piras’s warning is operational rather than theoretical: agents can raise output faster than a team can review it, moving the bottleneck rather than eliminating it.

The other talks supplied concrete interface-level answers. In “Design at the Speed of Adjectives”, Paul Bakaus argued against both one-shot generation and raw prompt prose for context-rich design. His proposed control surface is a project-specific vocabulary—commands such as “bolder,” “quieter,” or “distill”—whose meaning is backed by reusable design guidance. An adjective without that context, he put it, is merely “a nicer prompt.” The point is not aesthetic shorthand; it is a way to preserve constraints, hierarchy, and intent across iterations.

Max Drake’s “The Spatial Harness: Bringing Agents to the Canvas” approached the same problem through coordination. His tldraw demos place screenshots, document state, and canvas actions in an agent’s working environment, while exposing task states and parallel work visually to people. The claimed advantage is not that a canvas makes agents intrinsically better at spatial work—Drake explicitly says they are poor at it—but that humans can see what is happening without reading every chat trace.

Why It Matters

Together, these are arguments for treating the harness as part of the product, not as auxiliary scaffolding around a model. A capable agent with no reliable way to demonstrate completion creates review debt. A design agent with no durable representation of local taste produces plausible but arbitrary variation. Several agents with no shared view of state create coordination work for the human who is supposed to be saved time.

That reinforces a developing practical canon: model progress matters, but durable agent workflows are won or lost on verification and context. The next useful benchmark may be less “can it complete the task?” than “can a reviewer establish that it completed the right task, at a cost lower than doing it manually?”

Workflow Implications

Teams evaluating agents should start by inventorying tasks with crisp acceptance criteria, then make the evidence of completion a first-class output. For creative work, encode recurring judgments into shared, inspectable project guidance rather than repeatedly restating them in prompts. For parallel work, expose status and artifacts in a common surface that supports quick human inspection.

None of the talks is a controlled evaluation; they are first-hand product and practitioner arguments supported by demonstrations. That limitation matters. But their convergence is notable: the discourse is becoming less interested in agents as autonomous performers and more interested in the systems that make their work governable.

Further Reading

• The Design-Code Roundtrip That Isn't — Jonathan Gordon’s practitioner critique of “lossless” design-to-code claims, with a useful emphasis on detecting drift before merge. Its product and experimental claims should be treated as preliminary.