Agent observability should answer questions, not produce dashboards

An agent dashboard can show token use, latency and error rate while leaving the most important questions unanswered. Why did the agent choose that tool? Which source supported the decision? Whose authority did it use? Did the external action occur? Was the outcome verified? Can the team reproduce the behaviour under the same configuration?

Observability is useful when it shortens the path from an operational question to defensible evidence. Start with the questions an operator, incident responder, release owner and governance function must answer. Instrument the workflow to answer those questions safely.

Begin with five operational conversations

Before selecting telemetry fields, write the questions that arise in real decisions.

Incident triage

• What changed, for whom and when?
• Which actions are still in flight or ambiguous?
• Can we stop further effects and identify affected records?

User dispute

• What did the user request and confirm?
• Which evidence and policy were applied?
• Which identity performed the action?

Release comparison

• Did the new model, prompt, tool or retrieval index change outcomes?
• Which scenario segments regressed?
• Are differences statistically and operationally meaningful?

Control review

• Were required approvals, permissions and verification steps enforced?
• Which exceptions occurred and who resolved them?

Cost and reliability

• Which workflow steps create retries, latency and spend?
• Does extra computation improve verified outcomes?

If a metric cannot help answer a defined question or trigger an action, reconsider collecting it.

Model one workflow as a connected evidence chain

Use a stable workflow identifier and attach related identifiers rather than forcing every system into one log format.

Evidence area	Minimum useful record
Intent	Initiating principal, requested outcome, time and confirmed scope
Configuration	Agent, model, prompt, policy, tool and retrieval versions
Context	Source references, versions, access decision and assembly policy
Decisions	Route or plan selected, alternatives considered and governing rule
Authority	Subject, actor, scope, approval, expiry and policy result
Actions	Tool, sanitised parameters, attempt, response and external reference
State	Transition, prior version, event, actor and resulting version
Verification	Independent end-state check, grader or human decision
Outcome	Completed, declined, compensated, escalated or unresolved

The W3C Trace Context standard provides a vendor-neutral format for propagating trace correlation across services. Use it for technical request flow, but keep a business workflow ID as well: one workflow may pause for days, fork into asynchronous work or include actions that are not part of one continuous trace.

Distinguish spans, events, metrics and evidence

These signals serve different questions:

• Spans show operations with a start, end and parent relationship: model inference, retrieval, tool calls and handoffs.
• Events capture point-in-time facts: approval granted, state changed, retry scheduled, policy denied or incident declared.
• Metrics aggregate behaviour: verified success, fallback rate, p95 latency, duplicate prevention or cost per outcome.
• Evidence records preserve decision-relevant artefacts under stronger integrity and retention controls: approval, external receipt, evaluated trace and release result.

OpenTelemetry’s semantic conventions establish shared meanings for attributes across traces, metrics, logs and events. Its event guidance recommends events for meaningful occurrences such as state changes and outcomes, and spans for operations with duration. Follow stable conventions where they fit, and version any agent-specific extension.

Telemetry is not automatically audit evidence. Sampling, mutation, retention and access may differ. Decide which records must be complete and tamper-evident for the workflow’s consequences.

Observe model decisions without pretending to read minds

Do not require hidden chain-of-thought or treat a generated rationale as a faithful explanation of internal computation. Record observable inputs and outputs needed to reproduce or assess the decision:

• task and permitted options;
• model and instruction versions;
• retrieved source references;
• structured tool proposal;
• policy checks and grader results;
• final selection and confidence if the system exposes one; and
• independent outcome verification.

If the application asks the model for a short rationale, label it as model-generated explanation. It may help a reviewer understand the proposal, but it should not replace the evidence path.

Minimise content before it enters telemetry

Logging every prompt, retrieved document and response creates a second data system with its own privacy and security risk. Use an evidence ladder:

1. identifiers, hashes, versions and structured outcomes;
2. minimised non-sensitive attributes;
3. redacted excerpts for defined diagnostic cases;
4. encrypted full content only where justified, access-controlled and time-limited.

Do not place personal or confidential content into high-cardinality labels or broadly propagated trace metadata. W3C’s Baggage specification warns that baggage can carry user-identifiable or sensitive data and recommends removing information that should not cross trust boundaries.

Define retention by purpose. Operational traces, security evidence, user-dispute records and evaluation datasets may need different periods and access. Test deletion and ensure backups or derived analytics do not silently reactivate expired content.

Measure effects, not only agent activity

Tokens, model calls and tool attempts describe effort. The workflow owner needs outcomes:

• authoritative state reached;
• policy-compliant completion;
• unresolved or ambiguous effects;
• human rework and escalation;
• repeated or compensated actions;
• time and cost per verified completion; and
• severe failures by consequence tier.

Connect those outcomes to the trace. An agent can report success while the target system rejects the update. Conversely, a timeout can be recorded as a tool error even though the operation completed. Reconciliation evidence closes that gap.

Avoid a single “agent success rate.” Segment by workflow, action class, user group where appropriate, configuration and failure consequence. A stable average can hide a regression in a small high-impact path.

Make sampling support investigation

Random sampling controls cost but can discard the trace needed after a rare failure. Combine methods:

• retain all high-consequence write actions and policy denials;
• retain all failed, ambiguous, compensated and escalated workflows;
• use tail sampling based on end-state, duration or anomaly;
• sample routine successes at a documented rate; and
• temporarily raise sampling during a controlled release or incident.

The W3C trace guidance notes that independent sampling decisions can fragment traces. Propagate the decision consistently where possible and make missing spans visible rather than allowing an incomplete trace to appear complete.

Connect thresholds to named actions

A dashboard becomes operational when a threshold has an owner and response. Examples:

Signal	Trigger	Action
Ambiguous write effect	Any high-consequence occurrence	Pause that tool path and reconcile
Verification failure	Above the approved release threshold	Roll back or narrow the changed configuration
Human escalation backlog	Response objective breached	Reduce autonomous intake or add accountable capacity
Route shift	Material unexplained change by segment	Inspect traffic and router versions
Sensitive-content logging	Any confirmed exposure	Restrict access, contain, investigate and follow incident process

NIST’s 2026 paper on monitoring deployed AI systems examines practical monitoring challenges rather than treating tool adoption as sufficient. The NIST Generative AI Profile also connects post-deployment monitoring with incident response, recovery and change management.

Test observability by running an investigation

Select representative failures and give an operator only the records that would exist in production. Ask them to determine the initiating request, configuration, context sources, authority, actions, final state, affected objects and safe next step. Measure time, missing evidence and false conclusions.

Then test failures in the observability system itself: exporter outage, clock skew, duplicate events, schema change, redaction failure, broken propagation and delayed ingestion. The workflow should remain safe when telemetry is impaired, while making the evidence gap explicit.

The goal is not a wall of charts. It is the ability to reconstruct what mattered, decide what to do and prove that the response worked. Every dashboard should be downstream of that purpose.