Model choice
Match complexity, latency and cost to the model that should handle the request.
Make the next path explicit: use the fast model, the strong model, a tool, a person or no action.
Incoming request
“Refactor auth for SAML and SCIM while keeping backward compatibility.”
Next path
strong model · tools
Two routing layers
Choosing a tool is not the same as allowing it to run. Keep both decisions visible in the workflow.
Match complexity, latency and cost to the model that should handle the request.
Select the next approved tool or decide that no tool is needed.
Send uncertain or high-impact requests to a stronger model or a person.
Operations
A cheap route is useful only when the workflow knows when to step up.
Give every model or tool a short, honest capability description.
Use one question for complexity, destination and approval.
A router should be allowed to choose that no tool is appropriate.
Choose a route
A cheap route is useful only when the workflow knows when to step up.
{
"state": "Summarize this 80-page contract and flag renewal risks.",
"questions": {
"complexity": { "type": "score", "instructions": "How complex is this request?", "criteria": ["simple", "moderate", "hard"] },
"destination": { "type": "choice", "instructions": "Which route should handle it?", "criteria": { "fast": "short lookup", "strong": "complex reasoning", "tool": "needs a document tool" } }
}
}Describe the models, tools and handlers available in this loop.
Return a typed destination and the signals needed for the next gate.
Let deterministic code run, fallback or request confirmation.
FAQ
No. The same pattern can choose a model, handler, tool, queue or human review path.
Usually not. Ask where the request should go, then apply a separate deterministic permission or confirmation policy.
Choose a fallback such as a stronger model, a safe default or human review, and measure how often that path is used.