Replay and Agent Blame

Every session ORG-2 records is kept as a trajectory: an ordered list of typed events with their arguments and results. Because the record is structured rather than a scrollback buffer, ORG-2 can render it twice — once live, as the agent works, and once afterwards, as something you scrub through. This page covers what is in the recording, how to play it back, and how to go the other direction: from a file in your repo back to the session that touched it.

What a trajectory recording contains

The unit of the record is a session event: an id, a timestamp, the normalized tool name, its arguments, its result, and a small set of classifications the backend computes once at ingestion.

A typed payload is also extracted per event, so the UI never re-parses raw tool output. The payload kinds are thinking, file, edit, deleteFile, shell, search, glob, listDir, todo, message, await, webSearch, subagent and orgTask — a shell command, a file edit, a web search and a subagent handoff each land in the record as a distinct, inspectable thing rather than as text.

Events are grouped into turns: one user submission and everything the agent did in response. A separate turn index holds each turn's start and end position, duration, event count, status, whether it was interrupted, and the files it modified.

Note: awaiting_user is a real status, not a stalled running. Interactive tool calls — a question, a permission request, a plan for review — block the turn until you answer, and the recording preserves that pause.

Livestream and replay

Replay is not a separate viewer. The Workstation renders the session as a set of "apps" — Code Editor, Browser, Communication, Project Manager, Canvas, Diff and Background Tasks — and routes each event to the app that fits it. Watching live and watching later use the same surface; only the cursor differs.

The distinction is where the scrubber sits. Parked at the end, you are following the live stream and the view auto-scrolls with the agent. Move it anywhere else and the session switches to replay: the view shows the state as of that point, and auto-scroll stops so a new event cannot yank you away from what you are reading. ORG-2 deliberately opens historical sessions in replay mode, so opening an old session does not immediately scroll you to its end.

Playback controls

The controls sit in the replay bar under the session:

• Play / Pause — steps forward automatically, and stops on its own at the last event.
• Previous event / Next event — move exactly one event at a time.
• Playback speed — 0.25x, 0.5x, 1x, 2x. The default is 1x, which advances roughly every two seconds; the selected speed divides that interval. Your choice is remembered across sessions.
• The scrubber itself — drag it anywhere in the session. Dragging it back to the end returns you to follow mode.
• Follow / Free browse — pin the view to the agent's current app, or detach and click around the replay yourself while it keeps playing.

Filtering by event type

Long sessions are mostly tool calls. The Filter events control narrows the timeline to one or more categories: All events, Key interactions (messages, questions, approvals, plans), File changes (reads, edits, deletions), Terminal events (shell commands and their output), Explore (searches, globs, directory listings), and Other.

The bottom panel has two tabs, Trajectory and Todo, so you can read the raw event list or just the agent's task list as it evolved.

Reading a turn summary

Where an agent emits one, a Turn Summary card closes out the turn in the chat timeline. It is collapsed by default and shows the tool-call count and wall time (for example, 37 tools · 4m 12s); expand it for the written summary under a SUMMARY heading. The session detail view aggregates the same information as Rounds, Agent worked, Files Changed and an Event Analytics section covering tool usage, token usage, errors and duration.

How replay is stored and streamed

Sessions live in a local SQLite database at ~/.orgii/sessions.db, described in sessions.

Nothing loads a whole session into memory. ORG-2 fetches the lightweight turn index first, then pulls turn bodies on demand: the five most recent turns to start, a prefetch radius of one turn around wherever you scrub, and at most eight historical turn bodies held at a time. Oversized fields — a huge file read, a wall of command output — are stored as payload references with a short preview and fetched in full only when you open them. That is what keeps a multi-hour session watchable.

Replay data stays on your machine unless you explicitly share it, and local sessions never expire on their own.

Sharing a replay with a teammate

Sharing is opt-in and owner-controlled. In an ORG's collaboration settings, Session access has three levels:

Even at Full replay, a teammate clicking a session of yours sends a request; the snapshot transfers only after that. At Session cards only, the request is refused with "This session is shared as metadata only. Full replay is not available."

The app warns you before you enable it, and the warning is worth taking literally: full replay can include prompts, outputs, tool calls and file paths. Only enable it for ORGs you trust. Sharing is also scoped by workspace — nothing is shared until you pick at least one allowed workspace path.

On ORG-2 Cloud, replay uploads are chunked into compressed segments with the live tail kept separate. Session count, monthly replay uploads, and stored replay bytes are unmetered by default, while usage is still recorded for operations. Shares can be either directed at a specific member or issued as an expiring link. See collaboration and cloud for the details.

Agent Blame

Git blame tells you who committed a line. It cannot tell you which agent session produced it, in response to what, or whether it ever reached a commit. Agent Blame is ORG-2's answer: an index that attributes files and commits back to the sessions that touched them. (The board's per-card refresh action is labelled Update AI Blame — same index.)

To use it, select a repo in the sidebar and open the Agent Blame tab. Then:

1. Choose a tier — Metadata only, Details, or Full trajectory.
2. Click Initialize Agent Blame (or Rescan on an existing index) and watch the phase and progress.
3. Read the counters: Sessions, Files, Commits, Entries, Records, plus Sessions by app type and Models used.
4. Use Lookup file sessions — type a file path and get every session that edited it, with its edit count and Applied commits, or No linked commit yet if the work never landed.

Most Attributed Files and Top Sessions rank the repo by attribution. Separately, the AI Impact tab in the Workstation aggregates files touched, functions created, commits influenced and lines attributed across recent sessions, with ratio bars against total git activity.

The index is written to a .orgtrack directory inside the repo, split into a metadata/ half designed to be safe to publish and a histories/ half that is private by default. Tiers matter here: Full trajectory can include raw prompts, tool payloads, file contents and secrets, and ORG-2 asks you to confirm before scanning at that tier.

Note: Agent Blame attributes at the file and commit level, not per line. Inline per-line git blame in the editor is a separate feature, controlled by the editor.showBlame setting.

Next steps

• Sessions — how a session is created, scoped, and steered in the first place
• Collaboration — ORGs, session access levels, and sharing with teammates
• Projects — repos, worktrees, and where session work lands
• Security — what leaves your machine, and what does not