AI Agents in Production: Why Observability Matters More Than the Model

Production AI agents need tracing, evaluation and controlled tool calls. Explore architecture, operational metrics, privacy, security and OpenTelemetry examples.

November 9, 2026

Model quality alone does not make an agent reliable in production.
Traces explain execution; evaluation verifies business outcomes.
Track completed tasks, tool failures, P95 latency and cost per success.
Observability must protect sensitive data and never replace authorization.
Safe releases rely on approval gates, regression tests and fallback paths.

A strong model is not a reliable agent by itself

An AI agent handles a test request convincingly. A few hours later, the same workflow encounters an unreliable API, stale master data or missing permissions. Its answer still sounds plausible, but the underlying task has not been completed. The language model may not be the cause of the failure. The system around it often is.

In production, evaluating individual model responses is not enough. Teams need to know which data an agent read, which tools it called, what happened in downstream systems and whether the business outcome was correct. Observability provides that view.

Traces connect the steps of one execution. Metrics reveal patterns across many runs, and logs capture relevant technical events. Domain evaluation and versioning add evidence about quality. Observability makes failures diagnosable; it does not replace technical controls that prevent them.

Why agent observability matters more in 2026

In November 2026, Google announced general availability of observability features for BigQuery Data Agents, covering execution traces, latency, usage and cost information. The shift is important: operating agents requires as much attention as developing them.

Tracing alone does not establish governance or answer quality. A successful HTTP response may contain an incorrect recommendation. A fully recorded run may still perform an unauthorized action. Production teams need evaluation, explicit tool boundaries and accountable owners.

Example: an agent handling industrial service tickets

Consider an equipment manufacturer triaging incoming service tickets. An agent reads the issue, retrieves product and contract records from an ERP system, searches technical manuals and proposes a response for a service specialist. It escalates uncertain cases. Customer communications and writes to operational systems require separate approval.

The pilot performs well. In production, one ticket lacks a serial number, another retrieves an outdated manual, and a third encounters a tool timeout. The model can produce well-written output in all three cases without delivering a reliable answer.

A useful trace identifies the document version, each tool invocation, latency, retries and authorization outcomes. Domain evaluation then determines whether the ticket was actually resolved. This is an illustrative architecture, not a claim about a Valanor client engagement.

Architecture: explicit boundaries between model, data and actions

A workflow API receives the request and assigns an ID. Orchestration connects retrieval, model calls and tools. A server-side policy layer checks identity, tenant, permissions and target resources. Sensitive actions pass through approval, while idempotency keys protect writes against accidental repetition.

Every important step creates a span: the workflow, document retrieval, model inference and tool execution. A shared trace ID connects them. An audit log separately records the change confirmed by the target system. The trace explains execution; a domain-level check verifies the outcome.

This does not automatically require microservices. A single well-instrumented application with explicit tool contracts may be the right architecture. Separating model-generated suggestions from authorized actions matters more than the number of components.

The signals a production agent should expose

Layer	Signal or metric	Question it answers
Workflow	Task completion and escalation rate	Did the agent actually resolve the business task?
Model	Model version, tokens, inference latency	How do model and prompt affect quality, time and cost?
Retrieval and data	Source version, retrieval quality, empty results	Was the failure caused by missing or outdated data?
Tool calls	Tool, status, timeout, retry, permission decision	Did an integration fail or was a restricted call blocked?
Actions	Approval state, idempotency key, outcome	Was a write action authorized and executed exactly once?
Quality	Groundedness, verified outcomes, human corrections	Was the outcome correct and defensible?
Operations	P95 latency, error rate, capacity	Where are bottlenecks, and when should the team intervene?
Cost	Cost per successfully completed task	What does a usable outcome cost, including retries?

Tracing explains execution; evaluation assesses correctness

A trace can tell you why a workflow slowed down: search returned no results, an API timed out, or the model attempted another call. It cannot establish whether the response was factually right. Technical success and business success are different measures.

Evaluation requires representative cases and reference outcomes. In the service-ticket example, that means correct product identification, relevant documentation, permitted tool actions, appropriate escalation and sound recommendations. Automated graders can support expert review, not replace deterministic controls for high-impact actions.

Some workflows have delayed ground truth. A service diagnosis might be confirmed days later. Immediate proxy metrics should therefore be distinguished from verified outcomes recorded after the fact.

Instrument tool calls with OpenTelemetry

This TypeScript snippet instruments an already-authorized tool invocation. It does not implement authentication or approvals. Authorization must happen server-side, outside the model's control. Production systems also need context propagation, sampling, an exporter, idempotency and careful error handling. Sensitive payloads are deliberately not recorded.

TypeScript

import {trace, SpanStatusCode} from '@opentelemetry/api'
const tracer = trace.getTracer('service-agent')

export async function callTool<T>(
  name: string,
  requestId: string,
  executeAuthorizedAction: () => Promise<T>
): Promise<T> {
  return tracer.startActiveSpan('agent.tool', async (span) => {
    span.setAttribute('agent.tool.name', name)
    span.setAttribute('agent.request_id', requestId)

    try {
      // The server must enforce authorization and approvals
      // before the callback executes.
      const result = await executeAuthorizedAction()
      span.setAttribute('agent.tool.status', 'success')
      return result
    } catch (error) {
      span.setStatus({code: SpanStatusCode.ERROR})
      span.setAttribute('agent.tool.status', 'error')
      throw error
    } finally {
      // Never put prompts, credentials or customer data in traces.
      span.end()
    }
  })
}

Five metrics worth tracking first

Task completion rate measures verified outcomes, not how many replies were generated. Separate tasks completed autonomously from escalations and later corrections. A high volume of answers accompanied by substantial rework may deliver little value.

Tool failure rate distinguishes timeouts, permission failures, validation errors and empty retrieval results. Those categories help separate model issues from data and integration failures.

P95 workflow latency measures the time to a useful outcome, not just inference speed. Retrieval, external APIs, retries and approvals contribute to the real user experience.

Cost per successful task includes model usage, infrastructure, third-party services, retries and human rework. A cheap model call can become an expensive operational workflow.

Escalation and correction rates reveal whether an agent recognizes uncertainty and how often people need to fix its work. These signals help establish safe limits for automation.

Evaluate before deployment and keep evaluating afterwards

Offline evaluations should cover normal requests, missing inputs, conflicting sources, stale documents, broken tools, duplicate requests and malicious instructions. Results must be linked to exact model, prompt, tool and dataset versions. A good average score must not conceal an unacceptable critical failure.

Production conditions will change: users phrase requests differently, documents are updated and APIs behave unexpectedly. Privacy-safe samples of real cases should feed regression tests. Release gates, rollback procedures and manual fallback paths keep operations under control when performance deteriorates.

Example release gates for an agent

This YAML is an architectural example, not a runnable configuration for a particular framework. All thresholds are illustrative. Set operational limits from a measured baseline and the real consequences of errors. High-impact writes still require technical restrictions and human approval where appropriate.

YAML

# Example thresholds, not universal production targets
workflow: service-ticket-agent
dataset: service-tickets-v3
checks:
  - metric: required_field_accuracy
    minimum: 0.98
  - metric: unauthorized_write_actions
    maximum: 0
  - metric: p95_workflow_latency_ms
    maximum: 10000
  - metric: escalation_on_uncertainty
    required: true
release:
  human_approval: true
  rollback_enabled: true

Privacy: traces must not become a second customer database

Agents often process CRM entries, emails, technical documents and personal information. Sending complete prompts and tool outputs into an external observability product creates another sensitive-data repository with its own access and retention risks.

Default to technical metadata: trace ID, component version, tool name, status, duration and aggregated usage. Recording content requires a specific purpose, an appropriate legal basis and safeguards. Pseudonymized data may still be personal data.

Redact before export, restrict access by role, encrypt transfers, limit retention and control debugging sessions. Exception messages and tool parameters may expose sensitive values. Check exactly what the deployed SDK version captures automatically.

Security: observing an attack does not prevent it

Prompt injection can arrive through documents, websites or tool responses. A malicious attachment might instruct the agent to export customer records. Traces may help reconstruct the incident, but the trace itself cannot stop a write or data leak.

Treat external content as data rather than trusted instructions. Enforce least privilege, server-side authorization, tool allowlists, resource checks and approvals for consequential actions. An LLM should not be the sole authority deciding which writes are permitted.

Retries deserve equal attention. After a timeout, the caller may not know whether the target system completed an action. Without idempotency, retrying can create duplicate tickets, orders or other side effects. Better prompting does not resolve this failure mode.

OpenTelemetry, Langfuse or platform-native tracing?

OpenTelemetry provides a vendor-neutral foundation for traces and metrics, especially when backend observability already exists. Its GenAI semantic conventions define shared vocabulary for model and tool spans; adoption and stability depend on the versions being used.

Langfuse adds LLM-specific tracing, evaluation and prompt-versioning workflows. It can help engineers and domain experts inspect individual agent runs. Hosting, data transfer and access controls still require explicit decisions.

The OpenAI Agents SDK and Google Cloud also expose platform-native tracing and observability features. These can simplify integration at the cost of stronger coupling to a vendor stack. Choose based on existing infrastructure, data governance and operational needs rather than a feature checklist.

Moving from a pilot to a controlled production workflow

Begin with one bounded task and a verifiable definition of success. Specify data sources, tool contracts, permissions, telemetry and error classes. Test empty search responses, timeouts, duplicate calls, invalid records and unauthorized requests.

For higher-risk workflows, start with read-only operations or human-approved writes. Expand autonomy only when production telemetry and evaluations support that decision. Controlled rollout, alerts, regression tests and fallback procedures keep the process usable under failure.

At Valanor, we approach this as Data & AI Engineering: integrating data flows, agent architectures and software into operational workflows.

For the broader ML lifecycle, see What is MLOps?.

Conclusion: reliability is a property of the complete system

A more capable model may improve individual answers. It does not fix broken APIs, missing permissions or undefined approval paths. Business value depends on whether agents finish tasks reliably, safely and at a defensible cost.

Observability gives teams the evidence to understand behavior. Combined with evaluation, security and clear accountability, it turns a promising demonstration into a controlled operational capability. Not every agent needs a large monitoring platform, but every production agent needs traceable execution and a defined response to failure.

Frequently asked questions about production AI agents

How is observability different from monitoring?

Monitoring detects predefined deviations. Observability helps investigate unexpected failures using traces, metrics and events. Agent systems also need model, prompt, dataset and tool version information.

What should an agent trace capture?

Primarily technical metadata such as tool name, status, duration, versions and aggregate cost. Prompts, customer documents and personal data should never be captured by default without careful review.

Is Langfuse sufficient for production monitoring?

Langfuse covers important LLM traces and evaluation. Depending on the architecture, teams also need API and infrastructure monitoring, server-side access controls, alerting and domain-level quality checks.

How should agent quality be measured?

Measure verified task completion, valid actions, escalation and correction rates, latency and cost per successful outcome. Offline evaluation and representative production cases serve different purposes.

Does observability prevent prompt injection?

No. It aids investigation. Prevention requires least-privilege permissions, server-side policy enforcement, safe tool contracts and approval gates for sensitive operations.

When does a full observability stack make sense?

The need increases with workflow criticality, external dependencies and write permissions. Smaller pilots can begin with basic instrumentation, provided failures remain diagnosable.

Technical references

OpenTelemetry: GenAI semantic conventions

OpenAI Agents SDK: Tracing

Langfuse: Observability and evaluation docs

OWASP: LLM Top 10

Google Cloud: Data analytics updates

Production AI Engineering

Move from an agent prototype to a controlled system

We develop AI agents with explicit tool boundaries, traceable data flows, evaluation and observability. We engineer the architecture, approval gates and operational controls needed to integrate AI into real business workflows.

Discuss your AI use case

Aleksandar Basara

Managing Director

aleks@valanor.co

+49 (0) 711 16 44 6 83

Lindenspürstrasse 22, 70176 Stuttgart