Telemetry

Definition

Telemetry is data a running system emits about its activity. Traces connect operations in a request, metrics measure behavior over time, and logs record events. These signals help operators investigate agent workflows when they include useful context.

Telemetry is the stream of operational signals emitted by software. OpenTelemetry describes traces, metrics and logs as distinct signals: a trace follows a request through spans, a metric records a measurement, and a log records an event. Observability is the practice of using those signals to understand behavior; an audit trail is a separate evidence requirement.

What it covers

Traces

Spans linked by a trace ID show the path and timing of one operation.

Metrics

Aggregated measurements reveal rates, latency and usage trends.

Logs

Structured event records capture outcomes and relevant context.

Instrument the model call, authorization decision and tool boundary according to the questions an operator needs to answer. Decide which events and attributes are needed, who may see them, how long they are kept, and whether sampling may leave gaps. A missing log entry alone cannot prove an action did not occur.

In practice

Practical design patterns by Min.

• Choose signals for a concrete operating question before adding fields.
• Correlate a run or task ID with trace and span IDs across model, policy and tool steps.
• Record status and timing while limiting raw prompts, secrets and personal data.

Attach a stable run or task identifier to related operations and preserve trace and span correlation where the tooling supports it. Record tool name, outcome, duration and retry count without making raw prompts or customer data routine fields.

Use metrics for patterns such as error rate, latency and usage. Use traces to locate the slow step, then structured logs to inspect the relevant event. Keep the field names and meanings consistent across services.

Research notes

Source-grounded details and editorial applications. Follow each link for the original document.

Working example

Why the controls matter

If a task repeatedly retries a document tool, a trace can locate the failing spans, a retry metric can show whether the issue is widespread, and correlated logs can show timeout or policy-denial outcomes for that run.

Common pitfalls

• Assuming no recorded event means no action happened.
• Capturing sensitive payloads by default or treating operational logs as a complete audit trail.

High-cardinality labels can make metrics difficult to use. Raw prompts, tool payloads and URLs may contain sensitive material; apply minimization, redaction, access and retention controls. Sampled traces or missing instrumentation are not complete evidence of every action.

Questions for operational review

Use these questions to decide what evidence your team needs. They are editorial prompts, not a compliance checklist.

• Which operating question does each signal answer?
• Can one run be followed across model, policy and tool steps?
• What sensitive fields are excluded, and what might sampling omit?