A Practical Guide to Monitoring and Controlling Agentic Applications

In an illustrative example, an autonomous trading system has an indexing error that leaves a retrieval step with incomplete data. The trader agent answers from that partial context. Every request still completes with normal latency and no logged error, so application performance monitoring (APM) reports a healthy service while responses lose faithfulness to their source data.

APM was built for predictable software, where each request follows a known code path, but agents decide at run time which agent to hand off to, which tool to call and what to keep in memory.

End-to-end tracing comes down to four practices, which the steps below put in order:

1. Instrument every agent with the GenAI semantic conventions covered in step 2, or with a framework SDK.
2. Emit a span for each agent invocation, handoff, tool call, retrieval and large language model (LLM) call, tagged with the agent and conversation it belongs to.
3. View each run as a hierarchy from application down to span instead of a flat span list.
4. Attach evaluations such as faithfulness to responses, so quality failures raise alerts the way errors do.

You are moving agentic systems into production for multi-step use cases that predefined code paths cannot support. Debugging those systems starts with a clear definition of what separates an agent from a workflow.

How Agents Differ From Workflows

Anthropic’s “Building Effective Agents” defines an agentic system by distinguishing workflows from agents:

“Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.” [1]

Where Multi-Agent Systems Fail in Production

A multi-agent system adds failure points that a single agent does not have. Each handoff between agents, each tool selected at run time and each piece of context passed to a sub-agent is another point where a run can fail without raising an error. Failures can occur in seemingly simple ways, yet remain difficult to diagnose due to the opaque and dynamic nature of agentic behavior. In a study presented at NeurIPS 2025, Cemri et al. annotated 1,642 traces across 7 multi-agent frameworks and found failure rates from 41% to 86.7% [2].

Common Failure Modes in Production AI Agent Systems:

• Data Access and Retrieval Issues:
  • Retrieval errors: datastore outages or misconfigurations
  • Incorrect results: indexing errors or faulty retrieval logic
  • Incomplete data coverage: documents or records missing from the retrieval index, leaving questions the agent cannot answer from its source data
• Prompting and Contextual Failures:
  • Context errors: insufficient or inaccurate context provided to the model
  • Prompt construction: misleading or suboptimal prompt construction affecting performance
• Model-Level Errors:
  • Hallucinations: fabricated or factually incorrect claims that the LLM generates without support in the provided context or source data
  • Unsafe content: generation of offensive, inappropriate, or brand-unsafe content
• Security and Privacy Risks:
  • Data leakage: sensitive or private enterprise data can leak through prompts, tool returns, file reads or outputs
  • Jailbreaks and prompt injection: successful jailbreaks or prompt injection attacks
• Tooling and Execution Failures:
  • Tool invocation failures: agents failing to invoke required tools due to access issues
  • Missing tool input: inability to act due to missing or incomplete tool input data

Why APM Traces Miss Agent Failures

APM views assume a request follows one call stack on a known code path. In a multi-agent run, an orchestrator hands off to other agents, which may loop, retry and select tools at run time, so the same input can take a different path next time.

A flame graph, a timing view that stacks nested calls, shows timing and nesting only. It omits which agent decided to hand off, why a tool was chosen, and what state the agent carried in memory. A span list shows only that calls happened, so a confident but unfaithful answer looks like a correct one. An agent can return HTTP 200 and still fail by picking the wrong tool, handing stale context to a sub-agent or burning tokens in a retry loop [3].

Debugging requires spans tied to agent and conversation identity, handoff and tool-call inputs and outputs, and evaluations on responses.

Choose the Metrics That Expose Agent Failures

Given the wide range of failure modes in agentic systems, you need metrics across safety, output quality and operational telemetry to see how AI-driven applications behave in production. Latency and error rates alone cannot flag an unfaithful or unsafe response, so the list below pairs operational telemetry with safety and output-quality checks.

Below are a few key metrics to consider when instrumenting agent-based applications:

• Safety and Trustworthiness
  • Multi-Dimensional Safety: Detection of outputs that are illegal, hateful, harassing, racist, sexist, violent, sexual, harmful, unethical, or indicative of jailbreaking attempts
  • Toxicity: Measurement of harmful or aggressive language
  • Profanity: Detection of explicit or inappropriate language
  • Sentiment: Analysis of emotional tone, with thresholds for acceptable response ranges
  • Banned Keyword Detection: Identification of restricted terms or phrases
  • Personally Identifiable Information (PII): Monitoring for leakage of sensitive data
• Output Quality
  • Faithfulness: Ensuring responses remain grounded in the provided data or source context
  • Conciseness: Assessing whether outputs are unnecessarily verbose or meandering
  • Coherence: Evaluating logical flow and structural consistency
  • Answer Relevance: Measuring alignment with the original prompt or user query
• Operational Telemetry
  • Latency: Time per span and per agent
  • Token Usage: Tokens consumed per LLM call and per conversation
  • Cost: Spend per application per day
  • Error Rates: Failed tool calls and LLM calls

Tracking these metrics lets teams detect issues in real time and keep improving agent performance and user trust across critical workflows.

Turn Monitoring Metrics Into a Real-Time Control Plane

As applications shift from deterministic to probabilistic behavior, the same input can produce a different response on the next run, so reviewing logs after the fact finds a harmful or unfaithful response only once it has reached a user or downstream system. The very same metrics used for post-hoc analysis of agent logs can now drive enforcement that allows, blocks or redacts, depending on the policy and use case.

Running those metrics inline on the request and response path creates a real-time control plane, a system that observes and governs agent behavior. With guardrails in that path, you can check the request before the model is invoked and check the response before it reaches the user or a downstream system. Each check then allows, blocks or redacts as the policy and use case require, which minimizes risk and maintains trust.

For example, the safety guidelines below, from OpenAI’s “A practical guide to building agents” [4], recommend implementing guardrails across multiple dimensions.

Trace and Control Agents With Fiddler

The Fiddler AI Observability and Security platform applies this approach to production agents on standardized telemetry.

• Continuous Monitoring: Fiddler Agentic Observability organizes traces into the agentic hierarchy (application, session, agent, trace, span), so an application alert leads to its span.
• Reliable Evaluation: Fiddler evaluates 100+ metrics. Batteries-included Fiddler Centor Models score prompts and responses in-environment without external LLM calls, and can evaluate 100% of them by default.
• Enforceable Policy: Fiddler Guardrails enable it through inline enforcement on the request and response path of an LLM or Model Context Protocol (MCP) gateway, with under 80ms response time. Checks allow, block or redact, depending on policy.

How to Trace and Debug a Multi-Agent System

1. Set Up Guardrails

Depending on the criticality of business priorities, such as brand safety, data privacy, or response accuracy, you select guardrails that evaluate and score relevant inputs and outputs within the system. When a score exceeds its threshold, the guardrail allows, blocks or redacts, depending on the policy and use case.

The figure below, from OpenAI’s “A practical guide to building agents” [4], shows how to embed such safeguards directly into the application workflow.

2. Instrument Agents and Gather Traces

Capture inputs, outputs and critical metadata, such as latency, model version and agent ID, at span-level granularity. This is the foundation of effective monitoring of agent behavior.

OpenTelemetry (OTel) standardizes how this telemetry, including LLM and tool calls, is structured as traces and spans [5], and the OpenTelemetry GenAI semantic conventions define attributes that identify the agent (gen_ai.agent.id) [6] and the session or conversation (gen_ai.conversation.id). Application-level views are an aggregation built on that telemetry, not something OTel defines.

Emit a span for each agent invocation, handoff, tool call, retrieval step and LLM call, and record token usage on LLM spans. Set both attributes on every span, so you can reassemble a handoff between agents and group a runaway loop by conversation.

Depending on your deployment architecture, agent logs can be ingested from various sources. For example, logs from AWS Bedrock Agents may reside in a log store like Amazon S3, while systems like LangGraph provide direct access to structured telemetry from agent orchestration pipelines.

Structured logging of this kind supports real-time debugging, quality assurance and risk management in the agentic applications you run in production.

3. Monitor App-Level Metrics

Once logs are collected and processed, define a focused set of application-level metrics to track. This avoids the overhead of monitoring dozens of span-level metrics for every agent operation, which becomes unmanageable as the number of deployed agents grows.

Prioritize a few key performance and risk indicators, then create streamlined dashboards and set targeted alerts on them. Set alerts both on thresholds and on sustained shifts, such as a drop in faithfulness or a rise in daily token cost after a prompt, model or retrieval change. This keeps you ahead of emerging issues without drowning in noise.

4. Drill Down to the Failing Span

When an alert is triggered, the complexity of agentic systems can make root cause analysis both difficult and time-consuming. With numerous moving parts, pinpointing the source of failure requires careful investigation:

• Is a single agent causing issues within a multi-agent workflow?
• Is the problem isolated to one user or a specific interaction?
• Is a particular span consistently underperforming or failing?
  • Are LLM responses breaking down across certain prompts?
  • Have vector retrieval latencies spiked for a specific span?

Root-cause analysis follows a systematic drill-down through the agentic hierarchy, which has five levels: application, session, agent, trace and span. You work down the levels in this order:

1. Application: The alert fires on an application-level metric.
2. Session: Narrow to the affected user session.
3. Agent: Isolate the agent responsible.
4. Trace: Follow the trace of that agent’s run.
5. Span: Reach the exact span (for example, an LLM call or vector retrieval) where the failure occurred.

This traceability depends on logs enriched with high-quality, structured metadata, which enables fast and efficient debugging.

5. Resolve Issues and Prevent Regressions

Identifying the root cause is only the first step; resolving the issue requires targeted action. Depending on the failure mode, this may involve updating the prompt context, switching to a different LLM, refreshing vector data stores, or refining retrieval logic.

Once the fix is in place, turn the failing trace into a test case so the same input is checked before every future release. Then connect the evaluation threshold you set before deployment to the matching production alert and enforcement rule, so a recurrence trips the same check. You can also fine-tune guardrail thresholds to minimize false positives or add new guardrails that catch similar issues earlier.

Keep Oversight Ahead of Agent Autonomy

As agents gain capability and complexity, tracing across the agentic hierarchy, application-level metrics and real-time guardrails keep them reliable and aligned with business goals. Observability must precede autonomy, so agents should never receive more autonomy than the organization can observe and oversee.

Request a demo to review how agent tracing, evaluation and inline enforcement would fit your agent architecture and deployment environment.

References

[1] E. Schluntz and B. Zhang, “Building Effective Agents,” Anthropic, Dec. 19, 2024. Accessed: Oct. 19, 2026. [Online]. Available: https://www.anthropic.com/research/building-effective-agents

[2] M. Cemri et al., “Why Do Multi-Agent LLM Systems Fail?,” in NeurIPS 2025 Datasets and Benchmarks Track, 2025. Accessed: Oct. 19, 2026. [Online]. Available: https://proceedings.neurips.cc/paper_files/paper/2025/hash/b1041e52d3be19f0a9bc491657488e4a-Abstract-Datasets_and_Benchmarks_Track.html

[3] S.-J. Wiggers, “Cloudflare Adds Agent Tracing, with Truncation Limits and Uneven Payload Defaults,” InfoQ, Aug. 15, 2026. Accessed: Oct. 19, 2026. [Online]. Available: https://www.infoq.com/news/2026/08/cloudflare-agent-tracing/

[4] OpenAI, “A practical guide to building agents,” OpenAI, Apr. 2025. Accessed: Oct. 19, 2026. [Online]. Available: https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf

[5] OpenTelemetry, “GenAI spans semantic conventions (gen-ai-spans.md),” OpenTelemetry semantic-conventions-genai repository, GitHub, main branch, Development status. Accessed: Oct. 19, 2026. [Online]. Available: https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-spans.md

[6] OpenTelemetry, “GenAI agent spans semantic conventions (gen-ai-agent-spans.md),” OpenTelemetry semantic-conventions-genai repository, GitHub, main branch, Development status. Accessed: Oct. 19, 2026. [Online]. Available: https://github.com/open-telemetry/semantic-conventions-genai/blob/main/docs/gen-ai/gen-ai-agent-spans.md

[7] G. Liu and S. Solomon, “AI Agent Observability - Evolving Standards and Best Practices,” OpenTelemetry blog, Mar. 6, 2025. Accessed: Oct. 19, 2026. [Online]. Available: https://opentelemetry.io/blog/2025/ai-agent-observability/