One Claude per channel — and why the walls between them are a feature, not a limit.
Inside a channel there is exactly one ClaudeTag, shared by everyone: "anyone can see what it's working on, and can pick up the conversation from where the last person left off."[ref §5] Across channels, admins stand up separate Claude identities — each with its own scope and its own walled memory.[ref]
Because the work happens in the thread, ClaudeTag is a baton anyone can carry. You start a task, log off, and a teammate resumes it with full context already on screen. You already live this — your Mac ↔ Win VM hub is the same idea: one continuous agent context, handed between operators. ClaudeTag makes the handoff the default.
The real power is running different Claudes for different jobs, each a distinct Access bundle + memory:
| Identity | Tools scoped in | Memory holds |
|---|---|---|
#prism-ops | read/monitoring MCP tools (Lesson 2) | incidents, baselines, live-account context |
#prism-research | backtest + shadow-DB read only | strategy experiments, BT results |
#finance | invoicing / accounting connectors | vendor, billing context |
The #finance Claude cannot see the trading account. The #research Claude cannot touch a live position. That isolation isn't a restriction you tolerate — it's the design goal.
kill_global." The wall is enforced by scope, not by the model remembering to behave.
From Lesson 2's rule: memory is channel-scoped, and cross-channel learning happens only with granted permission.[ref §3] So the #research Claude won't absorb live-account details unless you deliberately bridge the channels.
Bridge only when the downstream identity genuinely needs the upstream context and the tool scope stays safe. Example: let #prism-ops read #prism-research's BT conclusions so it can sanity-check a live deploy — that's read-only knowledge flowing to a more-privileged channel, which is fine. The dangerous direction is granting a low-trust channel access to a high-privilege one's tools/memory. Default to no bridge; justify every one.
Two teammates, two shifts, one #prism-ops channel. What's the multiplayer benefit?
One shared Claude per channel means the work and its context sit in the thread — the next person resumes without a handoff briefing. It is not per-user instances, and it is not a voting panel.
Why give #finance and #prism-ops separate identities rather than one Claude in both?
Separate identities = separate blast radii: least-privilege tools plus walled memory. A single Claude spanning both would collapse the wall. (Claude can be in many channels; spend caps are per-channel, not doubled by splitting.)
You can now design a fleet of ClaudeTags — one per concern, each scoped and walled — instead of one over-privileged bot. That's the same architecture as your subagent roster, expressed in channels.
@Claude task, the actual craft of a delegation prompt that decomposes cleanly. This is the most direct hit on your mission.