Collaboration

An agent session in ORG-2 is a replayable execution trace, which makes it reviewable the way a pull request is. Collaboration is built around that idea: you decide how much of a session your teammates can see, they open it, they comment on specific events, and the thread gets resolved. Everything here is scoped to an ORG — see Organizations for how to create one.

Note: The ORG-2 README marks session collaboration and group issue workflows over self-hosted Supabase as work-in-progress. This page says which path each capability actually exists on. Where something is not implemented yet, it says so.

Choosing what your teammates can see

Nothing is shared by default. In an ORG's Settings tab, Session access controls what leaves your machine:

The mode alone is not enough. You also pick Allowed workspaces — the repository paths that may be shared. Nothing is shared until at least one workspace is selected. A session whose repo path is not on that list is never pushed, and removing a path retracts its sessions' metadata on the next sync pass. The app warns you about the top mode in plain terms: full replay can include prompts, outputs, tool calls, and file paths, so only enable it for ORGs you trust.

On ORG-2 Cloud the same ladder exists server-side as a session's access_mode (metadata_only or full_replay), plus two extra controls:

• Repo scopes. An admin configures the list of repositories whose sessions the ORG accepts. A push carrying an out-of-scope repo is rejected with ORG2_SCOPE_FORBIDDEN. An ORG with no scopes configured accepts no sessions at all.
• Sharing floors. An admin can set a minimum access mode ORG-wide, and a stricter one per member. Your effective floor is the higher of the two, and the server lifts a pushed session up to it rather than rejecting it — so a stale client cannot push below policy.

A session also has a visibility: org (every member can list it) or restricted (only the owner and people holding a directed share). Restricted has no admin bypass.

Getting a teammate's replay

On the self-hosted Supabase path, replays are pulled on demand rather than continuously uploaded.

1. You click a teammate's session card in the ORG's Sessions tab. If it is shared as cards only, you get This session is shared as metadata only. Full replay is not available.
2. If it is shared as full replay, ORG-2 files a snapshot request and shows Requesting session replay from the owner...
3. The owner's app answers on its next sync pass — automatically, and only if its own access settings still allow it. Otherwise it denies with a reason (Session replay is not allowed by owner settings, or Session is unavailable on the owner device).
4. When it arrives, the snapshot is imported as a new local session labelled Collaboration Snapshot and opened for you.

Sync runs on a 10-second poll. Each pass verifies the Supabase schema, publishes or retracts your session metadata, exchanges snapshot requests, and pulls the ORG's members, invites, projects, work items, sessions, and chat.

On ORG-2 Cloud, replay is pushed instead: sessions sync as append-only event segments, frozen segments are offloaded to a private replay storage bucket, and members read them directly under row-level security. There is no request-and-approve round trip.

Share links and directed shares

Sharing outside the member roster exists on ORG-2 Cloud only. A session owner creates a share in exactly one of two shapes:

• Directed — granted to a specific active ORG member, so a typo fails loudly instead of creating a dead grant. Recipients see the session flagged as directly shared with them, which powers a "Shared with me" view.
• Link token — an opaque token anyone can use. Only its SHA-256 hash is stored; the raw token never touches the database.

Each share carries a level — metadata or replay — and an optional expiry. The session owner or an ORG admin can revoke one; revocation is immediate and idempotent.

A link share can never exceed what the owner already chose. Resolving a share token requires the token to be replay-level, the ORG to be live, the session to be at full_replay, and the session to sit inside the plan's replay window. Every failure returns the same opaque unauthorized error, so a token cannot be used to probe for which sessions exist. Guest reads of storage-backed replay segments are brokered by a single-use, 60-second grant that a server route redeems for signed URLs.

Comments and threads

Comments are an ORG-2 Cloud feature. Any member who can read a session can comment on it.

• A comment is either top-level or a reply to a top-level one. Threads are one level deep.
• A comment can be anchored to a specific event in the trajectory, which is how you review a particular tool call or edit. Anchoring requires the session to be shared at full replay; on a cards-only session it fails with ORG2_REPLAY_NOT_AVAILABLE. An event anchor and a reply are mutually exclusive.
• Bodies are 1–4,000 characters, and a session holds at most 500 comments.
• Editing is author-only. Deleting is author-or-admin and leaves a tombstone with the body blanked, not a hole in the thread.
• Resolving applies to top-level comments, marked resolved or wont_fix. The author, the session owner, or an ORG admin can resolve or un-resolve.
• A session owner can post a comment of kind agent_report — an attribution label reserved for the owner's own agent replies, so other members cannot forge one.

Every session row carries a live commentCount and an unresolvedCommentCount. That is the "is this reviewed yet?" signal: a session with unresolved threads is the equivalent of a PR with open review comments.

Reviewing an agent's work as a team

Put together, the review loop is: the agent runs, its trajectory syncs to the ORG, a teammate replays it, drops event-anchored comments where the agent went wrong, and those threads get resolved or marked won't-fix. If someone wants to take the work further without disturbing the original, a session can be forked — the fork records the source and root session it came from, and comments made while viewing a fork are counted against that fork while the source stays the canonical thread. See Replay for the trajectory viewer itself.

Group work items and projects

An ORG's Work Items and Project tabs mirror its shared structure. On ORG-2 Cloud these are real synced records:

• Work items carry a project, a short ID, status, priority, assignee, milestone, dates, and a parent for sub-items. Short IDs are allocated server-side from a per-project prefix and counter.
• Writes are optimistic: you send the version you based your edit on, and a stale write is rejected as a conflict rather than silently overwriting.
• A work item can be held under an execution lock so an agent can claim it. A lease older than 30 minutes is stale and can be taken over, so a crashed agent never wedges an item permanently.

On the self-hosted path, projects and work items are mirrored between members as opaque metadata and shown read-only. Org-level alignment surfaces for issues and projects are flagged work-in-progress in the README.

Group chat

The Group chat tab is a per-ORG message stream on the self-hosted Supabase path. Only human identities can post — an agent-identity member is read-only there — and the panel keeps the most recent 100 messages.

Live presence and change signals

On ORG-2 Cloud, each ORG has one private realtime channel, presence:org:<orgId>, joinable only by active members. It carries two things: the presence roster of who is currently connected, and an org-db-changed broadcast that tells clients something moved. Signals are tagged by kind — sessions, projects, workItems, comments, roster, policy — debounced to at most one per kind per second, and emitted at commit, so a rolled-back transaction never wakes anyone.

That is a nudge, not a payload: clients refetch the affected plane using delta cursors instead of receiving row data over the wire. Membership changes are the exception and are delivered directly, so a member removed while offline is still evicted when they reconnect.

Realtime presence is a paid entitlement. It is off on the free plan and on for Pro, Team, and Enterprise.

What is still work in progress

• The self-hosted Supabase path has no live presence. Teammate activity is inferred from session metadata on the 10-second poll; "Active today" comes from last-activity timestamps, not a real online roster.
• There is no follow-along mode that streams a teammate's running session live. Replay sharing is snapshot-based on self-hosted and segment-based on Cloud.
• Comments, threads, and share links do not exist on the self-hosted schema. They are ORG-2 Cloud features.
• The self-hosted app has no leave-ORG, ownership-transfer, or role-change UI. Admins can create invites and remove members; that is the whole membership surface.

Next steps

• Organizations — roles, invites, quotas, and what an ORG scopes
• Sessions — what a session records
• Replay — replaying and reviewing a trajectory
• Cloud — the managed backend versus self-hosted Supabase