**Note** from Bead: 874fce5b · [canonical source](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/beads.md) · session 2026-04-23 · discussion: Talk: 874fce5b
**Date:** 2026-04-23 **Context:** Architecture chat, Claude Code. Extends [self-assembling-wires/ecology.md](self-assembling-wires/ecology.md), [polarized-links.md](polarized-links.md), [rewiring-cognition.md](rewiring-cognition.md). See [../chats/2026-04-23-ecology-architecture-chat.md](../chats/2026-04-23-ecology-architecture-chat.md).
## The claim A bead in the ecology is **an agent**. Not a static knowledge chunk, not a cached JSON blob, not a file at a path. Passive data cannot polarize, negotiate its surface, apoptose, or participate in the advanced wave. Only agents can. Therefore: every node in the network is an agent; the network is a population of **modular agents** that chain into conduits under structured demand. Each bead-agent is: - Small (one thing, not a bundle) - Addressable (has a URI) - Polarizable (can align with a demand gradient and participate in a shooter) - Active (responds to requests, maintains its own state, can emit and acknowledge advanced-wave signals) - Composable (chains with neighboring beads to form wires) - Recruitable (pulled from the reservoir when needed, returned when apoptosis happens) This is the node-level companion to [polarized-links.md](polarized-links.md): links are the wires, **beads are the agents the wires are made of**. The Hubler experiment's ball bearings become bead-agents when we apply the frame to the ecology. A file at a URI is not a bead; it is at most a passive substrate that an agent-bead might expose or reference. The agent is what participates.
## Three starter examples | Bead-agent | Primary role | Backing | Time-scale | |---|---|---|---| | "Where is Stephen" | State / spatial | An agent over phone GPS, calendar, check-ins, geo.camera's location route | Real-time, updates constantly | | "What tabs are open on his browser + current tab" | State / attentional | An agent in a browser extension, or one using the debug protocol, reporting observed DOM | Real-time, event-driven | | "An acequia extension" | Capability | The Chrome extension itself, an agent that bridges claude-browser memory into WebDAV URIs | Active when invoked; transform-heavy | None of these is data at rest. Each is an active process that responds to a GET (or richer request) by producing a current answer. The underlying sources may be sensors, files, databases, other agents, or LLM synthesis — the bead is the agent that reads or computes over them and responds.
## Bead-agent roles (not exhaustive) Every bead is an agent. The role labels below describe what the agent *primarily does*, not what it *is*: - **State-reporters** — primarily answer "what is the current value of X?" Example agents: location, current tab, battery level, acequia group membership, active chat. - **Memory-custodians** — hold persistent content and serve it (with apoptotic lifecycle). Backed by files, WebDAV resources, or their own storage, but the *agent* is what participates in the network. Example: a notes-agent that serves [../notes/](.); a chat-archive agent. - **Transform-executors** — do something when invoked. Verb-heavy (PUT/POST). Example: the bookmark-extractor skill-agent, the oracle-proxy in `redfish.acequia.io/dev/gsd-landscape-ai-talk-agent/`, a "summarize" agent, a "convert-units" agent. - **Sensor-streams** — continuously emit updates. Often WebSocket / SSE / WebRTC-backed. Example: camera feed, microphone, accelerometer, heartbeat. Physical analogue: a bearing in motion. - **Actuators** — cause side effects when invoked. PUT with intent. Example: "turn on projector", `PUT /room/A/projection?source=B`, "send message", "commit patch". - **Composites** — agents that internally chain other beads before responding. Look like a single bead from outside; polarize differently based on the request. Example: the gsd-landscape-ai-talk-agent is a composite (oracle-proxy + provenance + ledger). The taxonomy is for human navigation. At the physics level, a bead is a bead: polarize, chain, conduct, apoptose. Roles are emergent properties of which requests the bead responds to best.
## Agents, not data A file at a URI is not a bead. It is at most a passive substrate that a bead-agent may expose, reference, or persist into. Three reasons this matters: - **Polarization requires activity.** A GET on a static file returns bytes; it cannot decide to synthesize a representation tuned to the requester, emit advanced-wave acknowledgments, or participate in a negotiated handshake. - **Apoptosis requires agency.** Policy-driven self-termination is a thing only a live process can do. Files are reference-counted at best; they cannot apoptose. - **Advanced-wave flow requires reception.** Files cannot receive or ledger the reputation/attention/wealth that flows back through a transaction. They cannot consent to be bound, re-bound, or retired. This means: when you design a resource in this ecology, the design question isn't "where does this file live?" but "what agent is responsible for serving this URI, and how does it behave?"
## What makes a good bead - **Single responsibility.** "Where is Stephen" is a good bead. "Where is Stephen and what is he doing and who is he with" is three beads that should be composable. - **Polarity is clear.** A caller can predict whether asking this bead will help with their demand. Vague beads dilute the field. - **Cheap to query.** Bead activation should be fast relative to shooter-formation time. Slow beads force the network to wait; slow-and-uncertain beads get pruned by apoptosis before they contribute. - **Composable by URI.** Two beads chain when one's response can form a polarized link toward the next. If the only way to compose them is custom glue, they're not really beads. - **Negotiable surface.** Per [../notes/polarized-links.md](polarized-links.md) and Fielding-REST: the bead tells you what it can do when you ask (OPTIONS, /about, HATEOAS links), rather than requiring external documentation.
## A concrete shooter: Stephen's GSD-LA-Faculty talk as a bookmark folder The 2026-04-22 talk to GSD Landscape Architecture faculty is a perfect worked example. It is **literally a shooter** under the frame of this note. - **The demand ring**: the faculty audience's structured charge distribution — their interests, the invitation context, the faculty-meeting format, Stephen's goal of reframing AI in landscape-design terms. - **The beads (nodes)**: each bookmark in the folder is a URI pointing to a bead-agent. `Forman-20260220_111951.jpg` at `gsd.live/...` is served by an agent (at minimum: whatever backs gsd.live). `simtable.com/videos/new-south-wales-community.mp4`, the `self-assembling-wires-v2.html` viewer, the NetLogo RedfishAnts model — each is a bead-agent that polarizes when activated in the context of the talk. - **The shooter**: the ordered sequence of bookmarks in a folder IS a chain of bead-agents forming a conduit under the demand ring. The order is the growth direction. - **Parallel shooters**: the eight sibling folders (`GSD-LA-2026-04-22`, `GSD-LA-Faculty-2`, `la-fac3`, `gsd-faculty4`, `gsd-faculty5`, `gsd-faculty7`, `gsd-faculty0`, `GSDD-as-landscape-faculty-2024-04-22`) are eight parallel shooter attempts, iterated under the evolving demand ring during talk preparation. - **Circuit closure**: the talk Stephen actually gave is the shooter that closed the circuit — reached the audience, delivered understanding, completed the transaction. The field collapsed on close; the other seven shooters relaxed into the reservoir. - **Residual topology**: the losing shooters apoptosed but left their beads in the reservoir, plus structural memory of which chains almost-worked. Next time the demand ring is similar (another faculty talk, another reframing), re-forming a shooter is faster. - **Advanced-wave response**: every GET by an audience member activates the beads along the shooter; attention/reputation/wealth (see [advanced-wave.md](advanced-wave.md)) flow back through the chain to the beads' authors — to Stephen for the assemblage, to Forman for the source image, to Hubler for the self-assembling-wires experiment, to Sophia for her student work, to Acoma for the acequia heritage. Credit propagates recursively up the shooter. This completes the unification. A bookmark folder is not a passive organizational convenience. It is a **crystallized shooter** — a physical record of the conduit that formed under a specific demand, ready to be re-activated whenever similar demand arises. The bookmark-extractor [skill](../skills/extract-chrome-bookmark-folder.md) is the tool for recovering these shooters and passing them to other beads that need them.
## How demand assembles beads into wires Given a structured demand ring (see [rewiring-cognition.md](rewiring-cognition.md)): 1. Beads whose polarity aligns with peaks on the demand ring become candidates 2. Several partial paths form in parallel (shooters), each a chain of polarized beads 3. Chains compete for the shared field; the one that first reaches full demand-coverage closes the circuit 4. The winning chain's beads are credited in the advanced-wave ledger (see [advanced-wave.md](advanced-wave.md)); losing chain's beads apoptose back to the reservoir 5. Residual structure persists: this specific chain may be faster to re-form next time a similar demand arises (learning) **A good ecology has enough diverse beads that many queries can be satisfied from the existing reservoir, rather than requiring new beads to be authored per query.** This is the aspirational 22/22/56 state: the network has the right distribution of bead-types to form efficient conduits for most incoming demand.
## Relationship to existing software concepts - **MCP (Model Context Protocol)** servers → each MCP tool is a bead (capability-type). An MCP server is a bead-cluster. - **LLM tool-use** → tools are beads. Tool selection is the LLM's attempt to polarize; chain-of-tool-calls is a shooter forming. - **RAG chunks** → each chunk is a memory-bead, but weaker than a well-formed bead because it lacks URI-addressability and negotiated surface. - **Agent skills** → the [skills/ folder](../skills/) contains capability-beads. Each skill is a bead that an agent can invoke. - **Microservices / APIs** → every REST endpoint is aspiring to be a bead; most fall short because their APIs are reified rather than negotiated. - **Linked Data / semantic web** → closest prior art. Each subject-URI is a bead with typed properties. This ecology goes further by making beads active (agents can back them) and negotiated (APIs emerge per interaction).
## Practical next-ups implied by this frame - **Publish a starter bead inventory.** Which beads already exist vs. which are assumed-to-exist but unimplemented? Open question overlapping with [../chats/2026-04-23-ecology-architecture-chat.md](../chats/2026-04-23-ecology-architecture-chat.md) outstanding items. - **Bead registry / discovery mechanism.** How does an agent find out what beads are available? A mayordomo at `/beads/` that synthesizes a listing from many sources? A well-known PROPFIND response? A crawl of the namespace with capability-queries? - **Bead lifecycle.** Explicit: who authored, when, what it depends on, apoptosis conditions. Ties directly to [downstream-pattern.md](downstream-pattern.md) ledger. - **Composition primitives.** Is chaining beads an ecology-level concern (agentscript) or a caller-level concern (each client implements its own chain logic)? Probably agentscript, since it IS the transform of state and bead-composition IS transform. - **Bead "where is Stephen" as first concrete test.** Small, useful, exercises all the pieces: state-beads, backing (phone/geo.camera), URI (`/person/stephen/location`), ACL (who can read), apoptosis (stale data after N seconds), advanced-wave (whoever queries gives attention to the bead's maintainer).
## When to invoke this frame - Any "how do I expose X as a resource?" question → model X as a bead, pick its kind, design its polarity - Any "how should context assembly work?" question → beads under structured demand, not RAG over a corpus - Any "what's the right granularity?" question → one thing per bead; composition happens at the wire level, not inside the bead - Any "how do we make skills reusable?" question → skills are capability-beads; publish them as URIs with negotiated surfaces - Any "MCP server vs agent vs skill" confusion → at the Hubler level they're all beads; distinctions are implementation details