AI observability for agentic workflows is becoming an operational control

At a glance

What this is: Booking.com’s use case shows AI observability becoming an operational control for both agentic workflows and traditional ML, with end-to-end traces and prediction logs used to explain runtime behaviour.

Why it matters: This matters because AI teams need evidence, not inference, when they investigate regressions, privacy handling, and agent decisions across production systems.

Context

AI observability is the discipline of turning runtime behaviour into evidence that teams can inspect, query, and act on. In this article, the governance gap is that traditional dashboards can show latency or error spikes, but they often cannot explain what a model or agent actually did to produce an outcome.

That gap widens when a single request becomes a chain of prompts, retrieval steps, tool calls, guardrails, and fallback decisions. For IAM, NHI, and AI governance practitioners, the important intersection is that agentic workflows increasingly behave like governed software actors, so traceability, data handling, and accountability become part of the control set.

Booking.com’s experience is typical of organisations scaling multiple AI systems at once rather than relying on one flagship model. The operational challenge is no longer whether to monitor AI, but how to standardise the telemetry needed to make it explainable and defensible.

Key questions

Q: How should teams govern agentic AI when the model can act across multiple tools and services?

A: Teams should govern the full execution path, not just the model endpoint. The practical control is a replayable event history that records tool calls, context updates, and decisions in order, so security and compliance can reconstruct what happened. Without that trace, incident response and audit become guesswork.

Q: Why do agentic workflows require stronger observability than traditional ML models?

A: Agentic systems make decisions through chains of actions, so failure can come from any step in the sequence. Traditional model metrics may show that something is slow or inaccurate, but only traces can explain where the chain broke. That makes observability a governance control for complex runtime behaviour.

Q: What signs show that AI observability is not capturing the right evidence?

A: Common signs include unexplained regressions, inconsistent outputs across cohorts, repeated debugging without root cause, and alerts that show a problem but not the workflow step that caused it. If teams cannot move from symptom to explanation quickly, the observability model is too shallow for production AI.

Q: How should security teams govern AI observability in enterprise environments?

A: Security teams should treat AI observability as a governance control, not a monitoring add-on. Focus on identity attribution, data lineage, output quality, and policy evidence so every meaningful AI action can be traced back to an owner, a model version, and an access decision. That makes investigations, reviews, and accountability possible.

Technical breakdown

Why agentic workflows need end-to-end traceability

Agentic workflows are multi-step systems, not single model calls. A user request can trigger prompt construction, retrieval, tool invocation, policy checks, fallback logic, and final response assembly. Traditional monitoring can surface symptoms such as latency, cost, or failure rates, but it usually cannot reconstruct the decision path that produced a specific output. End-to-end tracing closes that gap by preserving the sequence and context of runtime actions. In practice, this is the difference between observing that an agent answered badly and understanding which step in the workflow caused the failure. That distinction is essential when agents interact with tools, data sources, or human review queues.

Practical implication: Instrument every agent path so you can reconstruct the exact sequence of model calls, tool actions, and guardrail decisions for any request.

Why prediction logs still matter for traditional ML observability

Traditional machine learning systems expose different evidence than agents. Their behaviour is usually represented through tabular prediction logs containing features, outputs, labels, timestamps, metadata, and sometimes explainability signals. Those logs make it possible to detect drift, segment performance by cohort, and compare expected versus actual behaviour over time. They are especially useful when the model is stable but the data distribution is changing underneath it. The governance value is that ML observability depends on selecting the right fields before analysis, not dumping raw production data into a monitoring stack. Sensitive attributes should be excluded or reduced before analysis begins.

Practical implication: Define a controlled prediction-log schema for each model family and use it to track drift, cohorts, and label performance over time.

How privacy-aware telemetry pipelines change the control boundary

AI observability is not just a logging problem. Once traces and prediction data move into a shared platform, the pipeline itself becomes part of the control boundary. Privacy-aware redaction, sampling, enrichment, and routing determine whether observability improves governance or simply expands exposure. If personal data is collected without filtering, the observability stack becomes another data-risk surface. If the pipeline is too sparse, teams lose the evidence they need to debug or explain behaviour. The right design preserves enough context for investigation while enforcing central rules for sensitive data handling. That is what makes observability an operational control rather than a reporting layer.

Practical implication: Treat the telemetry pipeline as a governed data flow and apply redaction and sampling before AI traces reach downstream systems.

NHI Mgmt Group analysis

AI observability is now part of the control plane, not a reporting afterthought. Once agents can plan, retrieve, and call tools, the organisation needs evidence of what happened inside the workflow, not just whether the request succeeded. That shifts observability from metrics collection to governance over runtime decisions, especially where humans may still review the final action.

Agentic AI creates a traceability problem that traditional ML monitoring cannot solve. A single interaction can contain several decision points, each with its own latency, data exposure, and policy implication. The practitioner consequence is that governance must move closer to the execution path, where evidence is created rather than where summaries are reviewed.

Privacy-aware telemetry is the difference between useful observability and data sprawl. Redaction, sampling, and routing are not implementation details, they are the controls that determine whether AI monitoring increases accountability or creates a new sensitive-data repository. The practical conclusion is that observability pipelines need security design, not just instrumentation.

Traceability of AI decisions will become a baseline expectation for regulated and customer-facing systems. As organisations rely on agents for support, search, fraud handling, and partner workflows, they will need to show how outputs were formed and why they changed. Practitioners should treat explanation quality as an operational requirement, not a model feature.

From our research library:

• 7% of security leaders admit they do not know how often their AI systems are making autonomous changes to infrastructure, according to the 2026 Infrastructure Identity Survey.
• Read next: AI Agent Observability, Audit and Incident Response Guide

What this signals

Observability gaps will become governance gaps as agentic systems move deeper into production. Teams that cannot reconstruct prompts, retrievals, tool calls, and fallback logic will struggle to explain why an AI system behaved the way it did. For practitioners, the signal is clear: the evidence layer now needs the same design attention as the model layer.

AI observability is converging with identity governance because agents act through delegated runtime authority. That does not make every observability problem an IAM problem, but it does mean the path from request to action needs audit-grade traceability when software systems can initiate work, call tools, and surface outputs with limited human review.

Context bloat is a useful named pattern for agentic debugging. When conversation history grows faster than task value, token usage rises, quality falls, and the root cause often sits in how state is being carried forward between turns. The practical lesson is to watch the lifecycle of conversational context, not just response quality at the end.

For practitioners

• Instrument end-to-end agent traces Capture prompts, retrieval calls, tool use, guardrails, latency, and fallback decisions so each AI interaction can be reconstructed without ambiguity.
• Separate agent telemetry from raw production logs Use structured traces for agentic workflows and prediction logs for traditional ML so each system is monitored with the right evidence model.
• Apply redaction before observability export Filter sensitive attributes and personal data in the telemetry pipeline before traces or logs are routed to downstream analytics or monitoring systems.
• Track cohort-level model behaviour Compare performance by geography, device, user segment, or workflow type so subtle regressions are visible before they become broad service issues.

Key takeaways

• AI observability is becoming a runtime control because teams now need to explain how agents and models reached specific outcomes, not just whether they responded successfully.
• The core evidence stack is different for agents and traditional ML, with traces, prediction logs, redaction, and cohort analysis each serving a distinct governance function.
• Practitioners should treat telemetry design as part of AI control design, because the ability to reconstruct behaviour is what turns monitoring into accountability.

Key terms

• AI observability: AI observability is the ability to see how AI systems are being used, what information they process, and what actions they trigger. In security programmes, it extends beyond uptime or model quality to runtime visibility, policy enforcement, and audit evidence across human and agent-driven use cases.
• Agentic workflow: An agentic workflow is a sequence of tasks executed by an AI agent with some level of tool access and decision authority. In security terms, the workflow matters because it can span multiple systems, identities, and permissions, which makes attribution and revocation harder than with ordinary automation.
• Prediction Log: A prediction log is a structured record of model inputs, outputs, timestamps, labels, and related metadata used to analyse traditional machine learning performance. It supports drift detection, cohort analysis, and post-hoc review without relying on raw production logs alone.
• Privacy-Aware Redaction: Privacy-aware redaction is the removal or masking of sensitive information before telemetry is stored or sent to analytics systems. It allows observability teams to retain enough context for debugging while reducing unnecessary exposure of personal or regulated data.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security for practitioners who need a stronger control model around delegated runtime behaviour. It helps security and identity teams connect governance, access, and lifecycle thinking to systems that act independently in production.