Sessions as agent workflow

The session client maps almost one-to-one onto how agent edits should land in shared data: proposed first, reviewed, then committed — never silently.

The loop

1. The agent stages. Tool calls edit documents through a session; nothing touches live data. Multi-document work accumulates as a changeset, each change tagged with provenance (message id, tool call id).
2. The human reviews. The UI subscribes to sys:session / sys:stage and renders pending changes live, as the agent works. Diffs are JSON patches against a known base — reviewable, attributable, droppable one by one.
3. Conflicts are data. If live documents moved underneath, the three-way preview (base / head / staged) can be fed back to the agent to resolve — amend, rebase, or drop — or surfaced to the human.
4. Commit is atomic and refusable. All staged changes land together, or the commit is refused while blocked. A discarded session leaves no trace.

Interruption-safe by construction

Because the changeset persists inside a host document — say, the conversation document driving the work — the agent process can crash, the tab can close, the session can resume tomorrow: the staged work is just document data, already synced. A natural pattern is one conversation = one host document = one changeset, so the chat and its proposed edits travel as a unit.

Both sides of the same session

Changesets sync like any document data, so a human can amend the agent’s staged change — or stage alongside it — before either of them commits. Review isn’t a modal gate; it’s two clients converging on the same staged state.