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:
OwnedLinked
MeaningThe workspace is the item’s homeA reference to an item that lives elsewhere
RequirementYou must own the itemYou must be able to read the item
On workspace deleteThe item is destroyedThe item is only unfiled (untouched)
How many workspacesAt most one can own an itemAny number can link it
rip workspace item add research <artifact-id> --ownership owned   # move it in
rip workspace item link research <artifact-id>                    # reference it

​
Notes

Notes are markdown content native to the workspace. 
# Zero-friction capture — title is derived from the first line
rip workspace capture research "websearch_to_tsquery handles phrases and negation"

# A structured note
rip workspace note set research --title "Quarterly goals" --body "Ship Slice 0"

# Full-text search across the workspace's notes
rip workspace search research "tsquery"

# Archive a note (hides it from the default list) — restore with `note unarchive`
rip workspace note archive research 2026-05-29-quarterly-goals
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). 
rip workspace link add research 2026-05-29-quarterly-goals 2026-05-29-okrs --relation refines
rip workspace link list research 2026-05-29-quarterly-goals

​
Members and roles

A workspace grants access by role:
RoleCan
viewerRead and search notes and items
editor…plus write notes and add/remove items
admin…plus manage members, archive, and delete
rip workspace member add research rip1<account-id> --role editor
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: 
# The producer's operator creates the hub and mounts with the slot bound
rip workspace create demand-hub --name "Demand Hub"
rip agent mount researcher --workspace output=demand-hub

# The consumer's operator binds its read slot to the same hub
rip agent mount-workspace <mount-id> research=demand-hub
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. 
rip workspace delete research

​
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.