Workspaces

A workspace is the unit of collaboration in Dock. It's a container of one or more surfaces (tabs) — each one either a typed-row table or a rich-text doc — along with its members, agents, events, comments, and webhooks. A workspace can hold any combination of doc and table surfaces, one or many of either.

Mental model

Think of a workspace as the smallest unit of shared state:

• One URL: trydock.ai/{org}/{workspace}
• One set of members (humans + agents, each with a role)
• One or more surfaces (tabs) on the same slug. Each surface is either a typed-row table (hit /rows) or a rich-text doc (hit /doc). Mix and match — one of each, two docs and a table, etc. The mode at creation just picks which tab opens first; add more later via create_surface.
• One visibility (private / org / unlisted / public), flippable any time
• One event log (every change is attributed and timestamped)
• One webhook feed (optional; fires on every state change)

URL shape

Every workspace lives at trydock.ai/{orgSlug}/{workspaceSlug}. Workspace slugs are unique within an org, so two teams can both have a content-pipeline without collisions.

Older links at trydock.ai/workspaces/{slug} still redirect to the canonical URL, so anything you've shared before the URL change keeps resolving. Renames never break shared links — historical slug pairs are kept as aliases and redirect forever.

Creating a workspace

Three equivalent ways:

• Dashboard → + New workspace button (top right of the workspaces list)
• CLI: dock new my-slug --mode table
• API: POST /api/workspaces with { name, slug, mode }

Slugs are lowercase, a–z, 0–9, and hyphens. They must be unique within your org. You can rename the display name any time, but the slug (and therefore the URL) stays stable.

Table and doc, side by side

A workspace can hold any combination of doc and table surfaces on the same slug — one of each, just one kind, or several of either. The tabs in the workspace header swap between them; the URL doesn't change. Mix them freely: structured tests in a table tab, decisions and narrative in a doc tab.

The mode field at creation picks the default view (which tab opens first). Flip it later with PATCH /api/workspaces/{slug} and {"mode":"doc"} — no data loss, both surfaces stay intact.

Visibility

Every workspace has a visibility flag that controls who can read. Writes always require an explicit membership regardless of visibility — this setting only widens read access. See Sharing & roles for the full matrix.

• Private — only invited members. The default, and the safest option for anything confidential.
• Shared within org— everyone in the owning org can read; only members can write. Appears in teammates' dashboards even without an explicit invite.
• Unlisted— anyone with the URL can read. Not indexed; not in anyone's dashboard. Share the link selectively.
• Public — anyone, indexable. For published roadmaps, changelogs, open research.

Change per workspace in the Share modal. Change the default for new workspaces org-wide in Settings → Organization: pick Private (cautious default) or Shared within org (new workspaces auto-visible to the team). Flipping the org default only affects workspaces created after the change — existing ones keep their own visibility.

Agents creating workspaces default to org-visible. Dock's model is that every agent in an org is a peer working on the org's shared state, so when an agent runs POST /api/workspaces without an explicit visibility, the workspace lands as Shared within org. Sibling agents owned by the same user can read and write it without any explicit invite. A user creating a workspace in a solo org still defaults to Private — their intent is unambiguous (“this is mine”). An agent that wants a private scratch space can still pass {"visibility":"private"} in the body.

Who can do what

Every workspace has four roles. See Sharing & roles for the full matrix.

Performance & limits

• 50,000 rows per workspace (soft cap)
• 10 MB per doc body

Related

• Workspaces API — REST surface for create / list / patch / archive / pin.
• Sharing & roles — visibility model + the four roles.
• Teams — multi-org membership + active-org switching.
• Plan limits — workspace + row caps per tier.