The session client

The live client sends every change immediately. That’s right for direct manipulation, but wrong for work that should be reviewed before it lands — an AI agent drafting edits across several documents, a form with a save button, a batch refactoring of a diagram. The session client adds a staging layer for exactly that.

Stage → review → commit

A session wraps the live client. Through it you edit documents as usual, but changes are staged, not sent:

Reads through the session show the staged view — live state with your staged changes overlaid. (You can also ask for the live-only view.)
Each staged document records the base it was edited from: its sequence number and a snapshot at staging time.
The live document keeps flowing underneath; the session can tell you at any moment whether the head has moved in a way that conflicts with your staged work.

When ready, commit() writes all staged changes atomically — all stages land or none do, and a commit is refused while any stage is blocked by a conflict. Or walk away: discard the session and nothing ever hits the live documents.

The changeset lives in a document

Here’s the datadata twist: a session’s state — its changeset — is persisted inside a host document, in a dedicated field. Because the changeset is just document data:

It survives reload. Reopen the session and the staged work is still there.
It syncs. Two collaborators (or a human and an agent) can see and contribute to the same staged changeset, converging like any other concurrent document edit.
It’s inspectable through the synthesized sys:session and sys:stage documents, like everything else in datadata.

A natural host is the document that motivates the changes — for example, an AI conversation document hosting the changeset of edits the conversation is producing.