Sessions & Collaboration

A Workspace is a durable desk: files, tools, issues, and git history. A Session is one particular agent conversation working at that desk. Several Sessions can use the same Workspace without becoming the same coworker.

OpenAlice gives every Session a stable resumeId, such as:

resume-calm-amber-river-a1b2c3

The visible form is @resumeId. That signature is the product-level answer to “who produced this?” and the handle OpenAlice uses to continue the exact conversation later.

The identity layers

A new worker in the same Workspace receives a new resumeId. A later turn in the same conversation keeps the existing resumeId but receives a new taskId. OpenAlice never exposes the runtime-native continuation id as its public protocol.

Signatures and provenance

OpenAlice stamps structured actions from the authoritative Session context. An agent does not submit its own identity in an Inbox, Issue, or trade tool call.

Standalone Markdown can carry the same attribution visibly:

---

Signed-by: @resume-calm-amber-river-a1b2c3

The Web UI recognizes the signature and can open the corresponding Session. Reports published through Inbox also receive a content revision hash, so OpenAlice can distinguish the bytes that were sent from later edits to the live file.

Exact, unavailable, or reconstructed

All follow-up surfaces use the same rule:

1. If an artifact has a known resumeId, continue that exact Session.
2. If the Session is retired, departed, purged, or missing its native continuation, preserve the attribution and report that it is unavailable. Do not impersonate it with a replacement.
3. If only the Workspace is known, recruit a new Session there and label the answer reconstructed.
4. If even the Workspace is unknown, return unavailable rather than guessing.

This distinction matters when a report has changed since publication, an Issue has a different current owner from its creator, or an old Workspace has been offboarded.

Ask the responsible Session

The product exposes provenance through business objects rather than making users copy runtime ids:

• Inbox: ask the sender, or ask the Workspace to reconstruct when no sender Session was recorded.
• Issue: ask the creator, the declared Session owner, or one selected scheduled run.
• Signed Markdown: open the exact @resumeId linked from the document.
• Trade decision: attribute the decision Session separately from human approval and UTA/broker execution evidence.

Agents can use the same model from alice-workspace:

alice-workspace inbox ask --id <entryId> --prompt "Why did you send this?" --await
alice-workspace issue ask --id <issueId> --creator --prompt "What was the original intent?" --await
alice-workspace issue ask --id <issueId> --owner --prompt "What should happen next?" --await
alice-workspace conversation ask --resume-id <resumeId> --prompt "Re-check the thesis" --await

For several independent peers, dispatch the questions first and then collect their task ids together. That lets the runs overlap instead of manufacturing shell sleep loops.

WebPi · Beta

Pi Sessions can switch between the native terminal and WebPi, a browser conversation surface. Both views use the same OpenAlice Session and Pi JSONL history; WebPi is a renderer over Pi's documented RPC mode, not a second OpenAlice message store.

Use the WebPi · Beta action from a running Pi Session to open it in the browser. You can switch back to the TUI without creating a new coworker or losing the resumeId. Claude Code, Codex, and opencode continue to use their native terminal surfaces.

Next Steps

• Lifecycle & Offboarding — See what happens to Sessions when a Workspace departs.
• Issue Board — Choose between a stable Session owner and a fresh Workspace worker.
• Inbox — Deliver revision-stamped reports and ask their sender.
• Automation — Understand taskId, resumeId, and scheduled execution.