AI Agent Tool Router: choose the next tool
Compare Search, Calculator, Code, and Database for an agent’s next step. Define tool boundaries before routing a request.
Free preview limits apply. Sign in to use your credits and keep a decision history.
Your next decision starts here.
Add context above, or try an example to get started.
Route against capabilities, not tool names alone
Agent routing chooses an available capability for the next step in a task. Search and Database both retrieve information, but from different sources; Code and Calculator can both calculate, but have different execution requirements. Describe what the agent already knows and what each tool can access. A routing decision does not call a tool, construct valid arguments, or grant permission. Your application remains responsible for validating the selected capability and its inputs before execution.
Work through the cases
Illustrative inputs and review guidance, not recorded model outputs. Run your own context to inspect a decision.
All operands are already present
The invoice subtotal is 240 and tax is 8%. Calculate the total.
Calculator is an appropriate policy choice for arithmetic with known operands. No external lookup is needed. Validate the numbers and units before execution; choosing a calculator does not establish whether the supplied tax rate is correct for a real invoice.
The data has to be retrieved first
What was our average order value this month, excluding refunded orders?
Database is a candidate if the authorized orders source supports this query. Retrieval and aggregation may happen together in SQL. Include the schema and tool capabilities in your routing policy; a calculator cannot supply missing order data merely because the question asks for an average.
None of the available tools can act
Book a flight for tomorrow and pay with my company card.
The default four tools do not establish a booking or payment capability. In an integration, add a clearly defined unavailable-action choice or reject unsupported tasks before routing. This page keeps its original options; a selected default tool must not be taken as permission or proof that the task is achievable.
Set the boundaries before you classify
Suggested review rules for these options. Include the rules relevant to your team in the question or context when you run a decision.
| Choice | Use it when | Check the boundary |
|---|---|---|
| Search | Retrieve information from the search sources available to the agent. | Public search is not access to a private orders database. |
| Calculator | Evaluate a bounded arithmetic expression with known inputs. | Missing facts require retrieval or clarification first. |
| Code | Run an allowed transformation or computation in an execution environment. | Execution needs its own sandbox, permissions, and input checks. |
| Database | Query an authorized structured data source. | Selection does not authorize a write or bypass row-level access controls. |
Where to take a closer look
Overlapping or vague capabilities
In a custom setup, “Query the orders database” tells the router more than “Database”. Define the source, supported operation, and exclusions. Evaluate overlap explicitly when both a SQL aggregate and a code task could produce the result.
Selecting a tool for an unsupported task
A forced choice always has a winner even if no option is suitable. Add a fallback choice in your own configuration, or enforce a capability check before routing. Do not silently execute the most popular tool when the request remains unresolved.
Evaluate the next step, including its execution cost
Measure routing mistakes by tool pair, execution cost, and whether the task eventually succeeds. A high-confidence selection can still be unavailable in the current environment. Validate permissions and arguments independently, and ask for clarification when required inputs are missing.
Measure routing latency within your own end-to-end budget rather than adopting a universal percentage. Multi-stage routing adds calls and can compound errors; include those costs when comparing a separate router with a model’s native tool selection.
A Jev API example for your next integration
Call the iajev REST API with cURL. Receive a choice, probabilities, and confidence as JSON.
curl https://iajev.com/api/v1/decisions/run \
-H 'Authorization: Bearer YOUR_API_KEY' \
-H 'Idempotency-Key: YOUR_UNIQUE_REQUEST_ID' \
-H 'Content-Type: application/json' \
--data '{
"state": {
"message": "What was our average order value in Q3, grouped by country?"
},
"decision": {
"type": "choice",
"question": "Which tool should the agent call?",
"choices": [
"Search",
"Calculator",
"Code",
"Database"
]
}
}'Questions about this tool
What if my agent has more than eight tools?
The current iajev interface accepts at most eight choices. One approach is routing first to a capability family and then to a specific tool. Define a fallback at each stage and evaluate the complete chain, since an incorrect first stage can hide the correct tool from the second.
When would I use this alongside native function calling?
Consider a separate routing step when you need to inspect a distribution over a fixed set of capabilities before execution. Native function calling may also produce arguments as part of the agent workflow. Compare task success and latency; this endpoint returns a choice, not an executable function call.
Using iajev
Add context
Include the facts needed for this decision.
Review the choices
Customize the question and options to match your workflow.
Run and review
Inspect the distribution before taking action.
Is confidence the probability that a decision is correct?
No. Confidence is a separate model estimate; the choice probabilities describe the distribution over your options. Neither is a measured accuracy guarantee.
Can I compare two inputs?
Edit the context and run the same question again to compare probabilities. Changing the question or choices starts a new comparison.