Observability isn’t an add-on — it’s the orchestrator.
Every hand-off, every tool call, every score — captured by default. We don’t bolt observability on after the fact; we make it the rail every agent walks on.
Platform team
Platform engineering
Most teams build the orchestrator first and add observability later. We did the opposite. The trace timeline existed before any specialist agent did, and every agent we’ve shipped since was built to write to it. That ordering is why we can replay any run, audit any decision, and roll back any change.
Build the rail first
When you build the trace second, every agent you shipped before it has its own ad-hoc logging format. You spend the next quarter writing adapters. When you build the trace first, every new agent inherits the format because there’s no other format to choose.
What a trace contains
- trace_id and parent_id for the run.
- Every hand-off (which specialist was called, with what input).
- Every tool call (verb, target, latency, idempotency key).
- Every model call (prompt, response, model, tokens, cost).
- Every decision (router intent, confidence, escalation status).
- Every outcome (success, soft-fail with warning, hard-fail with error).
Replay-first design
Because the trace is the source of truth, we can replay any run end-to-end. That’s what makes regression testing on agents tractable: ship a new specialist, replay yesterday’s 10k traces against it, diff the outputs, ship or revert.
Observability is also a product surface
We expose the trace in the customer dashboard. When a user reports a weird outcome, support asks for the trace_id and we look at it together. That changes what ‘support ticket’ means: we’re not guessing at logs, we’re looking at the same timeline the customer sees.
“Observability isn’t a tab in the dashboard. It’s the runtime your agents live inside.”