> ## Documentation Index
> Fetch the complete documentation index at: https://docs.joystream.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Review runs and tickets

> Read what an agent actually did — runs, stories, tickets, and the provenance behind them.

After a run, there are two views of the same work. Runs and stories tell you how it executed. Tickets tell you what happened, in language a teammate can read.

## Find the run

```bash theme={null}
jstm agent runs failed-payment-digest
jstm agent runs failed-payment-digest --mode live --status failed
```

Filter by `--mode` (`dry_run`, `pilot`, `live`) and `--status` (`queued`, `running`, `completed`, `failed`).

## Read one run

```bash theme={null}
jstm agent run show failed-payment-digest/runs/12
```

You get the run's status, its stories and their outcomes, its output, any rejection reason, and its provenance.

The provenance block is the part people skip and shouldn't. It names the exact spec version, agent version, package version, and deployment that produced this result. When two runs behave differently, this is where the difference lives.

## Read the work as tickets

```bash theme={null}
jstm ticket list --agent-id failed-payment-digest
jstm ticket list --run-id 5f3a5c81-2d44-4e0b-9a17-0c9d3b7e9b21
```

Tickets are grouped by run. Passing an epic id to `ticket show` renders its whole story tree:

```bash theme={null}
jstm ticket show 8c41f2b9-77de-4a30-b0c5-2e1f6a9d4b77
```

Tickets are what you send to someone who wasn't following the run. They describe what was requested, what happened, what changed, what failed, and what needs attention — without tool-call detail.

## Find what needs attention

```bash theme={null}
jstm ticket list --status blocked --since 24h
jstm agent stories --all --status failed
```

`--since` takes a window like `15m` or `24h`. `jstm agent stories --all` sweeps every agent at once, which is the fastest way to see whether anything is stuck across your whole workspace.

## Export for sharing or analysis

```bash theme={null}
jstm ticket list --agent-id failed-payment-digest --out digest-tickets.json
jstm ticket show 8c41f2b9-… --json | jq '.stories[] | select(.status=="failed")'
```

`--out` writes the payload to a file. `--json` sends it to stdout, clean of any diagnostics.

## Reading a failure

When a story fails, three things tell you why.

1. **The story's failure detail**, in `jstm agent run show` — what the step was trying to do and what it got back.
2. **The error policy**, which explains what happened next. A `CRITICAL` step aborts the run; a `MUST_HAPPEN` step retries with backoff; a `BEST_EFFORT` step records the failure and the run continues.
3. **The ticket**, which states the consequence in business terms.

A run that completed with a best-effort failure inside it is not the same as a clean run, and the ticket is where that distinction is visible.

## Judging success

A run that ended without an error is not automatically a success. The question is whether the intended outcome occurred.

Compare the run's output against the acceptance criteria in the agent's spec:

```bash theme={null}
jstm agent view failed-payment-digest --definition
```

If the criteria and the output don't line up, the improvement belongs in a new spec version — not in a note somewhere.

## See also

* [Runs and work](/concepts/runs-and-work) — the model.
* [Evidence, memory, and metrics](/concepts/evidence-and-memory) — what counts as proof.
* [`jstm ticket`](/cli/ticket) — full reference.