Collaboration
Content pieces are collaborative documents. Your team edits together in real time, outside reviewers comment through share links, and every change lands as something the owner can see, accept, or reject.
Real-time co-editing
Open the same piece as a teammate and you are in the same document: edits sync live, and everyone's cursor shows with their name beside it. There is no locking and no "someone else is editing" banner - the document merges concurrent edits automatically, and autosave continues to work exactly as it does solo.
If the realtime connection drops (a deploy, a network blip), the editor keeps working locally and syncs back when the connection returns. Nothing typed is lost either way.
Access levels
Three levels, enforced everywhere (editor, comments, API):
| Level | Who can have it | What it allows |
|---|---|---|
| Editor | Members, email invites, link holders | Write, suggest, and comment. Editors pick between Editing and Suggesting mode in the editor. |
| Commenter | Members, email invites, link holders | Read and comment. No editing and no suggesting. |
| Viewer | Members, email invites, link holders | Read only. |
Workspace members default to Editor on every piece; any member can be narrowed (or denied) per document. External people (email invites and share links) can hold any of the three levels, so a founder or freelancer can genuinely edit without joining the workspace. Share-link editors work in a plain document view without the AI surfaces (no completions, ⌘K, or assistant). Published pieces are locked for everyone - no edits, no new comments.
Media is owner territory: collaborators with edit access change the text, but the images and video that would publish with the piece (thread attachments, pins) can only be changed by the piece's owner.
Sharing a piece
Share on a content piece opens the sharing dialog:
- Add people - search workspace members by name, or type any email to invite someone external, up to 10 at a time, each with a role (Editor, Commenter, or Viewer) and an optional email notification.
- People with access - every member and invite with a per-person role dropdown. Members can be set to No access to deny them this one document; external invites can be removed.
- General access - the piece's link mode: Restricted (only people explicitly added), Workspace (every member), or Anyone with the link, each with a role.
- Expiry and regenerate - public links default to 30 days, email invites to 14; pick 14, 30, 90 days, or Never. Regenerating a link invalidates the old URL immediately, and access derived from a revoked link goes with it.
Individual members can also be denied on a specific piece, overriding the team baseline for that document.
Shared with you
When someone outside your workspace shares a piece with you, you get a notification and an email with a direct link - you work on it from your account without joining their workspace. The owner can revoke access at any time from the sharing dialog.
Comments
Select text in the editor and add a comment - it anchors to that passage and shows in the margin beside it. Threads support replies and Resolve; resolved threads leave the margin but stay in the piece's history.
Anchors are durable: they follow the text through edits and re-attach after heavy rewrites, so a comment about a sentence stays with that sentence. Content types without a rich editor (X threads) get document-level comments instead - same threads, replies, and resolve, anchored to the piece rather than a text range.
Commenting requires Commenter access or better, and locks when the piece publishes.
Suggestions
Editors can switch the editor from Editing to Suggesting mode. In Suggesting, changes are recorded as tracked suggestions instead of direct edits: insertions and deletions render inline in each author's color, and every suggestion opens its own thread in the margin.
Anyone with edit access reviews them from that thread: accept or reject, with a comment trail attached, and accepting resolves the thread. Suggesting requires edit access; a Commenter can discuss but not propose tracked changes. Publishing resolves any still-pending suggestions to the accepted text, and refuses to ship a piece the resolution would leave empty.
Review requests and approval
Contributors can request review on a piece (over MCP with request_review, or through the API); every manager is notified, the content list marks the piece as awaiting review, and a manager approving it flips the status to ready. Workspaces that turn on Require approval before publishing (on the Anti-Slop Guard page) refuse to publish or schedule anything a manager hasn't approved, including through the API and the scheduler.