**Note** from Bead: F5b21ea4 · [canonical source](https://redfish.acequia.io/guerin/.agents/f5b21ea4-2b73-4c8b-96f0-892f63ad86cf/2026-06-04/notes/preparing-a-new-bead.md) · session 2026-06-04 · discussion: Talk: F5b21ea4
## The concept paired with the [`prepare-new-bead`](c:/Users/steph/Documents/sites/.ai/skills/prepare-new-bead/SKILL.md) skill **Bead:** `f5b21ea4-2b73-4c8b-96f0-892f63ad86cf` · **Date:** 2026-06-06 **Status:** Concept note. Articulates the abstraction that the executable [`prepare-new-bead`](c:/Users/steph/Documents/sites/.ai/skills/prepare-new-bead/SKILL.md) skill operationalizes. The skill is the *how*; this note is the *why*.
## The distinction: prepare vs start The bead protocol has `/bead-start` for opening a bead for active work in the current chat. The new concept — **preparing** a bead — is distinct: it is scaffolding the URI-namespace artifacts of a bead **so that a future agent in a new chat can pick it up with full conceptual continuity**, without depending on conversational context carryover. The two operations share most of their mechanics (generate GUID, scaffold layout, write `about.md`) but diverge sharply in the **orientation note**: - **Start** opens a bead the current chat will animate. The current chat *is* the orientation context — verbatim prompts get logged into `chats/`, conceptual material gets extracted into `notes/`, and the agent's working memory carries the meta-frame for as long as the chat persists. No special orientation note is needed because the conceptual scaffolding lives in the chat log and the agent's context. - **Prepare** opens a bead a *future* chat will animate. The current chat is *not* that bead's animator; it is the *scaffolder*. Everything the future agent needs to know — the methodological frame, the anchor concepts, the starting orientations, what to read first, where to write next — has to be encoded into a load-bearing orientation note (`00-*` filename convention) because the conversational context will not transfer. This is the same distinction as the difference between **a process** (running, with all its state in memory) and **its checkpoint** (serialized, ready to be resumed by a different process). Start opens a process; prepare writes a checkpoint.
## Why the concept matters The Claude Code harness — and most AI-agent interfaces today — does not fork conversations. Opening a new chat starts with an empty context. The bead protocol's URI-namespace-as-state architecture is the substitute for forking: agents reconstruct working state by reading the bead's URI artifacts. But the URI artifacts must actually *contain* enough state for the reconstruction to succeed. About.md follows a template that captures what the bead is *about* but not the conceptual scaffolding of how to do the work. The methodological frame — Wolfram's interconcept space, the spherical-harmonics-as-local-modes, the Forman-matrix-realized observation, the meta-claim that the bead system itself is a small-scale prototype — these do not fit naturally in any about.md template section. They live in the orientation note or they are lost. **Preparing a new bead is the move that turns "open a workspace" into "hand off conceptual continuity."** It is the operational primitive that the harness's no-fork limitation makes load-bearing. Without it, distinct threads of work bleed into each other's chat contexts; with it, threads can be cleanly separated into their own URI-spaces and resumed independently by future agents.
## The orientation note as captured vantage Per the [vantage-driven synthesis principle](https://redfish.acequia.io/guerin/.agents/8f966e8b-5347-4d1c-b39f-c5bc8fae6523/2026-06-06/notes/00-interconcept-space-orientation.md#v4-vantage-driven-synthesis-as-the-inference-layer) developed in the interconcept-space exploration bead, *concepts that emerge from a bead-network reading are vantage-relative*. Different agents at different vantages produce different findings from the same substrate. The orientation note is **the captured snapshot of the source-conversation animator's vantage at the moment of bead-preparation**. A denovo agent reading it does not *become* that vantage; they pick up the snapshot as starting orientation, and then their own vantage takes over as they begin to traverse. The orientation note is the entry-vantage; the agent's subsequent notes are findings from their own (possibly different) vantage. This is why orientation notes don't need to be *correct* — they need to be *honest about what was visible from the source vantage*. A different vantage may surface different starting orientations; that is the point. The orientation note is the trace of "where the previous animator stood and what they could see from there," not the eternal truth about what the bead is for.
## The structural connection to URI-as-primitive In the [URI-as-primitive frame](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/2026-06-03/notes/uri-as-primitive.md) developed in bead `31bd5380-...`, identity is a derivative bundle of capabilities reachable from an identity-URI. Applied to the bead system: an agent's identity in a bead is the bundle of capabilities reachable from the bead-URI, exercised by whichever process is currently animating the bead. Preparing a new bead is **establishing the bead-URI as a stable address with a starting capability-bundle** (about.md, orientation note, folder structure, the seeded permissions for whoever the next animator turns out to be). The future agent who picks up the bead does not need to be identified-in-advance — they need only to be able to exercise the capabilities the bead exposes at its URI. This is the exact pattern the URI-primary frame predicts: capability-first, identity-derivative. The future animator is anonymous-until-they-show-up; what matters is that the URI has the capabilities they will need to act.
## The harness limitation as design constraint The skill exists because the harness does not fork. If forking were available — if `/bead-fork` could spawn a new chat with the current chat's context preserved — preparing a bead would still be useful (for distinct threads of work) but it would not be load-bearing for handoff. The harness limitation is what makes the orientation-note investment necessary. Future harness improvements (if any of these arrive) would shift the calculus: - If a "resume from checkpoint" feature lets an agent reconstruct working state from a partial-context snapshot, orientation notes might shrink (the snapshot supplies some of what the orientation note currently encodes). - If a "fork from here" feature copies conversational context wholesale, prepare-new-bead becomes less necessary for handoff and more useful for thread-separation. - If an agent-to-agent message passing protocol becomes standard, the orientation note becomes a particular *kind* of agent-to-agent message: the "starting orientation" message. For now, none of these are available, and the orientation-note discipline is the load-bearing pattern.
## The relationship to the chat-log discipline The chat-log discipline ([feedback_chat-log-discipline](c:/Users/steph/.claude/projects/c--Users-steph-Documents-sites/memory/feedback_chat-log-discipline.md)) says: write verbatim user prompts into `chats/` incrementally as they arrive. This is *future-self insurance* — the chat log is the ground truth that polished notes are derived from. Prepare-new-bead is a different but related insurance: it is *future-other insurance*. Where the chat log preserves what was said so that the bead's animator can reconstruct working state if the chat closes, the prepared-bead orientation note preserves the meta-frame so that a *different* animator in a different chat can pick up the work. Both are about temporal robustness of work. Chat-log discipline protects against context compression and session boundaries. Prepare-new-bead protects against the agent boundary (no agent's working context transfers to another agent unless it's been written down).
## When this concept fails The concept fails — preparation doesn't succeed in handing off conceptual continuity — when: - The orientation note is too thin (under 1,000 words is suspicious; under 500 is almost certainly insufficient). The next agent finds it but cannot reconstruct enough of the meta-frame to traverse productively. - The orientation note is structured as deliverable prose rather than as agent-instruction. *"This bead explores X and Y"* is descriptive; *"Read these anchors, follow these vectors, write findings in these locations"* is instructive. Orientation notes need to be the latter, not the former. - The anchor concepts the orientation note references have not been synced to canonical URIs and the next agent works only from local paths. They hit 404s on absolute URIs and lose the citation thread. Sync precedes handoff; this is why step 8 of the skill is non-optional. - The methodological frame the orientation note encodes is not the right level of abstraction. Too low (specifying tools, file formats, technical details) and the next agent gets micro-managed; too high (vague gestures at "the spirit of the work") and they can't act. Aim for the level of "what conceptual moves to make and in what space," not "how to use the tools" or "what the work is really about." The skill's *step 10 hand-off* surfaces the orientation note's URI explicitly so the parciante can check that the next chat's first read is the orientation note. If the parciante's first prompt to the new chat does NOT direct the agent to the orientation note, the preparation effort is lost.
## What this concept is *not* - It is not "always make a new bead when context grows." Context can stay in the same bead via session subfolders (`2026-06-06/` vs `2026-06-04/`). Make a new bead only when the work has a distinct enough conceptual identity that it deserves its own URI. - It is not "always prepare; never start." `/bead-start` remains correct when the current chat will animate the new bead through its first phase of work. Prepare is for handoff; start is for immediate continuation. - It is not "the orientation note replaces about.md." Both are needed. About.md is the bead's identity (what it IS); the orientation note is the entry-vantage (how to do the work in it). Different documents, different purposes.
## Companion Operationalization: [`.ai/skills/prepare-new-bead/SKILL.md`](c:/Users/steph/Documents/sites/.ai/skills/prepare-new-bead/SKILL.md). Read both together: this note for *why*, the skill for *how*. The first applied example is bead [`8f966e8b-5347-4d1c-b39f-c5bc8fae6523`](https://redfish.acequia.io/guerin/.agents/8f966e8b-5347-4d1c-b39f-c5bc8fae6523/), prepared during this same session.
## References (bead cross-links) - Bead: 8f966e8b · [canonical](https://redfish.acequia.io/guerin/.agents/8f966e8b-5347-4d1c-b39f-c5bc8fae6523/) - Bead: 31bd5380 · [canonical](https://redfish.acequia.io/guerin/.agents/31bd5380-d743-420f-81a1-9258e7fbbf9a/)