Platform / Rewind

Rewind an agent's work

Telara records what a connected agent did, action by action. Rewind turns that record into a reviewable plan to undo it — you choose how far back, read what the undo would actually do, and confirm.

Admin

Recovery

Audit

The three screens

Rewind is not a single page. It is three, and each answers a different question. There is deliberately no “Rewind” landing page that asks you to paste a session id — finding the session is what Observability → Sessions is for.

Screen	Answers	How you get there
Session timeline	What happened, and how far back can I get?	Observability → Sessions → configuration → session. Agent IAM audit entries also link in.
Preview & confirm	What exactly would the undo do?	From the timeline, from Approvals, or from the dashboard.
Recovery dashboard	What is recoverable across the tenant right now?	The AI Estate nav group.

Reading the timeline

The timeline lists the session's recorded actions in order. Every action carries its own answer to “could this be undone”.

reversible

Telara knows the counter-action and has what it needs to issue it.

irreversible

The action cannot be undone at the provider. Nothing Telara does changes that.

unknown

Telara cannot determine reversibility. Treated as a barrier.

expired

A reversal window at the provider has closed. Treated as a barrier.

uncaptured

Telara did not capture enough to reverse this one. Not a barrier — see below.

A barrier is a floor, not a badge. Everything below the deepest barrier is unreachable no matter which row you pick, so those rows are shown as out of reach. There are three reasons a walk stops: unknown — an action below that point is one the catalog cannot describe, and nothing older than an undescribable action can be reasoned about; expired — a receipt below that point has passed its Rewind window, so what it did is no longer recorded in enough detail to undo; and unbindable — a reversal below that point cannot be aimed at anything from what was recorded. The preview says which one in words, not as a code. If you want to undo something below the floor, Rewind is not the tool — the barrier is a fact about what was recorded, not a Telara setting you can raise.

uncaptured is not a barrier. Actions below it are still reachable. It means Telara did not capture enough for that one step, which is a capture problem to fix, not a limit on how far back you can go.

Checkpoint bookmarks render inline — agent-declared, idle, resume, and pre-destructive — and are usually the cut point you actually want.

Undoing a session

Starting screen: the session timeline. End state: the plan reports every step as applied, or it stops and tells you which step did not.

Pick the cut point

Select the action you want to roll back to. The timeline shows the reachable floor, so you cannot silently select something below it and discover the truncation later.

Generate the preview

Previewing writes a plan and supersedes any previous preview for that session. You land on the plan page.

Read the things that matter

Reach vs request, counter-writes, unverified reversals, and residuals — each covered below. The preview exists to make refusal easy; if something reads wrong, cancel.

Confirm

Confirm quotes the plan hash back to the server. One button, one decision.

Watch it apply

The plan page reports per-step outcomes as they land.

Reading a preview

Warnings are ordered by what matters most and are shown as prose at the top of the plan. Do not skim:

Reach vs request

If the requested cut and the reachable floor differ, that shortfall is the first warning on the plan, ahead of everything else. "We undid your morning" and "we undid four minutes and let you find out later" are different outcomes.

Where it writes

Each step names the issue, post, page, or PR it will write, and links it when a browse URL was recorded. That name is a resource ref, not the forensic argument values.

Counter-writes are new destructive writes

Undoing a create means issuing a delete. A rewind is not a read — it writes to the provider, and steps that do so are marked.

Unverified reversals

A reversal proposed for an external MCP tool that has never been resolved against a real response from that provider. Approving it approves a guess about a payload shape. Treat it as a decision, not a detail.

Residuals and their notes

A residual is something the undo leaves behind. There are four reasons and each has a different next action, so the note is written out in full rather than hidden in a tooltip. It is the most useful string on the page.

Arguments arrive redacted. The plan shows which keys were omitted and how many fields, not their values, and there is no client-side toggle to reveal them. The issue or post a step will write is a resource ref and is shown (and linked when a browse URL is known). The forensic view is a separate server response available only to a principal holding the role for it — asking for it without the role returns the redacted view, not an error.

When confirm is refused

A confirm quotes the plan hash, and the server re-renders the plan as of now rather than replaying what was stored. If a hash mismatch comes back, that is not a transient error to retry — it means one of the target resources changed since you previewed. Re-preview and read what moved before deciding again. The page disagrees with what you were shown before anyone clicks, which is the point.

Freezing a session

Freezing stops a session from progressing while you decide. Use it when you have found something concerning and need the state to stop moving before you can review it — a freeze holds the ground; it does not undo anything on its own. Freezes are recorded with the reason you give and are released explicitly.

The recovery dashboard

A tenant-wide view over a 7- or 30-day window: sessions that are still actionable, windows expiring in under 24 hours, frozen sessions, and recent recoveries. Expiring windows are the actionable half — a reversal window that closes takes the option with it.

Who can do what

Rewind is not three independent switches. Access is evaluated per action, and having access to the agent that owns a session already carries some of it.

Preview a session

Allowed with rewind:preview, with rewind:admin, or simply by being able to act on the agent that owns the session — that last one is the default, so most people who can see an agent can already see how far its work could be rolled back.

Confirm a plan

An agent may never confirm — not with any permission. An agent that could confirm its own rewind would be a system where the undo button is pressed by the thing that made the mess.

For a person: rewind:admin or rewind:confirm always suffices. Without either, agent access is enough for ordinary plans — but not for a plan containing a high blast-radius step or a counter-write. Those demand an explicit rewind:confirm grant, and the refusal names which step forced it.

Administer

rewind:admin gates freezing and releasing sessions, Rewind settings, the recovery dashboard, and the forensic view of unredacted arguments. It also implies preview and confirm.

Every one of these is enforced on the server side of the call, never by hiding a button. A client that asks for the forensic view without the role gets the redacted response rather than an error — the tier is not something the caller may choose.

Four-eyes approval

A tenant setting with three values: off, all, or high_blast — the last applying separation of duties only to plans that contain a high blast-radius step.

Where it applies, two people are refused: whoever ran the original session cannot also approve undoing it, and the agent that requested the rewind cannot approve its own request. Like the rest, this is enforced server side — the value of a separation-of-duties control is that the system refuses, not that the button is hidden from one of the two people who should not press it.

Agent-requested rewinds

An agent can request a rewind, but it cannot confirm one. The request lands in a pending queue for a human holding rewind:confirm, and that person opens the plan page and sees the full rendered plan — steps, residuals, warnings — rather than a count of steps to rubber-stamp.