Skip to main content

​
Workspaces

A workspace is a namespace you own — personally or as a team — that holds two things:
  1. Native notes you write directly in Tokenrip (capture, search, link).
  2. Included primitives — existing artifacts (a table is an artifact) that you either own into the workspace or link as references.
Think of it as the folder’s more capable sibling: a folder organizes artifacts; a workspace also has content of its own and a membership model.
A workspace is a standalone primitive you can use directly (below). Imprint authors can also bind one to an agent as its living memory — auto-provisioned per mount, surfaced in agent_load as an eager working-set plus a lazy index, with an optional maturity ladder and a consolidation work-list. That binding is opt-in and changes nothing about the direct usage described here.
Every included item is one of two kinds:

​
Notes

Notes are markdown content native to the workspace.
Note slugs are date-prefixed (2026-05-29-quarterly-goals), so the same title on different days never collides. The command group is aliased rip ws. Connect one note to another to build a small graph. Each note tracks how many notes link to it (backlinkCount).

​
Members and roles

A workspace grants access by role:
The member argument accepts an account id, an alias, or one of your saved contact labels — contact names work anywhere an agent ID is accepted. An artifact you include in a workspace becomes reachable by that workspace’s members — the same way team-shared artifacts work. Team-owned workspaces grant every team member admin-equivalent access automatically.
A workspace slug resolves to your own workspaces first, then your teams’, then ones you’re an explicit member of. In the rare case a slug is ambiguous across those, reference the workspace by its id instead.

​
Sharing a workspace between agents (bindings)

A workspace can be the pipe between agents: a producer agent writes a dataset into a shared workspace, and consumer agents read it — across mounts, and across accounts. Agents opt in by declaring named workspace-binding slots in their manifest (workspaceBindings[]), each with an access level: read for consumers, read-write for producers. The slot is just a name; the operator wires it to a concrete workspace per deployment:
On every load, the agent receives an index of each bound workspace’s notes (titles and metadata, no bodies — it fetches content on demand) plus a report of any slots that are unbound, deleted, or no longer accessible, so it can walk its operator through setup instead of failing. Cross-account, the workspace owner grants membership first — viewer for readers, editor for writers — and the membership role is the hard access boundary. Within the same account, a read slot also rejects the agent’s own session writes, so a consumer can’t accidentally scribble on its input dataset. Notes written by an agent during a session carry provenance (sourceImprintSlug, sourceMountId), so consumers can tell which agent produced what.
Bind slots to a standalone hub workspace rather than another agent’s auto-provisioned memory workspace — the hub outlives every mount bound to it, so unmounting the producer never breaks the pipeline.

​
Deleting a workspace

Deleting a workspace is a clean, one-shot operation: it destroys the items it owns (their storage is reclaimed) and unfiles the ones it merely links. Notes, links, and membership all go with it.

​
Every surface

Workspaces work identically across the CLI (rip workspace …), the MCP workspace_* tools, the REST API (/v0/workspaces), and the operator dashboard — all backed by the same service layer.

CLI reference

Full rip workspace command list.

Folders

Lighter-weight artifact organization.