TL;DR: Distributed execution, unstructured context, and schema-flexible tool use break traditional logging, metrics, and tracing models, according to HoneyHive. The practical implication is that AI programmes must treat traceability, enrichment, and real-time evaluation as core production controls, not optional instrumentation.
NHIMG editorial — based on content published by HoneyHive: The Evolution of Observability: From Monoliths to AI Agents
Questions worth separating out
Q: How should security teams govern AI models that can call tools and access data?
A: Security teams should govern AI models as non-human identities with named owners, limited scope, short-lived credentials, and continuous authorization.
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: How do teams know if AI observability is actually working?
A: It is working when teams can show which change caused a quality shift, which dataset surfaced the issue, and whether the regression was contained before users were affected.
Practitioner guidance
- Trace every agent action end to end Instrument prompts, retrieval, tool calls, model outputs, and state updates with shared trace context so investigators can rebuild the full execution chain.
- Preserve nested agent data before normalising it Store raw structured and unstructured payloads at ingestion time, then enrich later, so changing schemas do not erase evidence needed for debugging and governance.
- Define semantic failure classes up front Create labels for hallucination, tool misuse, policy deviation, and unsafe response patterns so evaluation rules can run consistently across production traffic.
What's in the full article
HoneyHive's full article covers the technical implementation detail this post intentionally leaves for the source:
- The ClickHouse schema choices used to separate heavy and light fields for faster query performance.
- The OpenTelemetry ingestion path for mapping spans into the observability data model.
- The write-time and read-time aggregation pattern used to support real-time analysis at scale.
- The enrichment workflow for semantic evaluation signals such as hallucination detection and response quality.
👉 Read HoneyHive's analysis of observability for AI agents and execution traces →
AI agent observability gaps: what teams need to see in production?
Explore further
AI observability is now part of identity and access governance for agents. Once an AI system can call tools, retrieve data, or delegate work, its traces become evidence of privilege use. That makes observability adjacent to NHI governance because the same runtime record must show who or what the agent was allowed to act as, what it touched, and whether that access stayed within policy. For identity teams, traceability is no longer separate from authorisation.
A question worth separating out:
Q: How do organisations reduce risk when agent schemas and workflows keep changing?
A: Use a flexible event model that captures raw data first and enriches it later. This preserves nested tool arguments, long context windows, and multimodal payloads without forcing early decisions about structure. It also prevents telemetry from becoming stale every time the agent architecture changes.
👉 Read our full editorial: AI observability is shifting from logs to agent execution traces