Author · Create · Writing & Content
Tool-routing table for an agent
I get a complete tool-routing table for my agent: each task class I declared is routed to exactly one primary tool or model, with a fallback and a cost tier, so I can see at a glance that nothing is unrouted and no route depends on a tool I do not have.
You receive: A JSON object { routes: [{ taskClass, selectionSignal, primaryTool, costTier, fallbackPolicy, fallbackTarget, rationale }] } with one row per declared task class, where costTier is exactly one of "cheap_fast" or "expensive_powerful" and fallbackPolicy is exactly one of "fallback_tool", "human_review", or "quality_warning".
Part of Ship MVP
Example
A sample of what this play produces. Your result is generated for your inputs.
| Task Class | Selection Signal | Primary Tool | Cost Tier | Fallback Policy | Fallback Target | Rationale |
|---|---|---|---|---|---|---|
| intake-triage | Request arrives as a raw buyer intake or a play-selection question, before any deliverable work starts. | fable-5-low | cheap_fast | fallback_tool | opus-4.8-high | Triage is high volume and pattern shaped: the intake either names a play or maps to one from workspace facts. A cheap fast model clears it in one pass; when the mapping is ambiguous across playbooks, the expensive model re-reads the full catalog context and decides. |
| sample-authoring | Request asks for a fresh deliverable draft in a play's native format: a doc, a table, a spec, a routing artifact. | fable-5-low | cheap_fast | quality_warning | Authoring runs on the generative tier by policy (Fable at low effort authors; judgment models audit). The play's own acceptance check already gates every draft before it lands, so a failed or uncertain draft ships with a quality warning rather than burning the expensive tier on a first pass. | |
| contract-audit | Request asks whether a published contract, honestScope, or validator actually enforces what it claims. | opus-4.8-high | expensive_powerful | human_review | founder review queue (Dan Schmitz) | Audits are judgment-bearing: a wrong pass verdict silently ships a defective contract, which is exactly the class of error a cheap model misses. The expensive tier reads the full rule set; anything it cannot settle escalates to the founder queue instead of guessing. |
| calculator-verification | Request contains a worked numeric example that must match a committed reference oracle exactly. | python-reference-oracle | cheap_fast | fallback_tool | opus-4.8-high | Arithmetic is not a model task: running the committed oracle is deterministic, instant, and free of confabulation risk. Only when the oracle errors or the inputs do not fit its signature does a model step in to diagnose the mismatch. |
| voice-cleanup | A drafted deliverable is complete and needs the voice pass: em dashes out, locked vocabulary in, register checked. | fable-5-low | cheap_fast | quality_warning | Voice cleanup is mechanical rewriting against a fixed rule list, the textbook cheap fast case. The deterministic voice lint in the gate catches anything the pass misses, so residual doubt surfaces as a warning, not an escalation. | |
| money-legal-deliverables | The deliverable states figures, terms, or obligations a buyer could act on financially or legally. | opus-4.8-high | expensive_powerful | human_review | founder review queue (Dan Schmitz) | Money and legal content is where a plausible wrong answer costs the most, so it gets the expensive tier and, by standing policy, a human in the loop: every deliverable in this class queues for founder review before it ships, no matter how confident the model is. |
Opens soon
STUD opens runs for everyone soon, on every play at once.
Scope of the check
What's verified: STUD verifies the structure and the coverage of the routing table, not whether the routing is right for your workload. Verified: the submission parses as a JSON object with a routes list; every task class you declared has exactly one primary route (no unrouted class, no duplicate class, no invented class); every primaryTool, and every fallbackTarget on a fallback_tool route, is one of the tools or models you declared; every route carries a fallback policy drawn verbatim from exactly these three literals, "fallback_tool", "human_review", "quality_warning", and a cost tier drawn verbatim from exactly these two literals, "cheap_fast", "expensive_powerful"; a fallback_tool route does not fall back to its own primary tool, and a human_review route names the reviewer or queue it escalates to (a non-empty fallbackTarget); each route's cost tier matches the tier you declared for that tool; and (when you leave the high-stakes switch on, its default) each task class you marked high stakes falls back to "human_review". Selection signals and rationales must clear your minimum character count and must not be placeholders. NOT verified: that the tool or model chosen for a class is the best or even a workable choice for your traffic, that the tools or models named exist, are available to you, or perform as claimed, that your cost tier labels are accurate to real prices, that your declared task classes cover the requests your agent will actually receive, or that the table will hold up once real users arrive. The cost vocabulary is deliberately two-valued because the source draws a two-way distinction (a cheap fast tool for common cases, an expensive powerful one reserved for the cases that need it) and does not offer a graded scale; a finer cost model is out of scope here. The high-stakes human-review check enforces guidance the source states as a rule of thumb ("assume you will need a human-in-the-loop step somewhere"), applied only to the classes you yourself mark high stakes, and you can turn it off in intake. Routing soundness is judgment, and the source says so: the routing logic itself must be reliable, and STUD cannot check that for you.
Get early access to STUD the day it goes live.