Author · Create · Writing & Content

Author a tool-routing table for my 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

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.