A problem worth the tokens

The demo is always the same. The model drafts a flawless purchase order — correct filter, approved supplier, right price — and the room is impressed. Nothing has been purchased. The budget may be stale, the approver may say no, the supplier may never answer; what everyone is admiring is a document that has reached the first handoff.

So here is the question I want asked of every agent feature: when the model stops, whose job is it to find out whether reality agrees? If the answer is you — you reconcile the draft against the purchasing system, you chase the approval, you notice the duplicate — then the feature made one step cheaper and left the job intact. The token bill bought typing.

Name the finish line#

Paul David's history of factory electrification describes plants that swapped their central steam engine for one big electric motor and kept everything else: the shafts, the belts, the floor plan designed around steam. Productivity barely moved. It moved decades later, when factories reorganized the work itself around small motors at each station.

Most AI features are the motor swap. The inbox drafts a reply, the project board clusters tickets, the IDE proposes a patch — each one genuinely useful, and each one keeping you employed as the shafts and belts, carrying state between systems and repairing the mismatch when reality disagrees with the text.

The right column demos badly, because its value only shows up after the generated text: identity, permissions, idempotent tool calls, observations read back from the target system, a repair path for the write that half-succeeded. Building those is the unglamorous product work. Skip it and the same fluent output leaves an unpaid order, a duplicate purchase, a delivery nobody recorded.

Verification changes the unit of work#

METR's time-horizon measurements score agents on self-contained software tasks with success criteria a script can check, and they report a substantial drop the moment evaluators judge performance more holistically. Product work lives on the far side of that drop. "Send a plausible order" grades as text; "restock the filter without an unauthorized charge" grades against external state that no transcript contains.

An outcome system therefore keeps a case record, not a chat log. For the filter that means the requested part, the price ceiling, the approver, the vendor's response, the payment identifier, the receipt. Each model call reads a typed slice of that record, and each tool call comes back with evidence that advances the case or contradicts it.

Token count loses its grip as a metric here, and good riddance. Ten completions proposing the same order are wasted motion, while one long, ugly run that checks authority, survives a vendor timeout, reconciles the acknowledgement, and closes the inventory discrepancy may have replaced the actual job.

A precise stop is part of the outcome#

Some cases should end with a person, and the quality of that ending is measurable too. The useful escalation is narrow: the preferred supplier raised the price above the approved ceiling, no policy grants the agent authority to accept, and the quote expires Friday. Hand a reviewer a chat log instead and they get to rediscover all three facts themselves, which is the old job with extra reading.

The filter case stays open through approval, payment, delivery, and reconciliation, and a blocked case waits with the quote attached. On the happy path it closes on the least glamorous line in the record — received_quantity: 12 — which is exactly the line the demo never shows.