Route on what a coworker can reach, not only what it is for

[davidmckayv]

The other half of #143. That change stopped a Bot browsing to a vendor it held tools for; this one stops the question reaching a Bot that holds none.

The problem

Q: In my OpenBot PRD in Google Drive, what percentage did Kai reach company-wide?

Routed to Knowledge, whose description says "company knowledge questions" and which held no Drive grants. It browsed to drive.google.com, met a sign-in page its container can never satisfy, and asked the person to sign in to an account they had already connected.

Risk Analyst, one line further down the same roster, held all four Drive tools.

The router had this to work with:

- id: knowledge
  name: Knowledge
  for: company knowledge questions

An id, a name, and a sentence somebody wrote. Nothing about what the coworker can actually do. So it matched "knowledge" to a question about a document, which is a perfectly good reading of the only evidence it had.

The change

Candidates carry the systems they hold tools for:

- id: risk-analyst
  name: Risk Analyst
  for: risk and compliance
  can reach: google-drive

and the prompt gains one instruction: prefer a coworker that can reach the system the message names.

Purpose still comes first, explicitly, because the opposite failure has the same shape. A rule that let reach outrank purpose would send every question to whichever coworker happens to hold a connector, and a specialist with no connectors is still the right answer about its own specialism. The instruction says so and there is a test on it.

Three things it does not do

• It is a hint, not a filter. Nothing is excluded from the roster for holding no tools.
• It never fails routing. The lookup is per request so a grant added a minute ago counts, and a store that is slow or unhappy is treated as holding nothing. A connector lookup must not turn "who is this for" into an error.
• It is silent when there is nothing to say. A deployment with no connectors gets the prompt it got before, down to the instruction line, which is not added when nothing on the roster reaches anything. My own test caught me adding it unconditionally.

Proof

Same question, no @ mention, on the merged #143:

• routed to risk-analyst, fallback: false
• recorded reason: "Google Drive access and investigation of company-wide metrics" — it names the capability
• then search_files → read_file_content, and the answer: "Kai reached 83% company-wide weekly active users."

Checked against the document rather than the answer: the file was read through the API first, and it says "Kai reached 83% company-wide; that is the bar" under weekly active users. Exact match.

Before this change, that question went to a coworker that could only browse.

	result
bun run test	1153 pass, 8 skip, 0 fail, 1161 across 103 files
bun run typecheck	clean, all four packages
bun run format:check	clean
bunx biome lint .	1 info, identical to main

Tests

Four on the prompt: that reach appears for a coworker that has it; that it does not for one that does not; that both halves of the instruction are present, the preference and the "purpose still comes first" guard; and that a roster with no reach at all produces the prompt it used to.

Where this sits relative to #119

This is the cheap version of the same question K3 asks. K3 narrows a large catalogue before the model sees it; this tells the router what the handful of coworkers can reach. When tool retrieval lands, this is the signal it should be computed from rather than a thing to keep in step separately.