The problem: why agents fail silently
An engineering team deploys a claims classification agent into production. For the first few weeks, everything looks fine: the system returns 200 OK on every call, latency is within SLOs, token consumption is stable. Infrastructure dashboards are all green.
Three weeks later, the operations team spots an anomaly: a growing share of claims is being routed to the wrong categories. They start investigating. No errors in the logs. No exceptions. No timeouts. The agent has been failing semantically for weeks, and not a single monitoring tool caught it.
This scenario is not hypothetical. It is the most common failure pattern in production AI agent systems: the technical system works fine; the behaviour is wrong. And it is precisely the problem that traditional observability was never designed to detect.
The difference between an observable agent system and one flying blind is not trivial: in sectors like Healthcare or Insurance, an agent that hallucinates on edge cases or enters reasoning loops can directly affect critical business decisions. The question is not whether you need agentic observability. The question is when you put it in place, before the first production incident, or after.
Why traditional observability falls short for agents
Modern observability, structured logs, infrastructure metrics, distributed traces, was built for deterministic systems: microservices that receive a request, run predictable logic, and return a response. In that model, failures manifest as technical errors: an HTTP 5xx code, an exception, a timeout, a latency spike.
AI agents break that model across three fundamental dimensions:
- State and memory. A microservice is, by design, stateless between requests. An agent maintains state: short-term memory within a session, long-term memory across sessions, and the context of the workflow in progress. A log entry capturing a single call does not capture the accumulated state that shaped that decision.
- Non-deterministic reasoning. The same input can produce different outputs depending on model temperature, the conversation context, and the documents retrieved by the RAG pipeline. Debugging by exact input reproduction does not work when the system is inherently non-deterministic.
- Semantic errors, not technical ones. An agent can execute all tool calls correctly, receive valid responses from the LLM API, and return a response that is technically well-formed but semantically wrong: a misclassification, an inappropriate recommendation, an answer that does not actually address the user’s real question.
A 200 OK log entry on a call to the OpenAI or Bedrock API only confirms the call completed. It says nothing about whether the model made the right decision, whether the reasoning was coherent, whether the output was relevant to the context, or whether the agent is gradually degrading.
The practical consequence: debugging an agent without semantic traceability is, in production, practically impossible. You can know that something went wrong. You cannot know why, or when it started going wrong.
The 5 pillars of agentic observability
Agentic observability does not replace infrastructure observability, it extends it with a semantic layer specific to agent behaviour. These are the five pillars that define a complete implementation:
1. Semantic traceability of reasoning
The goal is to capture the agent’s “thinking” at each decision point: what information it evaluated, what alternatives it considered, why it selected action X over action Y. This goes beyond logging the prompt and response, it requires instrumenting the intermediate reasoning steps, especially in ReAct or Chain-of-Thought architectures.
In practice, this means capturing dedicated spans for each reasoning step, with full context: retrieved documents, evaluated tool calls, chain-of-thought tokens. Without this layer, a failure in decision logic is invisible.
2. Tool call traceability
Agents orchestrate tools: external APIs, databases, search engines, other agents. Every tool invocation must be a traceable span containing: tool name, input parameters, response received, latency, and outcome (success, error, timeout). This traceability makes it possible to determine whether a behavioural failure originates in a specific tool returning incorrect or degraded data.
3. Agent state monitoring
The agent’s state, session memory, workflow variables, current checkpoint, must be observable in real time. This includes: active context size (to detect silent truncations), workflow state (to detect loops or deadlocks), and the evolution of long-term memory (to detect cross-session memory contamination).
4. Semantic quality metrics
Quality metrics are the most distinctive pillar relative to traditional observability. They do not measure whether the system is running, they measure whether the system is doing the right thing. Key metrics include:
- Response relevance: is the output pertinent to the query received?
- Coherence: is the response internally consistent and does it avoid contradicting earlier turns?
- Completeness: does the response cover all aspects required by the task?
- Hallucination rate: does the agent generate information not grounded in the available context?
- Task completion rate: does the agent successfully complete the tasks it was designed for?
These metrics are calculated through automated evaluation (LLM-as-judge), domain-specific heuristics, or human-in-the-loop validation. They must be monitored as time series to detect gradual degradation.
5. Anomalous behaviour alerts
Agentic alerts must go beyond latency and error rate thresholds. Patterns that require dedicated alerts include:
- Reasoning loops: the agent invokes the same tools repeatedly without making progress
- Unexpected escalations: the agent escalates to a human at an anomalous rate relative to baseline
- Out-of-range token consumption: an early indicator of reasoning loops or context stuffing
- Semantic quality degradation: a statistically significant drop in quality metrics
- Anomalous decision distribution: the agent makes a particular type of decision with unusually high or low frequency
The tooling ecosystem in 2026
The observability ecosystem for AI systems has matured significantly. Here are the relevant tools in 2026, organised by function:
Langfuse
Langfuse is the reference open-source platform for LLM observability. It provides full conversation and chain traces, prompt versioning and management, quality evaluation (manual and automated scoring), and usage and cost dashboards. Its architecture supports self-hosted deployment, a critical requirement for sectors with data sovereignty constraints such as Healthcare or Insurance. Native integrations with the leading agent frameworks (LangChain, LlamaIndex, OpenAI SDK) are available out of the box or via SDK.
OpenTelemetry for LLMs
The OTEL standard’s extension with GenAI semantic conventions defines a common data model for instrumenting LLM calls: spans with standardised attributes for model name, input/output tokens, finish reason, and tool calls. This standardisation is key for teams already running OTEL in their infrastructure stack who want to extend the same observability platform (Grafana, Datadog, Honeycomb) to the semantic layer.
Arize AI / Phoenix
Addresses model evaluation and production monitoring. Phoenix, the open-source edition, stands out for its automated evaluation capabilities, semantic drift detection, and embedding analysis. It is particularly well suited for RAG systems, where monitoring retrieval quality and document relevance is essential.
Helicone
Acts as an observability proxy for LLM APIs. Its position as an intermediary allows it to capture all calls without modifying application code, which lowers the barrier to adoption. It provides usage analytics, response caching, and rate limiting, along with basic traceability.
AWS Bedrock / Azure AI Foundry
Offer native observability for teams operating within closed cloud ecosystems. Invocation metrics, model input/output logs, and integrations with CloudWatch or Azure Monitor reduce adoption friction, though with less semantic granularity than dedicated platforms.
Tool selection depends on three factors: call volume (which determines instrumentation cost), data sovereignty requirements (self-hosted vs. SaaS), and the level of semantic granularity the use case demands.
How to implement it: a step-by-step guide
Implementing agentic observability does not require rewriting your system. It can be done incrementally, adding layers of visibility without disrupting the agent’s operation.
Step 1: Instrument LLM calls with OpenTelemetry spans.
The starting point is to instrument each model call as an OTEL span with the attributes defined in the GenAI semantic conventions: gen_ai.system, gen_ai.request.model, gen_ai.usage.input_tokens, gen_ai.usage.output_tokens, gen_ai.finish_reason. Most major frameworks (LangChain, LlamaIndex) have OTEL integrations available. For custom code, the OTEL SDK allows any call to be instrumented in a few lines. This is the minimum viable implementation: once LLM calls are traceable spans, you have the foundation on which to build everything else.
Step 2: Capture agent state at each decision point.
Define checkpoints at the critical moments of the agent workflow: before and after each tool call, at each branching point in the reasoning, at each handoff between agents. At each checkpoint, persist the relevant state: active context, results from the last tools invoked, workflow state variable. Langfuse allows these states to be attached to traces as structured metadata.
Step 3: Define the business metrics that measure agent success.
This step is critical and frequently skipped. Technical metrics (latency, tokens, error rate) do not measure whether the agent is fulfilling its function. For each use case, define specific business metrics: for a classification agent, the correct classification rate; for a customer service agent, the first-contact resolution rate; for a document analysis agent, entity extraction precision. These are the metrics that belong on executive dashboards and that should trigger degradation alerts.
Step 4: Build agentic behaviour dashboards.
An agent dashboard is different from an infrastructure dashboard. The relevant views include: decision distribution by category (to detect anomalous distributions), semantic quality over time (to detect gradual degradation), tool call success rate by tool (to detect degradation in data sources), and session length distribution (to detect loops). Grafana with a data source from Langfuse or Prometheus, or the native interfaces of Langfuse and Arize, are the most common options.
Step 5: Implement continuous automated evaluation.
Continuous evaluation closes the loop: you are not just observing, you are systematically measuring quality. The options are: LLM-as-judge (using one LLM to evaluate another’s responses, with criteria specific to the use case), domain heuristics (deterministic rules for cases where correctness is verifiable), and human evaluation on a sample (to keep automated evaluators calibrated). Langfuse and Arize Phoenix provide native infrastructure for this pipeline.
Agentic observability and regulatory compliance
(EU AI Act)
The EU AI Act, applicable since August 2024 and fully in effect in 2026, establishes specific transparency and traceability requirements for high-risk AI systems (Annex III). The sectors in which Cloudappi operates, healthcare, insurance, critical infrastructure, fall squarely within this category.
Articles 13 and 14 of the EU AI Act require high-risk AI systems to provide: transparency about their operation and capabilities, traceability of decisions that affect natural persons, and the capacity for human oversight of system behaviour. Agentic observability is not merely a sound engineering practice — it is the technical implementation of these regulatory requirements.
A medical classification agent or insurance risk assessment agent operating without semantic traceability cannot demonstrate, in the event of an audit, that its decisions were consistent, free of bias, and in line with the established criteria. The reasoning and tool call traceability that agentic observability provides is precisely the evidence regulators require.
For teams in regulated sectors, agentic observability carries an additional benefit: it enables the construction of the decision log that certain sector-specific regulatory frameworks (Solvency II, HIPAA, financial supervision directives) may require for automated decision-making systems.
Cloudappi: how we build it in real projects
At Cloudappi we have designed and deployed production AI agent systems for clients in the Insurance, Healthcare, and Telco sectors. Agentic observability is part of our reference architecture from the design phase, not an afterthought.
In a subscription process automation project for an insurer, implementing semantic traceability with Langfuse and OpenTelemetry allowed us to detect, within the first week of production operation, an incorrect reasoning pattern on edge cases involving multi-product policies. The error was invisible in the infrastructure logs: calls were completing with 200 OK, response times were normal. It was the monitoring of decision distribution, one of the business metrics we had defined in step 3, that triggered the alert.
In a clinical document analysis agent project, tool call traceability was decisive in identifying that the degradation in extraction quality originated in changes to the format of source documents, not in the model itself. Without tool-level observability, the investigation would have pointed to the model first and consumed weeks of analysis.
Our reference architecture for agentic observability includes: Langfuse as the central platform for traces and evaluation, OpenTelemetry with GenAI conventions for the instrumentation layer, automated LLM-as-judge evaluation calibrated with domain-specific criteria, and behaviour alerts integrated into the client’s on-call systems.
Conclusion
Production AI agent systems fail in ways that traditional observability does not detect. The errors are semantic, not technical. Infrastructure logs report that everything is working; users or auditors discover that the behaviour is wrong. The gap between what the technical system reports and what the system actually does is the primary risk of running agents in production without agentic observability.
The five pillars, semantic reasoning traceability, tool call traceability, state monitoring, semantic quality metrics, and anomalous behaviour alerts, provide the visibility needed to operate AI agents with the same operational discipline applied to critical software systems.
The tooling ecosystem is mature. Implementation is incremental. And in regulated sectors, agentic observability is also a compliance requirement.
The question is no longer whether to implement agentic observability. It is when: before the first production incident, or after
Are you building AI agents in production without an observability strategy?
At Cloudappi we help you design and implement the agentic observability layer your system needs — from instrumentation to behaviour dashboards and semantic degradation alerts.
