Hypernovelty Institute Technical Intelligence

Lead analysis · July 13, 2026

Pay for Work That Passed

By Jordan Finneseth

The prompt starts the job. The bill covers the whole trip. Agent procurement needs cost per verified completed task, with failed runs visible and energy claims tied to measured telemetry.

A data-centre operations analyst reviews a completed work receipt beside a stack of failed-run records.

The useful unit is verified completed work, with failed runs and measurement boundaries left visible.

Give an AI agent a purchasing task and watch what happens behind the chat box. It may search four databases, call a model several times, wait on a supplier API, retry a broken response, and send the result through a factual check before it drafts an order.

The prompt started the job. The bill covers the whole trip.

The International Energy Agency’s April report says the energy used by a simple AI task has fallen sharply as software and hardware improve. At the same time, reasoning, video, and agentic tasks can consume hundreds or thousands of times more energy per query than simple text generation. The IEA estimates that global data-centre electricity demand grew 17% in 2025, while consumption from AI-focused data centres grew 50%.

Those figures describe a large physical system. They do not tell an operator what one useful agent task cost.

An agent can branch, call tools, replay context, wait, retry, fail, and ask another system to check its work. Two runs that begin with the same prompt may leave very different trails. Counting prompts records intake. Counting model calls records activity. Neither measure proves that the requested work finished or passed review.

A July summary from KAIST shows how wide the range can get. Researchers behind an HPCA 2026 paper tested several open agent designs on named benchmarks using Llama models, vLLM, and A100 hardware. In one disclosed 70-billion-parameter setup, KAIST reported average energy use of 348.41 watt-hours per query, 136.5 times its simple question-and-answer comparison.

That number belongs to the tested configuration. KAIST’s much larger 198.9-gigawatt figure scales the same setup to 13.7 billion daily requests as a scenario. It cannot be carried over to every agent, cloud service, or workplace task.

Other recent work shows that design choices can move the bill in the other direction. MIT and Microsoft researchers reported on July 2 that their Murakkab system met user constraints on selected video-question and code-generation workflows while using about 35% of the computation, 27% of the energy, and less than 25% of the cost used by comparison methods. The results come from specific research workloads.

A Writer-authored July preprint reports another controlled comparison. Across 22 locked enterprise tasks and six models, its harness swap used 38% fewer tokens per task, cut blended cost by 41%, and reduced median wall time by 44%, while judged completion quality stayed roughly level. The study is vendor-authored, uses a small task set, and has not been independently replicated. It measured tokens, money, and time rather than electricity.

Taken together, these sources point toward a better operating unit: verified completed work.

A useful receipt would carry a stable task identity; model calls, tokens, tool waits, and retries across the full run; a terminal state; and an independent verification result. Failed, abandoned, and unverified attempts belong in separate columns. Otherwise a team can make its successful tasks look efficient by hiding everything that burned resources without passing.

Energy needs its own hard boundary. Tokens and elapsed time are useful accounting fields, but a generic conversion into watt-hours produces a number that may ignore hardware allocation, utilization, networking, storage, cooling, and facility overhead. The IEA says these components vary substantially among data centres. If the provider or operator lacks measured telemetry, the honest energy field is “unavailable.”

NIST’s evaluation-probes project offers a practical glimpse of the verification layer. Its research testbed places automated checks inside an agent workflow, compares claims with trusted source material, and stores structured verdicts in a machine-readable audit trail. This remains a research project rather than a binding standard. Still, the shape is useful: the evidence that work passed should travel with the work.

Verification bottleneck

Verification is becoming the scarce institutional function.

  • Agent workflows, tool calls, and retries can accumulate faster than teams can reconstruct whether a task finished correctly and what it consumed.
  • Operators, customers, cloud providers, auditors, and procurement teams now have to verify task identity, terminal state, evidence quality, failed spend, and any energy claim attached to the run.
  • Watch next: provider telemetry tied to individual task trajectories, independent verifier costs, shared receipt formats, and contracts that distinguish attempted work from work that passed.

Opportunities

Where value may appear: small, inspectable systems for agent-task receipts.

A builder could create a task-identity layer, a failed-run ledger, a verifier sidecar, a receipt exporter, or a procurement checklist that asks for the same evidence across vendors. Another useful product would show cost per verified completed task while keeping failed and unverified runs visible.

Energy reporting is a separate opportunity, but only where real telemetry exists. Tools could declare the measurement boundary, show which hardware and facility components were included, and refuse to manufacture an estimate from token counts alone.

This is builder idea fodder based on current research, not energy, engineering, procurement, financial, compliance, or investment advice.

The practical question for an agent pilot is simple: What did we pay for work that actually passed?

Public sources