Notifications
Clear all
Topic starter
18/08/2026 2:29 pm
TL;DR: Agentic systems generate more telemetry than traditional applications, but their nondeterministic plans, memory drift, and tool chaining make traces harder to interpret, according to Arize. The next observability layer has to reconstruct intent and causality, which also raises governance questions for identity, access, and accountability around AI agents.
NHIMG editorial — based on content published by Arize: AI agent observability: Why production systems need a reasoning layer
By the numbers:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, sharing sensitive data, and revealing access credentials.
- 96% of technology professionals identify AI agents as a growing security threat, and 66% believe this risk is immediate.
Questions worth separating out
Q: How should security teams govern AI agents that can choose tools at runtime?
A: Security teams should govern runtime agent choice as an access event, not as a simple application action.
Q: Why do AI agents make observability and incident response harder than traditional applications?
A: Agents can change their plan, retrieved context, and tool arguments on each run, so two similar traces may lead to very different outcomes.
Q: What breaks when AI agent traces do not include memory and tool context?
A: Reproduction breaks first, because engineers cannot tell whether a failure came from code, retrieval, memory drift, or a tool-side issue.
Practitioner guidance
- Capture the full agent trajectory Record prompts, retrieval results, memory state, tool calls, agent-to-agent messages, and downstream service spans under a shared trace so investigations can follow the decision path end to end.
- Version every runtime input Track the system prompt, model configuration, tool schema, policy state, retrieval source, and memory version for each execution so historical behaviour can be reproduced and compared.
- Separate intent from outcome Store task category, expected result, final state, and evaluation scores alongside telemetry so reviewers can tell whether an agent completed the right task, not just whether it completed a task.
What's in the full article
Arize's full blog post covers the operational detail this post intentionally leaves for the source:
- The talk-specific examples from Arize Observe 2026 that show how reasoning over traces works in practice.
- The product and workflow details around Arize AX, Signal, and Bedrock AgentCore integration for production investigations.
- The exact structure of the observability stack for traces, evaluations, datasets, and experiments.
- The end-to-end examples of how investigating one incident turns into an evaluation dataset and a proposed fix.
👉 Read Arize's analysis of why AI agent observability needs a reasoning layer →
AI agent observability is changing debugging. Are your controls ready?
Explore further
18/08/2026 3:17 pm
AI agent observability is now an identity governance problem, not just an engineering problem. Once agents can call tools, access memory, and trigger backend actions, they behave like governed non-human identities with dynamic authority. The article shows why trace data alone is insufficient: security teams need to know which agent acted, under what context, and with what effective privilege. The practitioner conclusion is straightforward: observability must support access accountability, not only debugging.
A question worth separating out:
Q: How do teams decide whether an AI agent needs human approval?
A: Use the sensitivity of the action, not the cleverness of the model, as the decision point. If the agent can change records, move funds, send external messages, or access regulated data, human approval or an independent policy engine should remain in the path. The more irreversible the action, the less autonomy the agent should have.
👉 Read our full editorial: AI agent observability needs a reasoning layer for production
