Skip to main content
Observability is what tells you what your agents are actually doing. Every run is captured as a chain of events with inputs, outputs, timings, token counts, and cost. From those events you get search, analytics, drift detection, and alerts — without writing any of the plumbing yourself.

​
What’s inside

LLM Calls

Table of every LLM invocation with filters, search, and a detail drawer.

Traces

Full chain-of-calls per run — chains, tools, retries, and durations.

Analytics

Cost by model, p50/p95 latency, error rate, and model performance.

Threads

Multi-turn conversations grouped from chat events.

Drift Monitor

Distribution monitoring across five metrics with composite scoring.

Alerts

Threshold rules with cooldown, escalation, and SLA tracking.

​
When to use what

You want to…Use
Find a specific run by user, agent, or input textLLM Calls
Debug why a particular run failedTraces
Track cost and latency over timeAnalytics
Inspect a multi-turn conversationThreads
Catch behavioural shifts before users doDrift Monitor
Get paged when something breaksAlerts

​
The data behind the views

Every event the SDK emits lands as one of two records in the database:
  • A Run — one execution of an agent, chain, or tool. Carries the aggregate cost, duration, status, and saved flag.
  • An Event — a leaf record inside a run, such as chain_start, tool_end, chat, or saved.
The Observability views are all built on top of these two tables. The SDK reference describes the event flow and how custom events plug in.

SDK event reporting

How events are batched, sent, and persisted.

Governance

Once you can see runs, the next step is shaping them.
Last modified on June 2, 2026