# Cost Per Resolved Task: The Unit Economics of an Agent

*Published 2026-03-10 · Dmitry Shirokov · shirokoff.ca/blog/agent-unit-economics*

Six weeks after shipping a support-triage agent, the platform lead sent me the bill with one line highlighted: "is this right?" It was. So were our per-call numbers — a median of ~0.4¢ per model call. Nobody had multiplied it by the number of calls a real agent makes to finish a real job. **A chat completion has one call per answer; an agent has a loop whose length a model decides at runtime — so your unit cost is a distribution you don't control.** Companion to [LLM & AI FinOps](https://shirokoff.ca/blog/llm-ai-finops-token-costs), which covers the platform view.

## The only unit that matters

**Cost per resolved task**: total spend ÷ tasks finished acceptably, same window. The denominator does the work — it forces you to define "resolved" and to count failures, which per-call metrics let you avoid.

| Factor | Why it dominates | Where it hides |
|---|---|---|
| Steps per task | Linear multiplier on everything | Mean 3.4, p95 14 — and the p95 is most of your spend |
| Context re-sent per step | Cost grows **quadratically** with steps | Invisible unless you log prompt tokens per *step* |
| Resolution rate | A failed task costs tokens *and* the human who redoes it | Nobody joins spend to outcome |
| Retry/loop behaviour | An ambiguous tool error sends the model round again | Looks like "thinking"; reads like self-inflicted denial-of-wallet |
| Human minutes saved | The numerator of the business case | Owned by ops, never in the same doc |

The quadratic term surprises people: step *n* re-sends steps 1..*n*−1. Twelve steps growing by a page each is ~70 pages of input, not 12. A small change in step count moves the bill more than switching to a cheaper model.

## Instrumentation

Three things per run: a **task id spanning the whole run**, **per-step input/output token counts**, and a **resolution verdict on the same record as the spend**. Traces give you the first two nearly free if you emit OTel; the verdict is what teams skip, leaving spend data with no denominator. Then report `sum(usd) / count(resolved)` beside p95 steps, segmented by tenant — a few tenants or task types always dominate spend, and averages hide them.

## Five levers, by leverage

1. **Cap the steps, escalate on the cap.** Turns the worst case from unbounded into arithmetic, and forces an escalation path you wanted anyway. Set the cap from your own p95; also cap wall-clock and total tokens.
2. **Stop re-sending what the model doesn't need.** Summarize spent tool output, keep compact running state instead of a verbatim transcript. Also improves quality — a short clean context beats a long one full of stale dumps.
3. **Route by step, not by agent.** Tool selection is often trivial; final synthesis isn't. Put routing in [the gateway](https://shirokoff.ca/blog/llm-gateway-routing-fallback). Measure quality per step class — a cheaper router that adds two steps cost you money.
4. **Make tools return less, and fail unambiguously.** Tool output is input tokens on every later step. "Not found: no customer with id X, try search_customer" ends the loop; "Error: 400" restarts it, and a retry is a full extra step.
5. **Cache the stable prefix.** In an agent the system prompt and tool schemas are re-sent every step, so prefix caching compounds across the loop. Keep the stable part stable; put volatile context last. This is provider-side prefix caching, not a semantic response cache.

## The failure that shows up when the agent is *working*

A model upgrade improved tool selection and doubled the bill the same week: the agent began attempting harder tasks it used to bounce, mean steps 3 → 5, p95 9 → 22, and nobody watched that metric because quality had improved. Track **steps-per-task and cost-per-resolved-task on the same dashboard as quality**, alert on the **p95 not the mean** (the tail is where thrashing announces itself), and set a per-tenant daily budget with a hard stop.

## The business case

Compare **cost per resolved task against cost per task the old way**. A human triage at eleven minutes of loaded cost is your ceiling — and unresolved tasks cost tokens *plus* human minutes, so a low resolution rate can breach the ceiling even with a cheap loop. An agent resolving 60% can be worse than no agent; 85% at twice the token cost is usually a clear win. **The denominator moves the ratio more than the numerator does**, so fix resolution before shaving tokens.

## Carry-away

Per-call cost makes agents look free; cost per resolved task tells you whether to ship one. Instrument task id, per-step tokens, and a verdict on the same record. Then: cap steps, trim context, route per step, make tools terse and their errors actionable, exploit prefix caching. Watch p95 steps next to quality. And keep the comparison honest against the loaded human cost, including the tasks the agent hands back.

*Related: [LLM & AI FinOps](https://shirokoff.ca/blog/llm-ai-finops-token-costs) · [Agent state you own](https://shirokoff.ca/blog/agent-state-portability) · [LLM observability](https://shirokoff.ca/blog/llm-observability) · [The LLM gateway](https://shirokoff.ca/blog/llm-gateway-routing-fallback) · [Agent frameworks compared](https://shirokoff.ca/blog/agent-frameworks-compared)*