Engineering

Engineering

The anatomy of a run trace

The anatomy of a run trace

What we record for every agent run, why each field exists and how traces power replay, evals and audits.

What we record for every agent run, why each field exists and how traces power replay, evals and audits.

Portrait of Jonah Weiss

Jonah Weiss

8 min read

Abstract data illustration for “The anatomy of a run trace”

Every Cairn run produces a trace: an ordered record of what triggered the run, what the agent read, which tools it called, what it decided and what changed in the world as a result.

Steps, not tokens

We model a run as typed steps — trigger, research, decision, action, result — rather than a raw transcript. Steps are what humans reason about, and they map cleanly to permissions and approvals.

Tool calls are first-class

Each tool call records inputs, outputs, latency, retries and the idempotency key used. When something goes wrong, you can see whether the agent made a bad choice or the API returned something unexpected.

  • Inputs and outputs, with PII redaction applied

  • Duration, retries and error codes

  • The policy version the decision referenced

  • Who approved the step, if approval was required

Replay

Because tool outputs are recorded, any run can be replayed deterministically against a new version of the agent. That’s how evals work in Cairn: last month’s real runs become this month’s regression suite.

Portrait of Jonah Weiss

WRITTEN BY

Jonah Weiss

Staff Engineer, Runtime

Jonah works on the trace store and replay engine. He cares about deterministic tests, readable logs and boring infrastructure.

Field notes

One email a month. Only the useful parts.

Lessons from running agents in production, new templates and the releases worth knowing about. Unsubscribe in one click.

Create a free website with Framer, the website builder loved by startups, designers and agencies.