Send an untagged message to the coworker it is for

[davidmckayv]

What this changes

Typing without an @ reached the default coworker; to get a specialist you had to @ them. That makes the person do the routing, which is the friction an outside user flagged: assistants that "just work" take what you say and act. Now an untagged message is routed to the coworker whose purpose matches it.

How. A channel is pinned to one coworker before its first turn, so the choice happens at the one seam where an untagged message picks a coworker (index.tsx, draft.agentId ?? fallback), before the channel is created. A new governed POST /api/route:

• reads the roster for the person asking (profileStore.list(actor)), so it can only ever pick a coworker they may already reach;
• asks the deployment's own model (its existing model + key, no new config) to choose against each coworker's roleDescription;
• validates the answer is a coworker on that roster, records a channel.routed audit row, and returns it.

Named, not silent — which the composer already believed ("a message that silently reaches somebody you did not choose costs trust"). The channel header is the coworker it went to; the audit row carries the reason and the candidates but never the message (payload redaction drops it anyway).

@ is unchanged and wins. An addressed message skips routing entirely: no model call, no inference recorded.

Every uncertain path fails safe to the same default the composer always used, and says so, rather than misroute or drop: no roster, one coworker, model unreachable, unparseable answer, an id not on the roster, or confidence below threshold.

Where it runs

• New state that outlives a request? None. The router is a pure function plus one per-request model call; no cache, map, or timer.
• Second replica? Identical. One permission-filtered roster read + one model call + one audit row per untagged send, same profile as agent.invoked.
• Serialised / fanned out / new listener? No.

Boundary and audit

• The decision goes through the governed shape: resolve (roster for the actor) → decide (model, validated against the roster) → audit (channel.routed) → act (start). A returned id not on the roster is never acted on.
• New event channel.routed records who, why, viaMention, fallback, and the candidate ids. No message text.
• Nothing new trusted from the client: only the message text is sent; the roster and the choice are server-side.

Changelog

• Entry under Unreleased.

Proof

Driven in Chrome on a running stack, verified by the audit trail and the rendered app, not the model's words:

• No @: typed "review this wire transfer for fraud and sanctions risk" → landed with Risk Analyst (header + a risk-flavored answer). Audit: channel.routed → risk-analyst, fallback:false, viaMention:false, candidates [general-assistant, knowledge, risk-analyst], no message body.
• @ override: picked General Assistant from the @ menu, sent the same risk text → landed on General Assistant, and no new channel.routed row (routing was not called).

Failsafe is a red-green unit suite on the pure classifier (server/tests/routing-classify.test.ts, 7 tests): specialist match, model unreachable, unparseable, off-roster id refused, low confidence deferred, fenced JSON parsed, single-coworker roster. bun run typecheck exit 0, biome lint/format clean, full suite 1086 pass.

Follow-up (not in this PR)

The routing reason is recorded and returned but not yet shown in the transcript; the header names the coworker. A one-line "Routed to Risk Analyst because…" notice is a small follow-up.