Useful work per dollar is the agent metric that matters

The useful metric for enterprise AI is not “how smart is the model?” or “how cheap are the tokens?” It is closer to what OpenAI calls useful work per dollar.

That sounds obvious. It is not how many teams buy AI.

Most AI investment still gets treated like software procurement with a new label. Pick a model. Negotiate rates. Run pilots. Count seats. Maybe track usage. The agentic version breaks that frame because agents are not just answering questions. They are attempting tasks, calling tools, checking state, creating artifacts, and sometimes looping until they get stuck.

That means cost is no longer just model price. It is model calls, tool calls, latency, orchestration, retries, human review, failed runs, security work, and the boring integration tax. The unit of value has to move up the stack.

Token price is the wrong center of gravity

OpenAI’s framing pushes enterprises toward a better question: how much useful work does a system complete for each dollar spent?

That is a cleaner yardstick than cost per token because tokens are an input. Work is the output. A cheap model that needs three retries, misses edge cases, and burns reviewer time may be more expensive than a higher-priced model that finishes the task cleanly. The reverse can also be true. A smaller model may be good enough for classification, extraction, routing, and policy checks.

The practical implication is that model selection should happen inside a workflow, not in a leaderboard spreadsheet. If the job is invoice triage, the metric is not abstract reasoning. It is correct routing, exception handling, cycle time, reviewer load, and downstream errors. If the job is sales research, the metric is not a polished paragraph. It is qualified accounts found, bad leads avoided, and time saved by humans who would have done the digging.

This is where agent hype gets expensive. A demo that completes one impressive task can hide the real cost curve. What matters is the distribution of attempts over time. How often does it finish? How often does it ask for help? How often does it create cleanup work?

Efficiency comes from workflow design, not just cheaper models

The agentic era makes orchestration an economic problem.

A team can improve useful work per dollar by swapping models, but that is only one lever. Often the bigger gains come from narrowing the task, improving context, giving the agent cleaner tools, reducing unnecessary calls, and adding checkpoints where failure is cheap.

I would separate AI work into three buckets: tasks the system can complete alone, tasks where it drafts and a human approves, and tasks where it should only assist. The mistake is forcing everything into the first bucket because the demo looked autonomous. Autonomy is not a virtue if it raises risk or hides uncertainty.

Enterprises should also resist scaling too early. OpenAI’s point about scaling high-value workflows matters because not every workflow deserves an agent. Some are low-value, rare, politically messy, or dependent on data that no one trusts. An agent on top of a broken process is usually just a faster way to expose the breakage.

The better move is to find work with clear inputs, clear outputs, repeat volume, measurable quality, and an owner who can say what “done” means. Then instrument the process before and after AI. Not perfectly. Enough to know whether the system is creating value or just activity.

The new budget conversation

AI budgets should start looking less like seat planning and more like operations planning.

For each workflow, define the unit of work, the acceptable quality bar, the human role, the cost per completed unit, and the failure path. Then compare AI-assisted work against the current baseline. If nobody knows the baseline, that is the first project.

This also changes vendor conversations. A lower per-token price is nice. It is not the deal. Ask how the system handles retries, tool use, evaluation, logs, permissions, and handoffs. Ask what evidence exists for the workflow you actually run. If the answer is a generic benchmark, treat it as a clue, not a decision.

For builders, I would pick one recurring workflow this week and write down the current cost in human time, error rate, and cycle time. Then build the smallest agentic loop that can complete part of it, with logging from day one. Track completed work, not chat volume. The catch most readers miss: the winning system may not be the most autonomous one. It may be the one that knows exactly when to stop and hand the task back to a person.