Docs The loop
Capture
What Runback records for each step an agent takes, and what it removes before anything leaves your process.
Runs. A run is one task an agent performed, start to end. Runback stores it as an ordered list of events, and every later stage (controls, fixes, evidence) points back at those events.
- type
- tool
- span_id
- t2
- seq
- 4
@runback/redact replaced one value: email at t1.output.email. The redactor logs the rule and the path, never the value. The run-end event records 1 redaction (email: 1).How to: inspect a run
Open Runs
In the app, open Runs. Every run your agents sent is listed, newest first. Use the agent filter to narrow it to one agent.
Open a run
Select a run. The page shows its timeline: every model call and tool call in order, with how long each took.
Select a step
Select any step in the timeline. Inspect shows exactly what that step saw and returned: for a model step the messages, tools and response; for a tool step the arguments and output. Time travel replays the run's state step by step.
Expected outputValues Runback redacted (emails, card numbers, keys) appear as[redacted:email],[redacted:credit_card]and so on. They were removed in your process, before anything was sent.
What a run is made of
The refund agent above was asked to refund an A$250 disputed charge. Its run is six events: it starts, a model step decides to look the customer up, the lookup_customer tool answers, a second model step decides to refund, the issue_refund call is stopped by a rule, and the run ends there. The run's recorded status is error: a stop by a rule is stored that way, so the widget shows it as data under the run's last step.
Every event carries the same envelope: schema_version, run_id, span_id, parent_span_id, seq and ts_start. seq orders the events, so nothing depends on clocks agreeing.
There are five event types:
| Type | What it records |
|---|---|
run | The start and the end of the run, its input, output, status and error |
llm | One model call: model, request.messages, response, usage, latency_ms |
tool | One tool call: tool_name, input, output, error, and any policy_block |
reasoning | A labelled reasoning step, with an optional graph node |
env | One environment read (now, date, random, uuid, fetch), captured by the commercial @runback/sdk-replay |
The full field list is generated from the schema in the event reference, and the record format, canonical JSON and hashing are in the open record spec.
Redaction happens before the event leaves
The TypeScript SDK runs @runback/redact on every event before it is buffered; the Python SDK's Collector(redact=...) does the same with its own redactor. What you pass sets how much is removed:
Pass redact: | What is removed |
|---|---|
| Nothing (the default) | The standard rules: emails, card numbers, API keys, tokens and private keys |
"strict" | The standard rules, plus phone numbers and IP addresses |
| An options object | The standard rules plus your own patterns and keys |
false | Nothing: events are sent as recorded |
The redactor logs the rule and the JSON path of each replacement, never the value. The run-end event carries the count (redaction_count, redaction_by_type), so the evidence pack can say how much was removed without holding any of it. In the TypeScript redactor, any string field over 50,000 characters is also truncated, and that is not counted as a redaction.
Run ids Runback refuses
| A run id that starts with | What Runback does |
|---|---|
demo- or sample- | Refuses the batch: 400 with code: "reserved_run_id". These prefixes mark Runback's own sample runs. |
decision:, decision_batch:, approval:, override: or report: | Skips and logs those events: the ids belong to the audit log. The response's ingested count is lower than what you sent. |