Observability model

Two things carry the record of what happened: the execution (the run itself, and what each step produced) and the audit log (who caused it). Neither is a full distributed-tracing product yet. Here's what's real.

Execution records

Every run is backed by an execution you can fetch:

GET /api/executions/:executionId
GET /api/workspaces/:workspaceId/executions

The response includes per-step status and a surfaces object keyed by node ID, the same output/wait surfaces described in Human in the loop. A currently paused step's surface tells you what's waiting on a person; a completed step's tells you what it produced. That's the primary way to inspect a run in progress, in the Console or against the API directly.

A step waiting on approval carries an outcome once it resolves (approved, rejected, or timed_out), alongside pending while it's still open.

The audit log

Every action, deploy, agent invocation, resume, lands in an append-only audit table, attributed to the user who triggered it. See Governance and Identity and audit attribution for what's actually on each event.

What we haven't formalized

A fixed catalog of trace event names (something like run.start / step.ok / tool.call) and per-call cost/token attribution aren't a committed, documented schema yet. If you're building automation on top of execution data today, treat field shapes as something to confirm with us rather than something to assume is stable. The Console UI in particular changes without notice. Pluggable trace export (OpenTelemetry, Datadog, Honeycomb) is on the roadmap, and a stable, versioned event schema is a prerequisite for it.