How do you implement observability for an agentic AI sy...

Observability for an agent has to answer both “why did it do that” and “what went wrong,” and neither question is answerable from the final output alone. Three layers, each covering a different question:

• Traces — the complete record of one run: every Thought, Action, tool called, arguments, result, latency, and token count, tied together under a single run ID. This is what lets a failure be replayed step by step rather than reasoned about from the outside.
• Metrics — aggregated across runs: success rate, average steps, cost per run, per-tool error rate, latency percentiles. This is where drift over time actually becomes visible.
• Logs — structured, contextual events: which user, which task, which steps completed, how the run ended. This is what answers “what was even going on here” when you’re triaging a specific incident.

Skipping the trace layer specifically is the gap that hurts most, because metrics alone tell you that something degraded but not where — a dropping success rate with no trace to inspect leaves you guessing whether the cause was retrieval, a tool, or the model’s reasoning, rather than being able to point at the exact step.