An AI router takes an input and suggests which part of an application should handle it. The useful work starts before the model call: define the possible destinations, the evidence available to the router, and what the application should do when the suggestion is uncertain.
This beginner guide is written by VerdictKit, an independent Jev playground. VerdictKit is not affiliated with TypeSafe AI. The examples below are hypothetical design examples, not measured results.
1. Are the destinations actually different?
Imagine a support application with three queues: billing, technical support and account access. A short label can conceal overlapping responsibilities. A payment problem might belong to billing, while an inability to reach the payment page might belong to technical support.
Write down each destination's responsibilities and the exceptions. If two options mean the same thing, asking a model to distinguish them adds confusion rather than useful information.
2. Is the question asking for a category or a rating?
A category selects an option from a finite set. A rating places a case on an ordered scale. These are different interfaces: a severity rating does not automatically tell you which team should receive a ticket.
Jev exposes Choice for named options, Score for ordered descriptions, and Noul for a yes/no proposition expressed as a probability. Choose the answer shape that matches the next decision in your application.
3. What evidence does the router have?
Give the router relevant facts from the current case. Keep the options stable while checking whether the input explains the distinction you want it to make. Missing information cannot be recovered by making the option labels more forceful.
4. What does uncertainty change?
A selected option is a suggestion. Decide whether an uncertain case should enter a review queue, request additional information or follow another defined path. Use examples labeled for your own task to evaluate that policy.
Avoid treating a probability as proof, or choosing a threshold solely because it looks familiar. A useful threshold depends on the costs of each kind of mistake in the application.
5. Which boundaries belong in ordinary code?
Available tools, permissions and required fields should be checked explicitly. For example, an unavailable integration should not become available merely because a router suggests it.
Keep the model's answer separate from the application's action policy. That separation makes it easier to inspect a decision and change the policy without changing the question.
6. Can you inspect the request and response?
Start by building one small question and inspecting the structured data it produces. Keep your own question identifiers stable so that the application can associate each answer with the intended question.
The independent Jev playground at VerdictKit provides an interface for exploring Choice, Score and Noul. Its JSON-output introduction explains the answer types. Clearly marked demo previews illustrate the interface and should not be treated as live predictions.
A router becomes easier to integrate when destinations, evidence and fallback behavior are explicit. Those definitions are useful even before deciding which model to use.
Top comments (0)