Test your voice agent
Jev for Tool Calling in AI Voice Agents

# Jev for tool calling in AI voice agents
Quick answer
Jev is TypeSafe AI's System One model. It cannot emit a hallucinated tool name or a mistyped argument, because its output is schema-constrained. In a voice agent, use Jev to decide if a tool is needed, pick the right tool, and gate risky calls in under 500ms. Then evaluate the results independently.
Tool calling is where voice agents get useful. It is also where they break. A hallucinated tool name or a wrong argument type can drop a call, charge the wrong card, or book the wrong slot.
Jev takes a different path. It launched on September 15, 2026, in early access. TypeSafe AI calls it the first "System One Model". This post shows how jev tool calling voice agents work, where Jev beats an LLM on the tool path, and where it does not.
What tool calling asks of a voice agent
Every tool call is really four decisions in a row.
First, does this turn need a tool at all? A greeting does not. A refund request does.
Second, which tool fits? You may have one tool or two hundred. The agent has to pick the right one.
Third, is this call safe to run now? Some tools read data. Others move money or delete records. The risky ones need a check.
Fourth, are the arguments valid? The tool name must exist. The types must match the schema. A JSON Schema defines what "valid" means.
Get any of the four wrong and the call fails. In voice, the failure is loud. The caller hears a stall, a wrong action, or an apology. Our guide on tool calling for voice agents covers the concepts in depth.
Where an LLM's tool calls break down
LLMs are good at tool calling. They are not perfect at it.
An LLM generates the tool call as text. That flexibility is the strength. It can also produce a tool name that does not exist. It can pass a string where a number belongs. It can invent a field.
TypeSafe's launch makes the point plainly. Existing LLMs still show a non-zero error rate on structured output and tool calls, no matter how capable the model is. The smarter model helps. It does not drive the error to zero.
There is a second cost. An LLM tool decision takes hundreds of milliseconds to seconds. In a phone call, that time is expensive. The caller feels every pause.
These failures are often silent. The call looks fine. The wrong tool ran anyway. Our post on how to detect silent tool failures explains why they hide so well.
How Jev changes the tool-calling path
Jev is not an LLM. It does not generate text. You send it a state, such as the transcript, plus your questions. It returns typed, calibrated decisions.
That design removes a whole class of errors. TypeSafe reports Jev adds 0% error on structured output and tool calls. Its output is schema-constrained. An invalid value, a hallucinated field, or a wrong type is mathematically impossible.
This is the core claim. An LLM can hallucinate or mistype a tool call. Jev cannot. You can read the formal ideas behind it in type safety and data validation.
Jev answers three question types. Each maps to a tool-calling decision.
Is a tool needed? (Noul)
A Noul question returns a yes or no probability. Ask Jev: does this turn need a tool? A high "yes" triggers the tool path. A "no" lets the agent just talk. This stops the agent from calling tools it never needed.
Which tool? (Choice)
A Choice question picks one option from up to 255. List your tools as the options. Jev returns a probability per tool plus a confidence value. The chosen tool name is always one you defined. It can never be a name Jev made up.
Is this call safe? (AutoMode)
Some tool calls are risky. A refund, a cancellation, a data delete. LangChain's `AutoModeMiddleware` uses Jev to check a tool call for risk and block it before execution. You ask a Noul question: is this call safe to run now? A low-confidence yes becomes a hold. TypeSafe describes the pattern in the LangChain harness post.
Schema-guaranteed structured calls
The tool name and the choice of value come back typed. There is no parsing step that might fail. The output already fits the schema. That is the difference between hoping a call is valid and knowing it is. The full API is in the TypeSafe docs.
LLM tool calls versus Jev: the decision table
Each tool-calling decision has an LLM approach and a Jev approach. The table maps them side by side.
| Tool-calling decision | LLM approach | Jev approach |
|---|---|---|
| Is a tool needed? | Infers from context; may over-call or skip | Noul question; yes/no probability with calibrated confidence |
| Which tool to call | Generates the name; can hallucinate a non-existent tool | Choice over up to 255 defined tools; name is always valid |
| Is this call risky? | Reasons about risk inline; slow and inconsistent | Noul gate via AutoMode; blocks or holds low-confidence calls |
| Are the arguments valid? | Generates free-form args; can mistype or invent fields | Schema-constrained output; wrong type or field is impossible |
| Speed per decision | Hundreds of ms to seconds | 70 to 500ms, about 40 to 200x faster |
| Cost per decision | Standard LLM token pricing | Input $0.042 per MTok; output free, about 400x cheaper |
The pattern is clear. Use the LLM for open-ended generation. Use Jev for fast, structured decisions.
The hybrid pattern: LLM proposes, Jev validates
Jev does not replace the LLM. The two work together.
The most common pattern is hybrid. The LLM proposes a tool call. Jev validates and gates it before execution. If Jev's safety confidence is low, the call holds. A human or a confirm-back step steps in.
A second pattern flips the order. Jev selects the tool with a Choice question. A constrained step then fills the arguments against the schema. The LLM handles only the parts that need free-form language.
Be honest about the split. Jev decides which tool, whether a tool is needed, and whether a call is safe. It does not generate free-form arguments from nothing the way an LLM does. When a tool needs a novel string, the LLM still writes it, and Jev checks the result. Our guide on testing versus evaluation frames how to verify each half.
For the wider set of Jev jobs beyond tools, see the Jev use cases for voice agents, and the routing side in Jev routing and escalation.
Why voice's latency budget makes this matter
Text chat forgives a slow tool call. Voice does not.
A phone caller expects a reply in about a second. That is the whole turn budget. Speech-to-text, the decision, the tool, and speech-out all fit inside it. A slow tool step eats the budget.
TypeSafe reports Jev latency of 70 to 500ms per decision. That is roughly 40 to 200 times faster than an LLM on the same task. You can run the tool-need check, the tool choice, and the safety gate as parallel questions in one call.
That speed changes what you can afford to check. A cheap, fast gate can run on every risky call. You are not trading safety for latency. You can read why timing dominates voice in latency (engineering)).
How to add Jev to a voice agent's tool-calling path
Follow these steps to put Jev on the tool path of a live voice agent.
1. List your tools as a Choice schema. Add every tool as an option, up to 255. Keep names distinct and short.
2. Capture the call state. Pass Jev the running transcript plus any structured context. Jev works on text and state, not raw audio.
3. Ask the tool-need question. Send a Noul question first. Skip the tool path when the answer is a confident no.
4. Select the tool. Send a Choice question over your tools. Read back the top tool and its confidence.
5. Fill arguments against the schema. Use Jev for typed choices. Use a constrained LLM step for any free-form value.
6. Gate risky calls. Ask a Noul safety question before high-impact tools. Use `AutoModeMiddleware` to block or hold on low confidence.
7. Set confidence thresholds. Pick a bar, such as 0.85. Below it, confirm back or escalate instead of firing.
8. Batch the questions. Ask tool-need, tool-choice, and safety in one parallel call to save time.
9. Log every decision. Store the state, the question, the chosen tool, the arguments, and the confidence.
10. Send the logs to an independent evaluator. Confirm the right tool ran with the right arguments on real calls.
Evaluation still decides whether it worked
Jev gives you a typed decision and a confidence number. It does not tell you the decision was correct. That is a separate question, and it is the one that matters in production.
This is where Evalgent comes in. Evalgent is an independent, third-party evaluator for AI voice agents. We do not build your agent or sell you a model. We measure whether your tool calls were right, on your own calls.
We score tool call accuracy as a metric. Did the agent call the right tool at the right time? We report it per tool, not as one blurry average.
We also check the arguments. A valid type is not a correct value. Our post on tool argument accuracy explains why a well-typed call can still be wrong. And we test whether Jev's confidence stays calibrated on your traffic.
Independent measurement is the point. A vendor grading its own tool calls is not a check. See why in our post on independent voice AI evaluation, and in our broader work on voice agent evaluation and voice agent testing. For the foundation model behind all this, see Jev for voice agents.
Honest limits of Jev for tool calling
Jev is powerful, but it is not magic. Be clear about the edges.
Jev decides and scores. It does not write free-form arguments from nothing. For a novel string value, you still need an LLM or a constrained fill step. The hybrid pattern exists for this reason.
Jev works on the transcript and structured state. It does not read raw audio. A weak transcript can mislead a good decision, so speech-to-text quality still shapes the input.
Calibrated is not guaranteed. TypeSafe trained Jev with RLCD and reports calibrated confidence. Calibration is a statistical average, not a promise on any single call. That is why you measure the gate on your own data.
Jev is in early access as of September 2026. Treat it as new. Pilot it, measure it, and keep a fallback path.
Frequently asked questions
Can Jev hallucinate a tool name in a voice agent?
No. Jev picks a tool with a Choice question over the tools you defined, up to 255. The returned name is always one of your options. Because its output is schema-constrained, TypeSafe reports Jev adds 0% error on structured output, so a hallucinated tool name is impossible.
How is Jev different from an LLM for tool calls?
An LLM generates the tool call as text and can hallucinate or mistype it. Jev returns typed, calibrated decisions that fit the schema by design. TypeSafe reports Jev cannot emit an invalid value or wrong type. Use the LLM for generation and Jev for fast, structured tool decisions.
How does Jev decide whether a tool is needed?
Jev answers a Noul question, returning a yes or no probability with calibrated confidence. You ask if the current turn needs a tool. A confident yes triggers the tool path. A no lets the agent respond without calling anything, which avoids needless tool calls.
Can Jev block a risky tool call before it runs?
Yes. LangChain's AutoModeMiddleware uses Jev to check a tool call for risk and block it before execution. You ask a Noul safety question, and a low-confidence yes becomes a hold. TypeSafe documents this pattern in its LangChain harness post for gating high-impact actions.
How fast is Jev for tool-calling decisions?
TypeSafe reports Jev latency of 70 to 500ms per decision, roughly 40 to 200 times faster than an LLM on the same task. Jev also runs many questions in parallel per call, so tool-need, tool-choice, and safety checks can return together inside one conversational turn.
Does Jev replace the LLM in the tool-calling path?
Not fully. Jev decides which tool, whether a tool is needed, and whether a call is safe. It does not generate free-form arguments from nothing. The common pattern is hybrid: the LLM proposes a call, and Jev validates and gates it, or Jev selects the tool and a constrained step fills arguments.
What does structured tool calls with Jev mean?
It means the tool name and typed choices come back constrained to your schema. There is no fragile parsing step that might fail. Following JSON Schema and data validation ideas, the output already fits the required types, so an invalid field or wrong type cannot appear in the call.
How do you evaluate Jev tool calls?
You log each decision, then score it independently. Evalgent measures tool call accuracy per tool and checks whether the arguments were correct, not just well-typed. We also test whether Jev's confidence stays calibrated on your own live traffic, so your risk gates behave as you set them.
The bottom line
Jev makes the tool-calling path faster and removes hallucinated names and mistyped arguments by design. It still needs an LLM for free-form generation and an independent evaluator to confirm the calls were right.
Evalgent measures whether your Jev-driven tool calls actually served callers. Book a demo to audit tool selection, argument accuracy, and risk gating on your own calls.
Related Articles

Why AI voice agents fail in production (and how to prevent it)
AI voice agents that ace demos still break in production. Learn the 5 root causes, how to test for each, and what production readiness actually means.
Read more
Voice agent regression testing: why LLM updates break production
LLM updates improve benchmarks but break voice agents in 5 predictable ways. How to detect and prevent regressions after every model or prompt change.
Read more