Trace

An agent's finished work does not explain how it got there. Trace is the discipline of answering that for a single run: every decision the agent made, and the rationale behind it, preserved from the opening prompt to the change that shipped.

When that trail holds, a failure from last quarter is something you reconstruct from the record left as the work ran, not something you reverse-engineer from the output and a few people's memories. Incident reviews start from evidence, and when an auditor asks how a decision got made, you have an account to put in front of them.

Exploratory

A run goes wrong and the why is gone: you stare at the output with no path back to the decisions behind it. Every team starts here.

Enables

The final output is still there, and the runs you find yourself wishing you could walk back are the ones a decision trail later gets built to preserve.

Deficiencies

No record of what the agent did or why, so postmortems are guesswork and there is nothing to show an auditor.

Cost to maintain

Reruns to try to reproduce a failure, often without reproducing it.

Expert-led

One engineer can reconstruct a run from memory and their private notes.

Enables

The cases they were close to can be traced, and their reconstruction is usually right.

Deficiencies

A single point of failure whose rationale lives in their head rather than the record, so cold and old runs are unrecoverable.

Cost to maintain

Their time reconstructing, plus the risk that walks out the door with them.

Documented

The team pieces a run together from scattered comments and trackers, and events are on the record even where rationale is thin.

Enables

Anyone can follow what happened, and postmortems draw on a shared trail rather than one memory.

Deficiencies

Rationale is still partial, provenance like sources read and queries run is not consistently cited, and gaps open where no one commented.

Cost to maintain

The habit of posting comments and updating trackers as the work happens.

Structural

Decisions are recorded with rationale and provenance as the work runs, so anyone can reconstruct a run months later.

Enables

Full postmortems and an audit-ready record, cold cases that stay recoverable, and a trace that does not depend on who was present.

Deficiencies

Logging volume can bury the signal, and capture must be designed not to leak secrets into the trail.

Cost to maintain

The logging pipeline upfront, plus storage, retention policy, and query tooling over time.

Trace rarely stands alone. Where it overlaps a sibling discipline, an investment on one side quietly depends on the other. The Observability domain page lays these out in full.

• Trace and Capture

  A trace is only ever a reading of what Capture bothered to write down: reconstruct a decision and you are replaying the record, not the run, so reasoning-level Trace demands reasoning-level Capture. Instrument only the prompts and the tool calls and the trail can say what happened but never why, which is the half of an incident that actually costs you.

  Invest in both and a cold case reopens down to the judgment behind it. Under-fund Capture and Trace becomes a courtroom with no evidence: the event on the record, the reason for it gone.

• Trace and Availability

  Availability and Trace answer opposite questions of the same record. Availability reads across every run at once while Trace goes vertical on one of them, the full walk of a single case down to the reasoning behind it.

  You need both postures, because a query that flags a spike in failures cannot tell you why any single one broke, and reconstructing that one broken run cannot tell you whether it is a fluke or a pattern. Fund only breadth and you are watching a trend you cannot diagnose; fund only depth and you are explaining a case you cannot place.