SendMessage name-based addressing silently misroutes with multiple same-type subagent instances (should require/prefer agentId)

Summary

SendMessage currently allows addressing a subagent by its subagent-type/template name (e.g. "general-purpose-sonnet") as well as by its unique instance agentId. When multiple concurrent instances of the same subagent type are running (a common shape in any multi-stage or fanned-out orchestration session), name-based addressing resolves ambiguously — apparently "latest wins" — and can SILENTLY deliver a message to the wrong instance, with no error at all. This is worse than the more commonly-hit failure mode (a bounce/"no agent named X is reachable" when the name truly doesn't resolve) because there's no signal that anything went wrong; the message is delivered, just to the wrong recipient.

Concrete repro / evidence (from a real session, 2026-07-12)

Session: a Sonnet coordinator running a multi-stage agent pipeline (project arc hub-1579-1562, "pr-table-render-agent" side-quest) with several concurrently-active general-purpose-sonnet instances doing different pipeline stages (a Stage 1 design IC and a Stage 2 build IC, among others).

• A topic-scoped Fable advisor (itself a subagent) tried to reach the Stage 2 IC via SendMessage(to: "general-purpose-sonnet", ...), intending to deliver a spec-diff review verdict.
• The message was delivered successfully — but to the WRONG instance: a completely unrelated, already-closed Stage 1 IC, which happened to also be typed general-purpose-sonnet.
• The advisor had no error/warning that this had happened. It only surfaced because the recipient IC (behaving well) noticed the message didn't match its own actual task scope, verified its own identity/history, and explicitly declined to act on an instruction that didn't belong to it — then reported the mismatch back up the chain.
• This happened a SECOND time in the same session, minutes later, when the same advisor tried to reach the actual Stage 3 test IC by the same generic name and again landed on the wrong (by-then-closed) Stage 1 IC's transcript.
• A near-identical, distinct incident also occurred with a different pair of agents in the same session, where a message intended for a Fable design advisor was misdelivered to an unrelated capture/documentation subagent that happened to share a similarly-resolved name/id confusion — that one was caught because the wrong recipient explicitly reported "I have no record of this work" rather than guessing/fabricating a response.

In all cases, the ROOT problem is the same: subagent_type names (and apparently plain "general" agent names generally) are TEMPLATE identifiers — many simultaneous instances can share one — while only agentId uniquely identifies a specific running INSTANCE. Addressing by template name is fundamentally ambiguous whenever more than one instance of that type is alive, which is an extremely common situation in any orchestration session that fans out multiple ICs of the same type.

Proposed fix

Require (or at minimum strongly default-warn/deprecate) agentId-based addressing for SendMessage, and either:
(a) remove/disable plain subagent-type-name addressing entirely, or
(b) if name-based addressing is kept for convenience (e.g. addressing the sole live instance of a uniquely-named teammate), make an AMBIGUOUS name match (more than one live instance sharing that name) a hard error/bounce — loud and immediate — rather than silently resolving to "latest wins."

The current tool documentation already hints at the right mental model ("Use the raw agentId... only when the agent has no name, or when a newer agent took the name (latest wins)") but this framing undersells the danger: "latest wins" is exactly the silent-misroute mechanism described above, and the current guidance treats it as an edge case rather than the default behavior whenever a coordinator fans out multiple same-typed subagents, which is a routine pattern.

Impact

This is a genuine coordination-safety issue for any multi-agent orchestration session using several instances of the same subagent type concurrently (a common and encouraged pattern per Claude Code's own documented multi-agent patterns). The failure is silent by default and depends on the wrong-recipient agent's own good judgment to be caught at all — it is not something a well-behaving orchestrator can reliably detect or prevent today short of manually tracking every spawned instance's agentId and never using name-based addressing, which the tool currently allows and does not warn against.