Workflow subagents receive the session's teammate roster + SendMessage — intended? (works well; docs + an off-switch would help)

What I observed

While running deterministic multi-agent scripts with the Workflow tool (research preview), I noticed every workflow subagent receives an injected system reminder advertising the interactive session's addressable agents:

<system-reminder> Other agents active in this session, addressable via SendMessage({to: name, message}): main, <named-agent-1>, <named-agent-2>, … </system-reminder>

…and the subagents genuinely hold the SendMessage tool. I could not find this behavior in the docs or the CHANGELOG (the changelog documents the messaging feature family — cross-session hardening, subagent steering, auto-resume — but not this roster advertisement to workflow/Task subagents).

What I verified (transcript-level, not model self-reports)

1. The advertisement follows the capability. A subagent spawned under a custom agent type whose tools: allowlist omits SendMessage gets neither the tool nor the reminder (checked the transcript: zero occurrences, vs present in every default-type sibling). Nice design — denying the capability removes the knowledge with it, so a registered agent type is a clean off-switch.
2. Subagent → main conversation works: {"success":true,"message":"Message queued for the main conversation's next turn."} — delivered.
3. Subagent → named live agent works: inbox delivery with msg_id; the message even re-invokes an agent that had already finished its turn. One-way (ephemeral workflow agents are not re-addressable).
4. Run siblings are NOT addressable by their label ("No agent named '…' is reachable") — no intra-run lateral channel.
5. Headless SDK sessions (a server-launched run): the tool is present but no roster is advertised, and the addressable universe is the headless session itself — no cross-session leakage.

Why I'm reporting it

Mostly as positive feedback: this enables useful patterns from deterministic workflows (an agent notifying the main conversation of a milestone/blocker mid-run, observer/watchdog teammates collecting signals). I've already seen under-specified fixture agents spontaneously message main to ask for missing context — which is also how I discovered the channel.

Three asks:

1. Is the roster advertisement to workflow/Task subagents intended and stable? If yes, a docs/CHANGELOG mention would help — today it reads as an undocumented information surface (session teammate names reach every capable subagent) plus an outbound channel workflow authors may not know their leaves have.
2. A first-class off-switch would help: the Workflow tool's agent() has no per-call tools, so today the only deny lever is registering a custom agent type .md with a restricted tools: allowlist. A per-workflow or per-call option to disable inter-agent messaging would make least-privilege leaves much easier.
3. Minor: the agent-type registry appears to be read at session start only (an agent .md added mid-session isn't visible to agent({agentType}) until a fresh session — the error is loud and lists available types, which is good).

Claude Code 2.1.206, Linux (WSL2). Happy to provide run journals/transcript excerpts if useful.