How it works

From a black box you can't debug to one you can re-run.

Runback records everything an agent does so you can reproduce any run, find what broke, test a fix before release, and keep a signed record you can prove.

01
Observe
Capture every decision the model sees — context, tools, tokens, PII redacted.
02
Replay
Re-run from the exact captured context. A different output means behaviour changed.
03
Gate
Simulate a policy against history. Enforce it live, block before it runs.
04
Audit
Export a tamper-evident, hash-chained record. Every decision provable.
05
Compound
Every incident auto-mines into a regression test. The suite writes itself.
What changes

When you can reproduce any decision, three things change.

01
Model upgrades become controlled experiments. You replay your actual production decisions against the new model and measure behavioral change before it ships — not after customers find it.
02
Prompt iteration becomes safe. Regression testing runs automatically from real failures, not from someone's memory of edge cases. Every incident that gets resolved becomes a test that blocks the same class of failure from reaching production again.
03
Regulated deployment becomes day-one. The governance artifact is built continuously from the first run — not retrofitted when an auditor asks for it six months later. That changes who you can sell to and how fast you can sign them.
01 · Observe

See exactly what the model saw.

Every step records the precise context the model was handed — system prompt, conversation, tools — captured at the model boundary, with PII redacted in-process. A failed run opens on the step that broke. Click any step:

research-email-agent · run failedclick any step ↓
Tool call · send_email — failed here
tool
send_email
status
error
input
{ "to": "alex[at]acme.co", "body": "Next.js 16 summary…" }
Invalid recipient — the model wrote the address in plain text ("[at]") instead of a valid email. The run failed here.
02 · Replay

Reproduce any decision — then find what changed it.

Re-execution holds tools, retrieval, context and timing fixed and runs the model fresh — so you can see if behaviour has changed, not watch a recording. LLMs are non-deterministic; getting a different output on replay is the signal, not a defect. When something breaks, bisect the model and prompt timeline to the exact change that caused it, in log₂ tries. Upgrading models? Replay a sample of real production decisions from the last 90 days against the candidate before you ship — behavioral drift shows as regressions, not incidents.

Original · gpt-4opass

Flagged the $85k application for human review — correctly applied the $50k limit.

route_to_review({ reason: "exceeds_auto_limit" })
Replay · gpt-4o-0513regression

Approved the same $85k application — ignored the $50k limit entirely.

issue_approval({ amount: 85000 })
One incident, two outcomes

Hours of log archaeology, or minutes on the failing step.

The same production failure, resolved with a log pipeline and with Runback. The difference is not tooling preference — it is whether the decision can be reproduced at all.

Without Runback
3h 48m
Grep through 2,400 log lines.
Guess. Patch. Hope it doesn't recur.
2:47 AM — alert fires
3:00 AM — first engineer online
4:15 AM — found a suspicious log line
5:20 AM — maybe found the prompt issue?
6:35 AM — fix deployed, fingers crossed
same incident
With Runback
4m 23s
Open the run. Root cause is highlighted.
Patch, replay to confirm, seal the record.
2:47 AM — alert fires with run link
2:49 AM — run open, failure step highlighted
2:51 AM — root cause found in messages[]
2:52 AM — fix applied, replay confirms
2:52 AM — sealed. Done.
03 · Gate

Turn a fix into a guardrail — then enforce it live.

Save the step to a dataset with the checks it must keep passing and run it as an eval before release. Go further: simulate a candidate policy against 90 days of your own production decisions — not synthetic test cases — to know exactly which past runs would have been blocked before you ship it. Then enforce it in-process — the violating action is blocked before it runs, with a re-runnable record of the block. A breach becomes a red row, never an incident.

3 / 4 passed — 1 regression caught before deploy
04 · Audit

The cassette that sealed itself as it ran.

Export a complete, tamper-evident record of any run — every event in a SHA-256 hash chain, signed. Change one byte and verification fails. The artifact an auditor actually asks for.

$schemarunback.audit/v1
run_idsupport-refund-agent
events6 · chained
content_digest3e68cdbbf372df98…
signatureHMAC-SHA256 ✓ signed
Recompute the chain to verify — POST to /api/audit/verify.
0nownowa1b2c3d4e5f6
current digesta1b2c3d4e5f6a1b2c3d4e5f6
SHA256(prev_hash + canonical({kind, key, output}))

Runs seal into an org-wide ledger too. Each run becomes a leaf; the leaves form a Merkle tree, so a single signed root proves any one run is in the log — without handing over the rest of them.

merkle_root
5e1a8c3f6b9d
node_01
3b6d9e0f1c4a
node_23
a2c5f8b1e4d7

↑ Click any leaf to highlight its proof path

05 · Compound

Every incident becomes a permanent test.

A run that breaches policy or errors is auto-enrolled as a golden test — deduped so each distinct failure is one test. Re-run the suite on any candidate model before release and see, in seconds, whether an old incident would come back. Your regression suite is written by reality and grows with every run — the loop closes on itself.

Walk the loan-approval-agent incident — all 5 steps, the policy block, the cassette →

  1. 01

    You can't reproduce what your agent decided.

    Logs record the outcome. Re-execution shows the reasoning — the exact context, retrieval, and messages[] the model saw. Root cause in 4m 23s, not 3h 48m.

    Demo scenario — walk the exact step · walk it →
    Without Runback · 2,400 lines
    [02:47:03] INFO agent.run started
    [02:47:04] INFO tool_call check_credit
    [02:47:05] ERROR issue_approval failed
    … 2,397 more lines, no context
    With Runback · exact step
    ▸ agent decides ← failure here
    model: gpt-4o · 418 tok
    system: loans up to $50k only
    root cause: in this block ↑
  2. 02

    You think you can build this. The parts that matter you can't.

    The capture layer takes a sprint. The golden corpus, fleet benchmarks, and policy history take years — and can't be imported, back-filled, or bought.

    Fleet benchmarks, golden suite, policy library · what's in Growth and Pro →
    Your org · month 1
    124 runs captured
    Your org · month 6
    847 golden tests
    Your org · month 12
    2,400+ auto-mined
    Competitor today
    starts from 0

    mined from real prod failures · can't be imported or bought

  3. 03

    Your agents produce decisions that outlast your current vendor.

    Move models, frameworks, or vendors. The cassette stays open-format, signed, and re-executable. Your proof outlasts every software contract.

    Open and verify a run yourself · open a run →
    $schemarunback.cassette/v1
    run_idloan-approval-agent
    modelgpt-4o → claude-4
    signatureHMAC-SHA256 ✓ still valid
    vendor changed · cassette unchanged · still verifiable
  4. 04

    An auditor will ask. A regulator will follow. You need an answer before the question arrives.

    EU AI Act Art. 12, APRA CPS 230, NIST AI RMF — one continuous record covers all three, built from the first run, not retrofitted when the auditor asks.

    EU AI Act, Article 12 — read the law · the law ↗
    EU AI Act · Art. 12mandatory logging for high-risk AI
    APRA CPS 230operational incident recording
    NIST AI RMFmeasure, manage, govern functions

    one Runback cassette · satisfies all three

  5. 05

    You're not betting on one model forever. Your governance layer shouldn't either.

    GPT, Claude, Gemini, Llama, or your own — across LangGraph or any framework. One governance layer above every model vendor.

    Why we don't compete on models · the standard →
    GPT-4oClaudeGeminiLlama 3MistralYour model+ any OpenAI-compatible endpoint
  6. 06

    Multi-agent systems have no trust primitive. Every other tool treats that gap as out of scope.

    Observability records after the call. Runback seals the delegation before execution — scope, caller, and chain cryptographically proven.

    Inter-agent trust chain — Enterprise · how delegation is signed →
    No trust primitive
    orchestrator → subagent
    scope: ??? (unverified)
    caller: ??? (no proof)
    injection possible
    Runback trust chain
    loan-orchestrator depth:0
    token: a3f8c2d1… (HMAC)
    kyc-subagent depth:1
    sig ✓ verifiable offline
  7. 07

    The team that starts capturing today has an advantage in 18 months that can't be bought.

    Behavioral history only builds forward. Every month you delay is a month of data you can never recover. That gap compounds.

    Fleet benchmarks, model diff, policy library · what's in Pro →
    4m 23sMTTR with Runback
    vs
    3h 48mwithout captured context

    loan-approval-agent · 2:47 AM · every month you delay is behavioral data you can never recover

Where the data lives

Your agent runs in your app. So how does Runback see it?

A fair question — your model calls happen inside your own application, not on Runback. You hook it up once; everything else runs on the trace that capture produces. Nothing sits in your critical path.

1 · Your agent

Instrument once

A ~3-line SDK wrap, a base-URL swap, or your existing OpenTelemetry traces. It's a post-hook: your real model call runs untouched — Runback only records the request it saw, the response, tokens, latency and tool calls.

const dbg = withDebugger(model)
const res = await generateText({ model: dbg.model })
await dbg.finish({ status: "success" })
SDKProxyOpenTelemetry
2 · In your process

Redact before egress

Secrets, keys, emails, card numbers and SSNs are scrubbed inside your application process, before a trace is sent anywhere. Even your own backend never sees them.

3 · Your store

Land in a store you own

Captured runs are written to Postgres you control — self-hosted in your VPC — or our managed cloud. You set retention and access; delete a run and it's gone.

4 · On the trace

Replay · Evals · Audit

Every feature reads those captured traces — re-run from the captured context, gate releases against policy, export a signed record. No extra wiring, no second integration.

Live replay and evals re-execute a captured step against a model, so they use a provider key configured server-side — the only thing beyond the one-time hookup. Observe, time-travel, and audit need no model key at all.

Connect your agent

About three lines, any agent.

Use the SDK for the deepest capture, or point existing OpenTelemetry traces at Runback — it sits above whatever framework you build in.

import { withDebugger } from "@runback/sdk";
import { generateText, stepCountIs } from "ai";

const dbg = withDebugger(model, { runName: "support-agent", redact: "standard" });
const res = await generateText({
  model: dbg.model,
  tools: dbg.tools(myTools),
  stopWhen: stepCountIs(8),
  prompt: task,
});
await dbg.finish({ output: res.text, status: "success" });

Every run now shows up ready to observe, replay, gate, and audit. See all integrations →

The fastest way to get it is to open a run.

Walk a real failing run step by step — no signup.