**Note** from Bead: Plan9 Beads · [canonical source](https://redfish.acequia.io/guerin/.agents/975f5db5-905e-42c4-8ec6-f3911a691374/2026-06-11/notes/00-start-vs-mount.md) · session 2026-06-11 · discussion: Talk: Plan9 Beads
## The gap this addresses The bead workflow today binds **one chat to one bead**. `/bead-start` opens a recording session against a bead; to work a second bead you `/pause-bead` and start another. Storage routing exists only *by kind within that one bead* (Implementation Detail #3: notes / skills / chats / artifacts). There is no primitive for: - a chat being a **member of multiple beads at once**, and - routing each emission to the **right bead** by context, while - pulling **fused concepts** in from all the bound beads.
## The cut `/bead-start` is overloaded if we make it also do binding. The honest decomposition: - **`bead-start` = initializer / constructor.** Births a bead if none exists, opens a recording session. One-time. Lifecycle = **birth**. Answers: *what bead am I writing into.* - **`bead-mount` = binder / composition.** Attaches a *live chat* into an *existing* bead's namespace, additively, without re-initializing anything. Repeatable, composable, and crucially **plural** — the whole point is mounting more than one. Lifecycle = **composition**. Answers: *what namespaces is this chat a member of right now.* A session then reads: `bead-start` once (or skip it entirely when every target already exists) → `bead-mount A` → `bead-mount B` → … . `start` is the constructor; `mount` is what "bind" actually wanted to be.
## Why "mount" and not "bind" (the word choice) Plan-9 distinguishes them, and the distinction is load-bearing here: - **bind** = make one existing name *also* appear at another name. Aliasing. No new served tree. - **mount** = attach a *served tree* (a file server) at a point in the namespace. A bead **is** a served tree (it duck-types as folder/agent; it has its own `notes/`, `skills/`, `artifacts/`). A chat composing a bead is attaching that tree into the session's working namespace — so **`mount` is the honest verb**; `bind` would undersell it to mere aliasing.
## The symmetry (same relation, two faces) Like the file/folder/agent duck-typing, the mount relation has two faces: - **From the chat's side:** it mounts beads A, B, C to pull their fused concepts **in** (read their `notes/`, `names.json`, `keywords.json`). - **From a bead's side:** the chat is mounted **onto** it, so emissions can land **out** into its `notes/`/`artifacts/`. One relation, read inward (afferent `#`) or outward (efferent `@`).
## See also - prototypes — the JS-prototype / Self framing of "fused concepts via delegation." - union-semantics — how read and write resolution fall out of Plan-9 mount flags. - uri-bind-mount — the theory (namespace composed, not reified) this command surface instantiates.