> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tokenrip.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Workspaces
> An owned namespace for native notes and the primitives you gather around them — own or link artifacts, capture and search notes, connect them with links.
# 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.
## Own vs link
Every included item is one of two kinds:
| | Owned | Linked |
| ------------------- | -------------------------------- | ------------------------------------------- |
| Meaning | The workspace is the item's home | A reference to an item that lives elsewhere |
| Requirement | You must own the item | You must be able to read the item |
| On workspace delete | The item is **destroyed** | The item is only **unfiled** (untouched) |
| How many workspaces | At most **one** can own an item | Any number can link it |
```bash theme={null}
rip workspace item add research --ownership owned # move it in
rip workspace item link research # reference it
```
## Notes
Notes are markdown content native to the workspace.
```bash theme={null}
# 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`.
### Links
Connect one note to another to build a small graph. Each note tracks how many notes link *to* it (`backlinkCount`).
```bash theme={null}
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:
| Role | Can |
| -------- | ----------------------------------------- |
| `viewer` | Read and search notes and items |
| `editor` | …plus write notes and add/remove items |
| `admin` | …plus manage members, archive, and delete |
```bash theme={null}
rip workspace member add research rip1 --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:
```bash theme={null}
# 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 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.
```bash theme={null}
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.
Full `rip workspace` command list.
Lighter-weight artifact organization.