JEV AI + Asterisk: Upgrade Your IVR with Qwen

JEV AI can give an Asterisk voice agent a dedicated decision layer: classify a caller's turn, take a short validated route for simple answers, and ask Qwen to interpret the difficult ones. The state machine still decides what the application is allowed to do.

In Build Your Own AI IVR Agent, we connected telephony, speech recognition, a restricted LLM interpreter and a deterministic conversation flow. This follow-up develops the next improvement: a Jev-first design that reduces how often an ordinary turn needs the larger language model.

Imagine saying “Repeat that,” selecting a known category or asking for a person. Those requests need a bounded decision and an appropriate response. A sentence containing several details and a correction needs richer interpretation. Giving both paths their own responsibilities is the opportunity.

This is an implementation blueprint for the planned improvement, illustrated with fictional, sector-neutral incidents. It is not a report of a completed Jev production rollout or a Jev latency benchmark.

What is JEV AI, and why put it before an LLM?

TypeSafe introduced Jev on September 15, 2026, as a System One model for structured decisions. It accepts context and typed questions instead of producing an open-ended conversational reply. That makes it relevant to routing inside an AI agent. TypeSafe announcement.

For this IVR, “above the LLM” means that Jev helps select the interpretation path. It does not become the owner of permissions, execute backend operations or invent the words spoken to the caller. Application code combines its results with the current dialogue state.

Three question primitives support different jobs: choice selects among declared alternatives, noul estimates whether a proposition is true, and score evaluates a defined scale. Our proposed routing primarily uses the first two. TypeSafe introduction.

Typed output narrows the shape of an answer; a model can still choose the wrong category. That is why the application must retain validation, an ambiguous option, clarification and human assistance.

From an LLM interpreter to a hybrid Asterisk voice agent

The original design sends recognized speech and context to its restricted interpreter. The new design inserts a decision step and preserves the existing interpreter as a fallback.

Figure 1. Proposed architecture. Both decision routes reach the same validation layer. Keypad input is interpreted by code in its current menu context.

A clear request for a person can reach the handoff flow without waiting for the larger LLM. A simple category selection can advance to the next missing field. Qwen remains useful when someone says, “The incident affects device A—actually, device B—and it started yesterday.”

The potential benefit is fewer large-model invocations on ordinary turns. The additional decision request also adds work, especially when fallback is necessary. Whether the combined experience improves must be measured across both routes.

Give Jev the question the caller actually heard

A transcript alone is insufficient. “Two” might select the second menu option or form part of a reference. “Yes” might approve a summary or merely request another service.

Build a compact state object containing the original transcript, the current state (INTENT, COLLECT, CONFIRM, MORE or HELP), the question that actually started playing, its offered choices, the expected field and relevant validated data. Keep a dialogue revision and attempt counter in code. If a lookup uses a year, fix it at call start according to the application's configured timezone.

Record playback progress as well: starting a summary does not prove the caller heard enough of it to confirm. A correction or interruption must invalidate an obsolete confirmation opportunity.

TypeSafe documents text-based state, including structured JSON; Jev does not receive the raw telephone audio in this design. Its documentation also notes that accuracy outside English needs particular attention. Evaluate the caller's actual language, including Spanish, rather than assuming English results transfer. State documentation.

For each turn, select only the questions relevant to that state:

Use an explicit unknown or ambiguous outcome in category questions. Each question evaluates the same input independently; do not write one whose answer requires seeing another answer from the same request. Combine those results afterwards in code. Choice documentation.

Jev does not extract arbitrary text through a yes/no answer. For a single literal description, code can retain the original transcript after checking that it answers the expected field. Splitting several fields or resolving a complex correction belongs to the larger interpreter.

Route each turn without handing over control

Figure 2. A proposed routing policy. Contradictory evidence triggers clarification or fallback, and every path respects the current dialogue revision.

The proposed order is human assistance or an explicit risk signal, cancellation, repetition, then field collection and correction. Ambiguous or contradictory results should not silently populate a field.

Initial tuning candidates are a top-option probability of at least 0.90 and a margin of at least 0.25 over the next option for ordinary categorical selections; 0.95 for confidently classifying a request as outside scope; and a 0.80 noul threshold for flagging an explicit risk for human review. These are starting policies, not measured Jev guarantees. A lower risk threshold prioritizes review; it does not diagnose an emergency or replace an emergency procedure.

Choice probabilities and confidence are different fields. TypeSafe describes confidence as a statistic derived from the probability distribution, not an independent measurement of correctness. A Noul answer instead exposes a noul probability and has no separate confidence field. Confidence and Noul.

The bounded failure policy is equally important: propose a one-second deadline for the Jev request, no retry inside that turn, and at most one fallback interpretation. A timeout, service error or invalid response returns to the existing interpreter. Its initial 20-second limit remains a ceiling to review, not a conversational latency target.

Both routes must produce the same internal intent-and-fields contract. Validate that contract before advancing the state machine. Keep the Jev client separate from Pi's conversational interface and verify the actual provider contract; a local compatibility gateway's chat endpoint is not automatically Jev's native API.

What changes in a real conversation?

These are fictional examples for a generic incident service, not recordings or real requests.

Once help has been offered, wait for the caller's request or a valid keypad selection. A digit only selects a menu item when that menu is active. Explicit requests for a person do not need to exhaust the clarification budget first.

At confirmation, “yes” is accepted only for the current summary, with no pending correction and enough playback evidence. At MORE, the same word means the caller wants another task, so ask which one and start it with clean task data.

For a prototype, the completion message remains honest: “Your test request is prepared. It has not been submitted.” A real integration must verify the backend outcome before announcing success. A status lookup likewise needs authorization; knowing a reference is not sufficient proof of access.

Improve the voice loop as well as the model route

Figure 3. Conceptual voice lifecycle, not a measured timeline. The 800 ms marker is a proposed waiting-notice trigger from processing start.

Pregenerate greetings, menus, clarification prompts and handoff notices. Build variable summaries from validated values and synthesize them during the call. Keep variable audio containing caller data in the call's isolated memory rather than a shared prompt catalog.

Schedule a short waiting notice for 800 milliseconds after processing starts. Cancel it if the response is ready first. If final audio becomes ready while the notice plays, stop the notice and start the useful response. The notice must not delay an already authorized lookup. Reserve hold music for an actual backend lookup, not every inference request.

Barge-in must stop queued speech and invalidate obsolete work. Asterisk documents FLUSH_MEDIA for discarding queued media; the application still needs cancellation signals and revision checks for model responses and generated audio. Asterisk WebSocket documentation.

When someone hangs up, cancel pending work and timers. When someone changes a field, reject results produced for the old revision. When a transfer is attempted, distinguish destination answer and a completed bridge from a human actually answering: an automated queue greeting does not establish human contact.

How to introduce the change and measure the result

Use three explicit modes. In off, keep the existing interpreter. In shadow, collect decision outputs for evaluation while the original path continues to control the conversation. In enforce, allow validated decisions to select the short route, with fallback intact. Version the questions, thresholds and audio catalog alongside the code, and instantiate the heavier interpreter only when needed.

Test corrections, ambiguous menu selections, mixed requests, unavailable models, invalid results, silence, interruptions, a late response and a hangup. Include spoken digits, keypad entry and phrases such as “yes, but…” in the caller's language. Functional completion and transcription quality need separate results.

Measure the following before claiming a faster AI phone agent:

Our previous article measured speech recognition and interpretation separately; those measurements cannot establish the speed of this Jev architecture. We are not rebranding measurements from another decision model as Jev results. Benchmark Jev with a fixed version, the same test corpus and recorded service conditions, then repeat through real telephony. Report unsuccessful and canceled work too.

A practical brief for implementing the JEV integration

Adapt this brief to an existing agent whose ASR, Qwen and TTS services already work:

Add a Jev decision client before the existing restricted interpreter.
Keep the current state machine as the owner of dialogue and actions.
Use fictional generic incidents in examples and tests.

Build state from transcript, active state, played question, offered
options, expected field, validated data and dialogue revision.
Select independent Choice/Noul questions appropriate to that state.
Verify the provider API; do not assume chat-completions compatibility.

Validate every result. Use explicit unknown outcomes and tunable
per-category thresholds. Never equate probability with authorization.
Preserve one fallback interpretation for complex or uncertain input.
Set a 1-second decision deadline and no within-turn decision retry.

Preserve correction handling, current-summary confirmation, contextual
DTMF, cancellation, hangup cleanup and human assistance.
Use prepared fixed audio and TTS for validated variable responses.
Make the 800 ms waiting notice cancellable and non-blocking.

Add off, shadow and enforce modes. Log route and timing metadata
without recording caller text or audio by default. Test both routes,
their failures and stale revisions. Report precisely what was tested.
Keep test preparation separate from any authorized backend write.

The useful deliverable is an adapter and a testable routing policy, not a longer prompt giving the model ownership of the telephone call.

Can this decision layer run locally? KEV and Qwen

For teams exploring self-hosting, Kev is a separate open-source family of Jev-like decision models built on Qwen3.5. Its repository provides models, training code and serving instructions, including 0.8B, 4B and 9B variants. It is not Jev under another name, and API similarity does not establish equivalent accuracy, calibration or latency.

The portable part of this design is the application contract: structured decisions enter the same validation and state-machine boundary. A local alternative still needs its own multilingual evaluation, hardware sizing and provider adapter. Verify its license and the selected model's terms for the intended deployment.

JEV AI and Asterisk: common questions

Does Jev replace Qwen in an AI IVR?

In this design, Jev handles bounded routing decisions. Qwen remains the interpreter for complex utterances, and the application determines which path to use.

Does Jev listen to calls or generate the voice?

The integration feeds Jev text after ASR. Prepared prompts and a separate TTS service produce the spoken response; Asterisk transports and plays it.

Will this make every call faster?

That is not established. Simple turns may avoid a larger-model request, while fallback adds a decision step. ASR, backend and audio delays still matter.

What should remain outside model control?

Authorization, current-summary confirmation, backend execution, call isolation and the rules for cancellation and transfer. The next version of the agent should make those boundaries easier to test while making ordinary conversations less cumbersome.