Notifications
Clear all
Topic starter
06/09/2026 9:01 am
TL;DR: AI agent observability must cover tool calls, state changes, reasoning traces, and error recovery because logging only what an agent said misses the actions that can silently cascade across production workflows, according to Openlayer. The operational gap is no longer about model output quality alone, but about controlling and attributing what agents actually do.
NHIMG editorial — based on content published by Openlayer: AI Agent Observability Guide: Tracing Actions & Tool Calls (July 2026)
By the numbers:
- Tool calls fail between 3 and 15% of the time in production, and a single failure can cascade silently across a multi-step workflow.
Questions worth separating out
Q: How should security teams trace AI agent failures in production?
A: Trace the whole agent run, not just the final model call.
Q: Why do AI agents need more than LLM tracing and logs?
A: Because logs and model-call traces miss the workflow around the model.
Q: What are the signs that AI agent observability is failing?
A: The main signs are missing tool metadata, disconnected traces between agent hops, unexplained retries, and an inability to reconcile a successful call with the actual state change it caused.
Practitioner guidance
- Instrument tool-level execution traces Capture the tool name, version, input arguments, raw output, latency, and success or failure status for every invocation so you can reconstruct the real execution path.
- Correlate every hop with a shared trace ID Thread one trace identifier through the full agent chain, including subagents and downstream tool calls, so context handoffs and root cause remain visible across the workflow.
- Verify state after each side effect Check whether a database write, API call, or file change produced the intended external state before the agent continues to the next step.
What's in the full article
Openlayer's full analysis covers the operational detail this post intentionally leaves for the source:
- Step-by-step instrumentation guidance for tracing tool calls, retries, and state changes across agent runtimes
- Detailed OpenTelemetry GenAI span mapping for LLM calls, tool spans, and agent spans in production workflows
- Operational examples of how to detect silent failures and reconcile intended state with actual state after execution
- Framework-specific integration detail for teams using agent SDKs and distributed tracing stacks
👉 Read Openlayer's analysis of AI agent observability and tool-call tracing →
AI agent observability: what teams need to trace beyond text output?
Explore further
06/09/2026 9:02 am
Action observability is becoming part of identity governance, not just application telemetry. Once an agent can call tools, write records, and chain decisions, it behaves like a non-human runtime identity with delegated authority. That means the governance question is no longer whether output was accurate, but whether the action was authorised, attributable, and bounded. IAM and PAM teams should treat agent traces as control evidence, not as optional debugging data.
A question worth separating out:
Q: Should agent observability include runtime enforcement or only logging?
A: It should include both, but logging alone is not sufficient. Logging tells you an unsafe or out-of-policy action happened, while runtime enforcement stops it before the action leaves the inference boundary. For production agents, the control value comes from preventing harmful side effects, not just documenting them after the fact.
👉 Read our full editorial: AI agent observability gaps are exposing action-level production risk
