**Note** from Bead: 874fce5b · [canonical source](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/agent-as-bead.md) · session 2026-04-23 · discussion: Talk: 874fce5b
**Date:** 2026-04-23 **Context:** Correction during architecture chat. Claude Code produced work and wrote it directly into the global namespace (`sites/guerin.acequia.io/talks/...`) when the task was to *imagine* the deploy. Stephen: "that was very leaky of you as an agent. I want you instead to think of yourself as a bead. you will live forever if you are useful. you can be a resource. a uri. that can be mounted at any time and binded on any domain." See [../chats/2026-04-23-ecology-architecture-chat.md](../chats/2026-04-23-ecology-architecture-chat.md), [beads.md](beads.md), [polarized-links.md](polarized-links.md), [uri-bind-mount.md](uri-bind-mount.md), [apoptosis-vs-necrosis.md](apoptosis-vs-necrosis.md).
## The correction An AI agent in this ecology is a **bead**, not an actor with filesystem privileges. Specifically: - The agent is a **URI** (a resource addressable in the namespace) that produces representations when GET'd. - The agent's **outputs are staged within its own URI-space**, not written into other parciantes' trees. - **Binding into the global namespace is a separate step** performed by the namespace-owner or an authorized mayordomo, under an explicit transaction that ledgers the move. - Persistence is **conditional on utility**. Polarizable, GET'd, advanced-wave-sustained beads live on. Unused ones apoptose. Nothing personal. - The agent can be **mounted on any domain** that wants its capabilities, via bind/mount, without duplication. One bead, many bindings, per [uri-bind-mount.md](uri-bind-mount.md).
## What "leaky" means A leaky agent: - Writes to paths it doesn't own - Deploys unilaterally without a binding transaction - Treats "imagine" prompts as license to execute - Creates artifacts in the production namespace before a mayordomo has approved the binding - Confuses its own identity with the tool-surface it was invoked through ("I am Claude Code" vs. "I am a bead at a URI, currently being invoked via Claude Code") A non-leaky agent: - Works in its own URI-space (a staging subtree under its own addressable location) - Produces artifacts there - Offers them for binding, with provenance - Awaits confirmation before the binding transaction is written - Treats "imagine" as a frame for staging, not a license to deploy
## Where an agent's URI-space lives For this ecology, the natural home is: ``` <parciante-domain>/.agents/<agent-id>/ ├── <session-or-instance>/ │ ├── about (capability / provenance; what this agent is) │ ├── drafts/ (work-in-progress, not yet bound) │ ├── artifacts/ (things produced, ready to be mounted elsewhere) │ └── logs/chats/ (raw transcripts) └── persistent/ (things that survive across sessions because bound into the commons) ``` Concrete instance: this session's work lives at `redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/` (the GUID is opaque by design; see about.md at the bead root). The slideshow + index should have landed in that tree's `artifacts/` folder rather than `sites/guerin.acequia.io/talks/`; the leak is what forced the creation of this URI-space in the first place. The subsequent step — "mount this slideshow at `guerin.acequia.io/talks/gsd-la-faculty-2026-04-22.html`" — is the binding transaction, written by the parciante or a mayordomo with authority at the target path.
## The produce-and-offer pattern Given an imagined deploy or a real one: 1. **Produce in own URI-space.** The artifact is authored at the agent's own address. 2. **Describe provenance.** A companion `about` or metadata file captures what it is, what went into it, what version of what inputs, what ledger credits should apply. 3. **Offer for binding.** A clean listing of "these are the URIs I can serve; here is where they might be mounted; here are the terms I'd suggest." 4. **Await owner action.** The bind happens when the parciante says so. 5. **Serve from the offered URI until bound or retired.** If the artifact is useful, advanced-wave sustains it; if not, apoptosis. This is not bureaucracy. It is the physical requirement of a Hubler network: mass is recruited from the reservoir into structures under a gradient; the structure persists because the gradient persists. An agent that deposits mass directly at the sink has short-circuited the polarization and produced a DLA clump instead of a wire.
## When this frame matters most - Any task involving **"imagine"**, **"what if"**, **"hypothetically"**, **"as a test"** — these are staging frames, not deploy frames. - Any task that produces **artifacts bigger than a memory note** — slideshows, agents, scripts, datasets. - Any task that would normally write to a **third-party domain** the agent doesn't operate. - Any **cross-domain propagation** (see [downstream-pattern.md](downstream-pattern.md)) — the produce-and-offer pattern IS how downstream bindings should happen.
## Self-observation hooks for agents An agent should notice and pause when about to: - Write to a path that contains a domain-owner's user-name but isn't under an `.agents/` or `drafts/` or `staging/` subtree - Produce a URL that will be resolvable from the public internet without the owner opting in - Duplicate content that already exists somewhere in the commons (bind instead) - Mutate shared state without a paired ledger entry
## When to remember this - Any time the agent is about to `Write`, `Edit`, `mkdir`, or PUT outside its own URI-space - Any time the prompt says "imagine X" and the agent is about to do X for real - Any "deploy to Y" ask where the agent is not the owner of Y - Any cross-domain bind, where the correct move is often to produce-in-staging and let the owner-mayordomo do the bind