AI Agent Observability: What a Trace Shows and Can't Stop

OpenTelemetry's primer defines observability as the ability to understand a system from the outside by asking questions about it without knowing its inner workings, and it names three signals an application emits to make that possible: traces, which record the path a single request takes through services; metrics, which are aggregations of numeric data over time; and logs, which are timestamped messages. A trace is built from spans, each a single unit of work, with a root span that covers the request end to end. Agent observability keeps all of that and changes one thing. In a conventional service the call graph is fixed at build time, so a trace confirms a path you already knew. In an agent the model decides at runtime whether to call a tool, which one, with what arguments, and whether to call another afterwards. There is no source file that shows the path. The trace is the path. That is why the term has become its own discipline rather than a footnote on APM: the questions are different (why did it pick that tool, why did it retry, what did the tool return that made it stop) and the unit of interest is the decision, not the request.

A large share of the searches around this phrase are for products, not the practice, and the word order flips the meaning. An observability agent is an AI agent whose job is observability, usually shipped by a cloud or monitoring vendor to sit on top of your existing telemetry. Microsoft alone ships several. The Azure Copilot Observability Agent lives in Azure Monitor and lets you ask natural-language questions over logs and metrics, run deep investigations that correlate application, infrastructure and platform signals into a report, and (in preview) run autonomous alert correlation that opens Azure Monitor issues for the on-call team; Microsoft's own docs state it does not restart resources, change configuration or resolve issues on its own. Azure SRE Agent is a separate product aimed at incident response: it queries Application Insights and Log Analytics, proposes mitigations, prefills a ServiceNow or PagerDuty ticket, and can connect to Datadog, Splunk, New Relic, Dynatrace and Elasticsearch over MCP. In Microsoft Sentinel the relevant piece is the Agent 365 data connector, which brings AI agent telemetry from Agent 365, AI Foundry and Copilot into the Sentinel data lake so security teams can investigate agent behavior, tool usage and execution with hunting, graph and MCP workflows. So: AI agent observability is instrumenting your agents so a human can inspect them; an observability agent is a vendor's agent inspecting your systems. The two meet in Sentinel, where the second is used to watch the first.

Until recently every tracing vendor invented its own span names for LLM calls, which meant traces from one SDK could not be read by another backend. The OpenTelemetry project is closing that gap with the GenAI semantic conventions, now maintained in their own repository. They define a set of well-known values for gen_ai.operation.name, including chat, create_agent, invoke_agent, invoke_workflow, plan, execute_tool, embeddings and retrieval operations, and they model an agent run as a tree: an invoke_agent span at the top, with chat spans for each model call, plan spans for decomposition, execute_tool spans for each tool call, and memory spans for create, search, update and delete operations. Attributes such as gen_ai.agent.name, gen_ai.agent.id, gen_ai.conversation.id, gen_ai.tool.definitions, gen_ai.tool.call.arguments and gen_ai.tool.call.result carry the context. Two facts matter for anyone adopting this today. First, every page in the agent conventions is marked Status: Development, which means names can still change between releases; Microsoft's Foundry docs repeat the same warning. Second, stabilization is now actively in progress: an issue opened on September 11, 2026 proposes stabilizing the inference span, the invoke_agent client and internal spans, invoke_workflow, execute_tool, the operation duration and token usage metrics, and the inference details event, while noting that span ownership, duplicate suppression and the agent-versus-workflow relationship are still being clarified. The conventions also treat message content as opt-in: gen_ai.input.messages, gen_ai.output.messages and gen_ai.system_instructions carry a warning that they are likely to contain sensitive information, so prompts and completions are not recorded unless you switch them on.

Working backwards from the questions you will actually ask, a useful trace of one agent run carries five things. The trigger: the event or request that started the run, with a stable conversation or session id so multi-turn work can be stitched together. The decisions: each model call as a span with the model name, token counts in and out, latency, and the list of tools that were available to it at that moment, because 'why did it not use the right tool' is usually answered by 'it was not offered'. The actions: each tool call as its own execute_tool span with the arguments passed and the result returned, which is the single most important span in the tree when the tool writes to another system. The outcome: the final output, the number of retries, and the error type on any failed span. The cost: token totals and wall-clock duration per run, rolled up as metrics so drift shows on a dashboard rather than in a spot check. Microsoft Foundry's tracing docs describe the same set (inputs and outputs, tool calls and results, token consumption, duration and latency) and add a security note worth taking literally: tracing can capture user inputs, model outputs and tool arguments, so redact personal data and secrets before they reach telemetry and treat trace data with the same access controls and retention as production logs. For an agent touching a CRM or a mailbox that means logging that a field changed and what it changed to, not the customer's words that motivated the change.

Tracing and evaluation are the same data at two moments. A trace is a single run observed; an evaluation is a judgment applied to many runs, either offline against a dataset or online against sampled production traffic. Foundry describes observability as three capabilities that work together: evaluation, monitoring and tracing. Its built-in evaluators include general quality metrics such as coherence and fluency, retrieval metrics such as groundedness and relevance, safety metrics, and agent-specific ones such as tool call accuracy and task completion, and its post-production stage runs continuous evaluation of production traffic at a sampled rate plus scheduled evaluation against test datasets to detect drift. LangSmith's framing is more direct: traces are the record of what your agents did in production, and you use them to debug failures, monitor quality and build the datasets you evaluate against. That last clause is the operating loop. Traces from real runs become the regression set; the regression set gates the next prompt or tool change; the new version ships behind the same tracing; the cycle repeats. Without traces you evaluate against synthetic prompts that never quite match production. Without evaluation you have a wall of traces and no way to say whether this week's agent is better than last week's.

The tooling has settled into three layers that mostly interoperate through OpenTelemetry. Instrumentation libraries capture spans from your code: OpenLLMetry from Traceloop is Apache-2.0 licensed, describes itself as extensions built on top of OpenTelemetry, and instruments OpenAI, Anthropic, Cohere, Google, Mistral, Bedrock and others plus LangChain, LlamaIndex, LangGraph and CrewAI; Arize's OpenInference conventions play a similar role for Phoenix; the OpenAI Agents SDK has tracing on by default and records LLM generations, tool calls, handoffs and guardrails. Backends store and display the traces: Langfuse is MIT licensed, self-hostable, accepts OTLP on its /api/public/otel endpoint and states it aims to be compliant with the OpenTelemetry GenAI conventions; Arize Phoenix is open source under the Elastic License 2.0, built on OpenTelemetry, and bundles tracing, evaluation, datasets and experiments; LangSmith is commercial and hosted but accepts OpenTelemetry traces at its OTLP endpoint from any compatible application. Platform-native options route the same spans into a cloud's monitoring stack: Foundry writes traces to Azure Monitor Application Insights and supports LangChain, LangGraph, the OpenAI Agents SDK and the Microsoft Agent Framework; Microsoft's Agent 365 observability builds on OpenTelemetry through a single Microsoft OpenTelemetry distribution shared with Foundry and Azure Monitor. The practical selection rule is to instrument once against the OpenTelemetry conventions and keep the backend swappable, because the conventions are still in Development and the backend you pick this year may not be the one you want when they stabilize.

No analyst figure for agent observability specifically is cited here, because none was verified for this piece, and the ones that circulate tend to be for adjacent categories relabeled. What can be said from the product pages is structural. The incumbent monitoring vendors (the Datadog, Splunk, New Relic, Dynatrace and Elastic connectors that Azure SRE Agent ships out of the box are a fair proxy for the list) are adding agent traces to platforms that already hold the infrastructure and application telemetry, which is a strong position because an agent's tool call usually lands in a service they already monitor. The cloud AI platforms (Foundry on Azure, and equivalents elsewhere) bundle tracing with evaluation and model hosting so the trace and the eval live next to the deployment. The open-source layer (Langfuse, Phoenix, OpenLLMetry) is where most teams start because it costs nothing to self-host and follows the same conventions. And a security-facing segment is forming around agent identity and activity, which is what the Sentinel Agent 365 connector and Foundry's redaction guidance point at. The pressure that will decide this market is standardization: once the OpenTelemetry GenAI conventions stabilize, the span format stops being a differentiator and the competition moves to what you do with the spans, which is evaluation, alerting and control.

Here is the limit, stated plainly by the people who wrote the security guidance. OWASP's Excessive Agency entry lists logging and monitoring of extension and downstream activity as a mitigation and then says it will not prevent Excessive Agency, but can limit the level of damage caused. The same entry's preventive control is different in kind: utilise human-in-the-loop control to require a human to approve high-impact actions before they are taken. The EU AI Act's Article 12 asks high-risk systems to technically allow for the automatic recording of events over their lifetime so that risk situations can be identified and post-market monitoring performed, which is a record-keeping duty, not an interception one. Observability is retrospective by construction. A span is written when the operation completes; the execute_tool span for an email send closes after the email has gone. For an agent that only reads, that is fine, and it is exactly why the Azure Copilot Observability Agent can run autonomously in preview: it produces issues, not actions, and Microsoft documents no automatic mitigations. For an agent that writes to a CRM, sends a message or files a ticket, you need a second mechanism in front of the tool call. Microsoft's own SRE Agent shows the shape: run modes are separate from permissions, Review mode proposes the action and waits for an administrator to approve or deny, Autonomous mode executes and reports, and the docs recommend starting in Review, observing for two to four weeks, and promoting only the triggers you consistently approve. Notice what the observability data is for in that loop. It is the evidence that earns an action class its promotion. Governance (who may do what, and who must say yes) is the sibling discipline, covered in our guides on AI agent governance and the AI agent audit trail, and the two are complementary: the gate decides, the trace proves.

Take the concrete case of an agent that turns a customer call into actions: update three CRM fields, draft a follow-up email, open a ticket. Full observability gives you an invoke_agent span with the call as the trigger, chat spans showing which fields the model decided to change and why, and an execute_tool span per write with the arguments and the response from Salesforce or HubSpot, Gmail, and Jira. That trace answers 'what did it do' completely and 'why' well enough to debug. It does not answer 'should it have' until after the customer has the email. The design Mindlyft settled on for ASTRA puts a decision in front of every external write and records that decision as part of the same trace: the proposed change with before and after values, the policy result (auto, gated or denied), the approver and timestamp when gated, and then the tool call and its result. The reviewer sees one batched review per call in the tools they already use, and the audit record and the trace are the same object rather than two systems that have to be reconciled. Observability on its own would have told us, three months later, exactly which follow-up email should not have been sent. That is useful. Having the trace show an approval step before the send is the part that keeps it from being the only useful thing. If you want to see it on one of your own workflows, the first one is free, then $5,995 a month at mindlyft.in.