AI Agent Unit Economics: Measure the Completed Workflow, Not Token Price

Why token price does not answer the agent ROI question

For a conventional chatbot, economics can still be approximated per request: input tokens, output tokens, and model time. An AI agent behaves differently. It reads context, chooses a tool, calls a CRM or search service, validates the result, retries a failed step, waits for human approval, and calls the model again.

One user task becomes a trajectory of operations. A cheap model call therefore does not guarantee a cheap process, and a lower token price may be insignificant next to retries, external APIs, and human review.

For a manager, the right unit is not a token or a run. It is an accepted business outcome: a correctly created request, a reconciled document, a handled inquiry, or an updated customer record. That is the unit to compare with employee effort and automation cost.

What the sources establish

The FinOps Foundation’s token-economics guidance explicitly separates marginal inference price from the full economics of an initiative. Costs include standing instructions, context and memory, model selection, output length, retries, and orchestration. It recommends looking at cost per inference, workflow, and outcome, including useful output or goodput.

LangGraph documentation explains why a trajectory may replay. After an interruption, execution resumes from a checkpoint and the affected node can start again; side effects must be idempotent. Human-in-the-loop mechanisms persist state while waiting for a decision. These are valuable capabilities, but they create real operations, latency, and cost.

OpenTelemetry defines attributes for input, output, reasoning, and cache tokens, as well as model, workflow, and tools. Costs can therefore be collected for one trajectory instead of being inferred only from a provider invoice. The specification also warns that prompts, responses, and tool arguments may contain personal or sensitive data.

An independent study of token consumption by coding agents found large variation across repeated runs of the same task and no simple relationship in which more tokens always produced higher accuracy. Those coefficients should not be copied into accounting or customer support, but the method transfers: budget an agent from its own traces and outcomes, not from an average demo request.

Four layers of cost

Split one run into four buckets.

1. Model

This includes:

• input and output tokens for every call;
• repeated context and conversation history;
• reasoning tokens when metered separately;
• cache creation and reads;
• embeddings, reranking, and auxiliary models;
• local inference allocated by actual active time.

Count every call inside the workflow. The final answer may be short even if the agent reread a large document set three times before producing it.

2. Tools and data

Some calls have direct prices: search, OCR, maps, telephony, digital signatures, or sector-specific APIs. A free internal method still uses database resources and can occupy a queue.

For each tool, record call count, latency, success, direct price, and the amount of context returned. A slow or noisy tool can increase model cost because the agent analyzes more output and retries more often.

3. Orchestration and infrastructure

The queue, checkpoint database, ledger, vector store, monitoring, and policy service are not free. A local deployment also adds server amortization, electricity, reserved capacity, and administrator time.

These costs are usually fixed or stepwise. Allocate them to accepted outcomes during the period, not to the hardware’s theoretical throughput.

4. Human effort and error cost

Approval, correction, and exception handling often cost more than inference. Count employee minutes at the fully loaded hourly rate. Track damage or recovery work from incorrect actions separately; do not hide a serious risk inside an average unit price.

The baseline formula

For a month or week, use a simple calculation:

`cost per accepted outcome = all workflow costs / accepted outcomes`

The numerator is:

`models + tools + infrastructure + human review + reprocessing`

The denominator contains only outcomes that pass the business acceptance criterion. A run with technical status `success` that creates the wrong record is not useful output.

Keep three adjacent metrics:

• share accepted on the first attempt;
• share accepted after retry or human correction;
• share rejected or unfinished.

This reveals where savings are real and where cheap calls conceal a long exception queue.

A model calculation for 1,000 tasks

This is an illustration, not a market price. Assumptions:

• 1,000 inbound-request tasks per month;
• first-attempt model, infrastructure, and tool cost of RUB 6 per task;
• 20% of tasks require one retry costing RUB 5;
• 10% require four minutes of employee review;
• fully loaded employee cost is RUB 900 per hour;
• the business accepts 930 outcomes.

Calculation:

• first attempts: `1,000 × 6 = RUB 6,000`;
• retries: `200 × 5 = RUB 1,000`;
• human review: `100 × 4/60 × 900 = RUB 6,000`;
• total: `RUB 13,000`;
• per accepted outcome: `13,000 / 930 ≈ RUB 14`.

Looking only at first attempts produces RUB 6 per run. The complete unit is almost 2.3 times higher—not because of an expensive model, but because of retries and human time.

Replace every input with pilot measurements. Include payroll overhead in the hourly rate, and allocate a local server over actual useful volume. Do not assume perfect future utilization.

Building a ledger for one trajectory

Every business task needs a stable `workflow_run_id`. The ledger only needs:

• task class and workflow version;
• start and finish time;
• outcome: accepted, corrected, rejected, or unfinished;
• model and tokens for each call;
• count, type, and status of tool calls;
• retry count and reason;
• cache usage;
• human waiting and working minutes;
• quality-check identifier;
• allocated infrastructure cost.

Do not record prompt and document contents by default. Metadata is usually sufficient for economics. If content is needed for debugging, capture it selectively with PII redaction, restricted access, and retention limits.

Link the trace to the business event: request, invoice, or ticket ID. Finance then sees the cost of an operation class rather than abstract tokens.

Stop conditions protect the budget

An agent must not be allowed to “try once more” indefinitely. Define for each task class:

• maximum model calls;
• maximum calls to one tool;
• retries for the same error;
• maximum elapsed time;
• input-context limit;
• monetary run budget;
• mandatory human-escalation conditions.

After a limit is reached, the task should enter an explicit exception state instead of continuing the loop. This is both an economic and operational control: predictable failure is cheaper than unpredictable autonomy.

Where an agent is unnecessary

If a process is fully described by rules, the model should not reinvent the same plan on every run. Required-field checks, tax calculation, database writes, and sending an approved template belong in deterministic code.

An agent is useful where the system must understand an ambiguous request, select a source, compare documents, or propose a decision. A structured command can then enter a conventional workflow with validation and permissions.

A practical hybrid pattern is:

`model classification → bounded plan → deterministic tools → rule validation → approval → action`

The more repetitive the process, the more of the path should move out of model reasoning. This reduces tokens, outcome variance, and expensive reviews.

API and local models use the same ledger

For an external API, the call price appears on an invoice. For a local model, it is hidden but not zero. Estimate it as:

`active accelerator time × fully loaded node-hour cost + storage and operations share`

The node-hour includes amortization, electricity, cooling, reserve idle time, and administration. If a GPU is utilized at 20%, do not allocate costs as if it operated at an imaginary 100%.

Keep the same workflow metrics in both options. A move to local infrastructure can then be based on cost per accepted outcome, data requirements, and throughput rather than an impression created by token price.

A two-week pilot

Choose one process with a measurable outcome and preserve the human baseline. Then:

1. Define an accepted outcome.
2. Collect 100–300 representative tasks, including exceptions.
3. Instrument every model and tool call.
4. Record retries, human minutes, and failure reasons.
5. Add trajectory budgets and human escalation.
6. Compare cost, time, and quality with the current process.

Scale based neither on a polished demo nor on a falling token price. Scale when cost per accepted outcome is lower—or the value of speed is higher—while risk and the human exception queue remain manageable.

The management takeaway

Ask the team for one table by task class: runs, accepted outcomes, retries, tool calls, human minutes, cost, and p95 completion time. If that table does not exist, the agent’s economics are still unknown.

Start with trajectory budgets and a run ledger. Model optimization makes sense after the whole receipt is visible—especially the part the friendly agent printed in very small type.