Your traces know latency, not what a task was worth

A tracing stack can replay every token of a failed run. It will show you which tool call timed out, which retry burned an extra 4,000 tokens, and exactly how many milliseconds elapsed between the LLM response and the downstream API write. What it cannot show you is what a successful run was worth.

That asymmetry is the core problem with AI agent cost per task observability today.

What observability actually measures

Modern agent observability platforms track a well-defined set of signals. CloudZero's breakdown of agent-level schemas lists the canonical fields: total latency, total dollar cost across all steps, task outcome (completed, failed, timed-out, budget-killed), user and tenant IDs, and counts of LLM calls, tool calls, and retrieval queries per task.

That schema is genuinely useful. It is also incomplete in one specific direction: none of those fields capture the business value produced when the task succeeded.

Latency tells you the task took 8.3 seconds. Token cost tells you it burned $0.014. Error rate tells you 3% of runs never finished. None of that tells you whether the task that finished was worth $0.02 or $20.00.

The cost side is already non-trivial

Before arguing for adding a value field, it helps to understand what you are already paying to instrument the cost side.

According to Bartosz Cruz's April 2026 analysis of production agent costs, observability tooling alone costs roughly $80 per month at 10,000 tasks, $420 per month at 50,000 tasks, and $1,800 per month at 250,000 tasks, excluding model and API spend. A team of three engineers monitoring an agent that generates 200,000 traces per month on LangSmith Plus pays approximately $217 per month just for trace storage, on top of the $39-per-seat plan fee.

Zoom out further and Tokenfence's May 2026 cost breakdown puts the full observability stack at a 12 to 20 percent overhead on total AI spend for a fleet of 100 agents. Full prompt and response logging alone accounts for 8 to 15 percent of token spend.

So you are spending real money to know your costs precisely. You are spending nothing to know your value at all.

Why agents make this worse than single-call LLMs

A single chatbot call has one input, one output, one latency number, and one token count. An agent task chains model calls, tool invocations, retrieval steps, and conditional branches. Gartner's 2026 figures, cited in Splunk's observability research, put agentic workloads at 5 to 30 times more tokens per task than a single chatbot call, driven by reasoning loops, retries, and multi-agent coordination.

That multiplier means cost per task is already volatile and hard to reason about. When you layer in the fact that two tasks with identical token counts can produce wildly different business outcomes, cost-only observability becomes actively misleading. A task that resolves a $2,000 support escalation and a task that answers a FAQ both look the same in your trace dashboard.

The one field that changes the equation

Closing the gap does not require a new platform. It requires one additional field emitted at task completion: the value of the outcome, in the same currency unit you use for cost.

What that field contains depends on your domain:

• Support deflection: the loaded cost of the human ticket that did not get created. If your support team costs $35 per resolved ticket and the agent closed the issue, value = 35.
• Document processing: the per-document rate your ops team would have charged. If a human analyst bills at $0.80 per processed invoice, value = 0.80.
• Lead qualification: the pipeline value of a qualified lead times your historical conversion rate. If a qualified lead is worth $120 in expected revenue, value = 120.

Once you have cost and value in the same record, the metrics that actually matter become computable:

# Per-task unit economics, computed at collection time
roi_ratio = task_value / task_cost          # e.g. 35 / 0.014 = 2500x
net_value  = task_value - task_cost         # e.g. 35 - 0.014 = $34.99
break_even_success_rate = task_cost / task_value  # e.g. 0.04%

Those three numbers answer the questions a finance team or a board actually asks. The tracing dashboard answers the questions a SRE asks at 2 a.m.

Where teams get stuck

The practical blocker is not instrumentation complexity. It is that value is often known by a system that is not the agent runtime. The CRM knows the ticket was closed. The ERP knows the invoice was approved. The agent orchestrator knows the task finished, but not whether the downstream system accepted the result.

The pattern that works is a two-step emit: the agent emits task completion with cost fields immediately, and the downstream system emits the value field on confirmation, referencing the same task ID. Both events join on that ID before the metric is computed.

At 10,000 to 50,000 tasks per month, that join is trivial in any event store or time-series database you are already running. The engineering lift is one webhook or one additional API call per workflow, not a new data pipeline.

Cost observability is necessary but not sufficient

A tracing stack that reports latency, tokens, and error rates is doing its job correctly. It was designed to answer operational questions. It was not designed to answer financial ones.

The operational questions and the financial questions both matter. Right now, most teams have complete answers to the first set and no answers at all to the second. Adding a single value field per completed task is the smallest possible change that makes both sets answerable from the same data.