Agent Telemetry

When one agent run goes wrong you read its trace. When a thousand runs go wrong you need numbers. Agent telemetry is the stream of measurements an agent emits as it works — counts, durations, costs, outcomes — aggregated across runs so the behaviour of the whole system becomes visible rather than anecdotal.

What actually gets measured
Telemetry is the quantitative sibling of tracing: a trace tells the story of one run, telemetry tells you the distribution across all of them. The signals that matter:

• Step counts per run, and how many runs ended at the step limit instead of a real termination condition.
• Token and spend totals, broken down by model and by tool.
• Tool-call volume, latency and error rate — which tool is failing, and how often a failure is retried rather than handled.
• Task success rate and the share of runs that escalated to a human.

Why a loop needs it
A single model call either returns or errors, and its cost is known before you make it. An agent decides its own length, so cost, latency and step count become distributions instead of constants. Telemetry is how you find out that a tool's slow tail doubled after a vendor update, that one prompt edit pushed median step count from four to nine, or that spend per task crept up a fraction of a cent at a time. Without it the first alert is the invoice.

How it is wired
Emission normally rides on OpenTelemetry spans, the same instrumentation that produces traces, with metrics derived from them. Platforms such as LangSmith present both views over one captured run, which is why teams instrument once and read it two ways.