Use cases · Last updated 2026-09-21

Intent routing with Jev

Not every request deserves the same handler. TypeSafe’s intent-routing pattern puts Jev in front as a fast classifier:

Some intents are a database lookup (order status).
Some need a specialist LLM (product question, returns).
Some need a human (unclear intent, or a complaint that scores too complex).

This unofficial page restates that pattern and links the glossary. Official mermaid + Python: docs.typesafe.ai/patterns/intent-routing. We do not sell keys.

Two questions, one call

Their customer-service sketch:

Choice intent — order_status, product_question, return_exchange, complaint, …
Score complexity — used when the intent is a complaint.

Then code (their thresholds are examples):

If intent confidence < 0.5 → human
order_status → deterministic handler
product / returns → different LLM system prompts
complaint → human if complexity.score > 1 or complexity confidence is low; else a complaint LLM

The expensive model runs only when the cheap decision says it must.

Compare to rules and queues. Pair with confidence-gated routing when the same intent has different risk levels. Sort probabilities for a ranked route only after the floor passes.

Worked sketch: hotel booking concierge

A hotel chat widget should not send every turn through a guest-facing LLM. Official pattern: classify handler class, then code. Floors below are illustrations, not shipped defaults.

{
  "guest": "Do I still have the late checkout I booked last night? Also the minibar was billed twice.",
  "stay": { "reservation_id": "H-441", "late_checkout": true }
}

Id	Type	Options / levels
`intent`	Choice	`res_lookup` / `amenity_question` / `folio_dispute` / `other`
`complexity`	Score	routine → needs desk (3 levels)

intent, cx = answers["intent"], answers["complexity"]
if intent.confidence < 0.5:          # official example floor — fit yours
    return human("front_desk")
if intent.choice == "res_lookup":
    return lookup(stay["reservation_id"])
if intent.choice == "amenity_question":
    return llm(AMENITY_PROMPT)
if intent.choice == "folio_dispute":
    if cx.score > 1 or cx.confidence < 0.5:
        return human("night_audit")
    return llm(FOLIO_PROMPT)
return human("unmapped")

res_lookup is a database hit. amenity_question is a specialist LLM. folio_dispute uses the Score the way TypeSafe uses complaint complexity. Do not clone their mermaid; cite the intent routing pattern.

This is not model routing (which class picks a generator). Jev does not write the guest reply. Jaggedness: no dates — “last night” stays text; the PMS has the checkout flag.

Pin jev-1.13.0. Vendor $0.042 / M input (claim). POST https://api.typesafe.ai/v1/systemone.

When not to use

A single deterministic menu already covers 100% of turns.
You need Jev to generate the confirmation email.
You treat 0.5 as a universal law. Fit on offline evaluation.

Handler class and model class are different cuts. If the PMS lookup already returned the reservation, do not also route a frontier chat model “to be safe.” Log intent.choice, full probabilities, and confidence so a night-audit reviewer can see why the folio path fired. Schema-safe res_lookup is not proof the reservation id is valid — your code still hits the PMS.

FAQ

Is intent a reserved API field? No. You name the key. See glossary: intent.

Should every company use 0.5? No. Fit on your labels (offline eval). Official floors are examples.

Choice cap? ≤255 options. Deep hotel taxonomies should cascade — see triage workflow.

Can jev.pro sell me a key for the concierge? No. Confirm access on docs.typesafe.ai.

Hub: Use cases. Official: docs.typesafe.ai.

Disclaimer

This is an independent unofficial site and is not affiliated with TypeSafe AI; official documentation is available at https://docs.typesafe.ai. Never treat jev.pro as TypeSafe official documentation. We do not sell, issue, or proxy API keys.

Sources

Intent routing