Notifications
Clear all
Topic starter
21/08/2026 4:56 pm
TL;DR: Multi-agent systems need production observability because orchestration, tool calls, and handoffs create failure modes that demo testing misses, according to Arize’s walkthrough of Google ADK and Arize AX. The key issue is not whether agents can run, but whether teams can trace, evaluate, and govern their decisions at scale.
NHIMG editorial — based on content published by Arize: Tracing, Evaluation, and Observability for Google ADK (How To)
Questions worth separating out
Q: How should security teams control autonomous agent actions in production?
A: Security teams should validate every high-impact action at runtime against intent, context, and allowed scope.
Q: Why do multi-agent systems create governance risk beyond normal application monitoring?
A: They create governance risk because the meaningful security event is often the sequence of actions, not the final answer.
Q: How do security teams know if agent observability is actually working?
A: Observability is working only when teams can tie together token activity, tool calls, and latency for a specific agent session.
Practitioner guidance
- Instrument every agent handoff Capture routing decisions, sub-agent transfers, and tool invocations with structured traces so that production behaviour can be reconstructed after the fact.
- Define evaluation sets for agent trajectories Build regression datasets that score handoff quality, tool selection, and sequence validity rather than relying on response-only testing.
- Review tool metadata as a control surface Treat tool descriptions, permissions, and default instructions as part of the security design, because they influence what an agent chooses to do.
What's in the full article
Arize's full post covers the operational detail this post intentionally leaves for the source:
- Step-by-step Google ADK agent orchestration examples for a multi-agent travel concierge.
- OpenTelemetry registration and instrumentation code for capturing agent traces in Arize AX.
- Prompt Playground workflow examples for comparing prompts, models, and evaluation strategies.
- Regression dataset handling and human review loops for production agent tuning.
👉 Read Arize's analysis of tracing, evaluation, and observability for Google ADK →
Google ADK observability and agent tracing: are your controls keeping up?
Explore further
21/08/2026 5:13 pm
Agent observability is becoming an identity control, not just an engineering convenience. Once a multi-agent system can route tasks, call tools, and retain state, it starts behaving like a runtime identity that needs traceability. The governance question is no longer only whether the system answered correctly, but whether its actions were authorised, inspectable, and attributable. That is where observability intersects with IAM and NHI governance, because every tool call is effectively a privilege use event. Practitioners should treat agent traces as governance evidence, not optional telemetry.
A question worth separating out:
Q: How do you know if agent evaluation is actually working?
A: It is working when it explains failures well enough to change the system, not just when it outputs a score. Good evaluation should point to the layer that failed, produce a reproducible trace, and feed confirmed failures into regression tests. If the score does not change engineering decisions, it is not yet operational.
👉 Read our full editorial: Google ADK observability exposes the control gap in multi-agent systems
