Build the Router

Why this matters

Without a router, you are making a tool-selection decision on every task. That's cognitive overhead that compounds over thousands of interactions. With a router, the decision is made once and maintained. You start a session, your router fires, and the right tool is already selected. You do the work. The router handles the dispatch. The router is not sophisticated software. It can be a structured section in your HARNESS_SPEC.md, a simple script, a CLAUDE.md command, or a lightweight agent. What matters is that it exists and that it's self-updating. **The April 2026 routing logic (starting point — adapt to your context):** | Task type | Route to | Rationale | |---|---|---| | Sensitive client documents | Local Qwen3.5-72B via Ollama | No cloud API, no data retention, full privacy | | Deep reasoning, complex synthesis | Claude Opus 4.6 | Best-in-class reasoning, worth the cost | | Research + real-time info | Grok 4.20 | Live web access, current events | | Standard structured work | Claude Sonnet 4.6 | Fast, capable, good cost/performance | | Unfamiliar domain, breadth needed | GPT-5.4 Pro | Widest training breadth | | Code review, refactoring | Claude Sonnet 4.6 or local Qwen | Code-specialized, cost-efficient | | Long document analysis | Gemini 3.1 Pro | Best long-context performance | | Quick factual lookups | Grok 4.20 or local | Speed-optimized, cost-free if local |

How to do it

1. 1

   Add a 'Router' section to your HARNESS_SPEC.md

   Use the routing table template below. Adapt it to your actual task types from Drill 6.1 and Drill 6.2 recommendations. Add a "last updated" date and the scout model used to generate it.

2. 2

   Create your first router artifact — choose one format

   Option A: Add a "## Route this task" slash command to your .claude/commands/ directory. Option B: Create a ROUTER.md as a standalone reference. Option C: Build a tiny routing script if you want automation.

3. 3

   Test the router with 5 real tasks from your work this week

   Take 5 actual tasks from your current work. Run each through your router. Did it route correctly? If not, was the logic wrong or was the task type missing? Update the router.

4. 4

   Add the self-update protocol to your router

   At the bottom of your router, add: "Last reviewed: [DATE]. Reviewed using: [SCOUT MODEL]. Next review trigger: any major frontier model release or quarterly, whichever comes first." This is the mechanism that keeps it current forever.

The prompt

Based on my Harness Spec and the backend mapping from my Scout Audit, help me create a practical routing table for my work.

My Harness Spec: [PASTE HARNESS_SPEC.md]
My Scout Audit recommendations: [PASTE KEY RECOMMENDATIONS FROM DRILL 6.2]

Create a routing table in markdown format with columns:
- Task type (specific to my domain)
- Route to (specific model/tool)
- Rationale (one sentence — the "why" for this routing)
- Privacy level (cloud OK / local only)

Then add:
- A simple decision tree I can follow when a task doesn't fit a category
- The self-update trigger: "Run Scout Audit (Drill 6.2 pattern) when: [conditions]"

Make this practical enough to use tomorrow morning, not theoretical.

Create a slash command file for my .claude/commands/ directory that implements my routing logic.

When I type /route [task description], it should:
1. Analyze the task description
2. Apply my routing logic
3. Return: "Route to: [MODEL/TOOL] — [one-line rationale]"
4. Optionally start a new session in that tool's format

My routing logic:
[PASTE YOUR ROUTER SECTION FROM HARNESS_SPEC.md]

Success criteria

• ✓HARNESS_SPEC.md contains a Router section with a task → tool → rationale table
• ✓At least one router artifact exists (slash command, ROUTER.md, or script)
• ✓Router was tested against 5 real tasks with at least one correction made
• ✓Self-update protocol documented: when to re-run scout, what triggers a review

Common mistakes