Detect, diagnose and intervene
AI Agent Monitoring and Observability
Monitor useful task completion, dependency health and review burden with correlated traces, actionable alerts and a worked latency diagnosis.
AI agent monitoring should tell the operating team whether useful work is being completed, where execution is slowing or failing and what intervention is needed. Model latency and server uptime are only part of that picture. An agent can remain technically available while using stale evidence, increasing review effort or leaving cases unresolved.
Observability provides the connected evidence needed to explain those symptoms. This guide is for service owners and engineering operations teams. Its illustrative case is a shipment-exception assistant that gathers permitted shipment facts, prepares an evidence-based case and routes it to an operator. The examples below are proposed designs and hypothetical measurements, not results from an Open for AI deployment.
Start with the operator's questions
Ask what the team needs to know during a normal day and during an incident. How many assigned cases reached a useful completion state? Which are waiting for evidence or a person? Did a source change increase unsupported outputs? Are repeated tool calls consuming time without advancing the task?
Each question should connect a signal to a decision. A dashboard tile showing token consumption is useful when someone can investigate or adjust a budget. It is less useful if nobody knows whether the increase comes from more work, larger documents, retries or a changed prompt.
Separate the operational purpose from the audit purpose. Monitoring supports timely detection and diagnosis; an audit trail preserves the evidence needed to review consequential actions. They can share identifiers and events, but their retention, completeness and access requirements may differ. The audit trail guide develops the latter contract.
Connect the workflow, model and tool activity
Use a task or case identifier to link the business request with relevant execution records. A trace can connect the stages of one run, including retrieval, model calls, tool execution and waiting. Record meaningful parent-child or causal relationships rather than treating every log line as an isolated event.
OpenTelemetry describes traces as connected operations represented through spans. Its GenAI conventions include agent, workflow and tool operations and are marked as under development. Choose and record a compatible instrumentation version rather than assuming the schema is permanently stable. See OpenTelemetry traces and the current GenAI agent conventions.
Useful context includes the deployed application version, model configuration reference, instruction version, tool name, source version where relevant, error category and final business state. Store sensitive content only where the agreed purpose and access controls require it. A reference to restricted evidence can be more appropriate than copying the full document into telemetry.
A worked latency diagnosis
Suppose a sequential shipment-exception run takes 45 seconds under an illustrative trace. The stages are 5 seconds waiting in a queue, 3 seconds reading shipment state, 28 seconds retrieving supporting evidence, 7 seconds generating the case and 2 seconds saving it. The total is 5 + 3 + 28 + 7 + 2 = 45 seconds.
| Stage | Elapsed time | Next investigation |
|---|---|---|
| Queue wait | 5 seconds | Worker capacity and arrival pattern |
| Shipment lookup | 3 seconds | Source response time and access checks |
| Evidence retrieval | 28 seconds | Retries, source latency and document selection |
| Model generation | 7 seconds | Input size and model-call behaviour |
| Case save | 2 seconds | Destination receipt and write outcome |
In this example, changing the model alone does not address the largest measured stage. Inspect whether evidence retrieval waits on a slow source, repeats a query or processes unnecessary material. The trace suggests where to investigate; it does not establish the root cause without the supporting details.
Real workflows may overlap stages. Do not add overlapping durations and present the sum as end-to-end latency. Measure the user's elapsed time separately and use the execution relationships to understand which stages lie on the effective path to completion.
Define signals at three levels
Service health
Track availability, dependency errors, queue depth, stalled work, tool timeouts and execution duration. Break failures into actionable categories such as invalid input, denied access, unavailable source and unknown write outcome. A single “agent error” counter hides which team can resolve the problem.
Task behaviour
Track completion, clarification, escalation, cancellation, budget exhaustion and reconciliation states. Observe repeated calls and unusual path changes. An increase in clarification may be appropriate after a scope change or may indicate degraded extraction; context determines the interpretation.
Business usefulness
Track reviewer acceptance, material correction, unresolved cases and the effort required to finish the work. These signals often require human feedback or destination-system evidence. They cannot be inferred reliably from a model's self-assessment or a successful HTTP response.
Keep the levels connected. A technical problem can cause a business backlog, while a source-policy change can affect output quality without any technical error. A useful operating view makes both patterns visible.
Set objectives with the service owner
Define service objectives for the supported workflow and workload. State the measurement window, denominator and exclusions. Time waiting for a required human decision may need a different objective from machine execution, but it still matters to the user's complete journey.
Inspect distributions rather than only averages. A small set of very slow cases can be operationally important even when the average looks acceptable. Segment by task type and relevant language journey where the sample is meaningful. Avoid interpreting tiny groups as stable trends.
Set quality objectives separately from latency. A faster answer with unsupported evidence is not an improvement. The evaluation guide explains how reviewed cases and regression tests provide evidence that telemetry alone cannot supply.
Design alerts that lead to action
An alert needs an owner, a reason to interrupt them, a view of the affected work and a first response. Choose thresholds from the agreed service objective, baseline and consequence, rather than copying a generic agent dashboard.
- Growing unresolved queue: inspect whether the constraint is source availability, reviewer capacity or a failed state transition.
- Unknown write outcomes: reconcile destination operations before allowing broad retries.
- Unexpected access-denial pattern: inspect identity propagation and any recent permission changes.
- Sudden resource growth: compare workload, document sizes, retries and release versions.
- Rising material corrections: review source freshness and behaviour changes, even if infrastructure remains healthy.
Use different urgency for different consequences. A routine capacity warning and a suspected data-boundary failure should not share the same response. Avoid alerting on every normal clarification; excessive noise makes meaningful signals easier to miss.
Observe quality through a maintained review loop
Collect structured feedback that distinguishes a wrong fact, missing evidence, unsuitable tone, incorrect routing and a failed action. An unqualified thumbs-down is difficult to diagnose. Make feedback easy enough that operators can provide it during their actual work.
Sample completed and incomplete cases deliberately, subject to the data handling policy. Reviewing only successful answers misses the exception workload. Reviewing only reported complaints can overrepresent visible failures while missing quiet omissions. Document the sample purpose before interpreting its results.
Turn confirmed new failure patterns into evaluation cases. Then reassess changes on appropriate independent cases. Monitoring discovers problems in operation; evaluation helps determine whether a proposed fix improves the supported behaviour. Neither replaces the other.
Control telemetry volume and sensitive content
Use bounded categories for aggregate metrics and keep case-specific identifiers in appropriately restricted records. Putting every document title or customer identifier into metric labels can create an unnecessarily complex telemetry set and expose information beyond the people who need it.
Choose sampling rules consciously. Retaining more failure traces can help diagnosis, but that sample is not an unbiased estimate of all traffic. Preserve the aggregate counts needed to interpret rates, and do not let diagnostic sampling remove evidence required by a separate audit obligation.
Define access and retention for telemetry itself. Logs and traces are another data store with an operating purpose. Redaction should happen at an appropriate collection boundary, and investigation access should be proportionate. The security architecture guide addresses the surrounding access design.
Make the monitoring system observable too
Check whether events arrive, identifiers remain connected and timestamps are usable. A quiet dashboard can mean that the service is healthy or that instrumentation stopped reporting. Monitor dropped telemetry, exporter errors and gaps after deployments where relevant to the chosen stack.
Verify that each important business state is represented. If the application records “completed” before confirming a destination write, the dashboard will faithfully report a misleading state. Observability quality depends on correct application semantics, not just an installed agent-tracing library.
Link releases to changes in behaviour. A rise in retries after a tool-schema update should be investigable without guessing which version handled each case. Keep rollback and selective-disable procedures available, with the effect on in-flight work defined. The orchestration guide covers that recovery boundary.
Keep the operating review focused
A regular service review should examine meaningful trends, unresolved incidents, source changes, reviewer burden and the next improvement decision. Avoid accumulating metrics without an owner or a use. Retire signals that no longer inform action and add new ones when the supported workflow changes.
Open for AI can scope agent development with monitoring needs and operating ownership defined. To discuss observability for your agent, bring the task's completion states, the systems it calls and the questions your operators must answer during a failure. Those questions determine the telemetry worth collecting.