Jev: A Typed 'Intelligent If' for High-Speed Agent Decisions

We've Been Using LLMs as Hammers for Too Long

Current agents rely heavily on general-purpose LLMs for decisions such as tool selection, completion verification, risk assessment, and retrieval evaluation. While this works, it is inefficient: many judgments have only a few possible answers, yet LLMs generate token by token, requiring waiting, parsing, validation, and retries. For a simple classification like "billing, engineering, or sales," this pipeline is too heavy.

TypeSafe AI defines Jev as the first public "System One Model," referencing Kahneman's System 1: fast, bounded judgments rather than prolonged reasoning. Official end-to-end latency is 70–500 ms , input price is $0.042 per million tokens , output is free. Benchmarks claim 193.6× faster and 444.6× cheaper , though TypeSafe notes these are best-case workflow numbers, not universal guarantees.

What Is Jev?

Simply put: Jev is a semantic if-switch. You provide a state (text or JSON describing the situation) and a set of questions. Each question declares an answer type, and Jev cannot deviate from that schema.

Choice

: pick one from given options, returning probabilities for each. Score: place input on an ordered scale (e.g., low, medium, high). Noul: answer a yes/no question, outputting probability of truth.

Example: a deployment fails twice, users see 500 errors. You can ask Jev simultaneously whether it is urgent and which team (engineering, billing, sales) should handle it.

{
  "model": "jev-latest",
  "state": "部署连续失败两次，用户正在遇到 500 错误。",
  "questions": {
    "urgent": {
      "type": "noul",
      "instructions": "这件事是否需要立即处理？"
    },
    "owner": {
      "type": "choice",
      "instructions": "应该由哪个团队处理？",
      "criteria": {
        "engineering": "产品故障和服务中断",
        "billing": "扣款、发票和退款",
        "sales": "价格和新客户"
      }
    }
  }
}

The response contains no free text to parse and no invented options. Code receives probabilities and decides whether to page on-call, queue, or escalate to human review. Multiple questions in one request are computed in parallel, eliminating sequential ask-wait-ask cycles.

Probabilities Are More Valuable Than Final Labels

If Jev assigns a ticket to "billing," the label only tells you who won; the probability distribution reveals how confident that win is. For instance, "billing 52%, engineering 46%, sales 2%" — billing leads but auto-routing is risky. Such results should go to human review or a stronger model.

Thresholds must be coded and bound to consequences. Tagging internal reports may tolerate 60% confidence; judging a destructive command requires a much higher threshold plus permissions, sandboxes, and human confirmation.

Jev's training method is RLCD (Reinforcement Learning for Calibrated Decisions), aiming to align reported confidence with empirical accuracy. If Jev frequently gives 90% probability to an answer set, that set should be correct ~90% of the time over the long run.

A common marketing claim is that Jev "does not hallucinate." The precise statement: Jev never violates its declared output types, but it can still pick a wrong valid answer. With options limited to billing, engineering, sales, it will not suddenly return "legal" or emit prose. However, it may confidently misclassify an engineering fault as billing. Type safety guarantees schema conformance, not infallible judgment.

Three Checkpoints Where Jev Fits in an Agent Loop

Jev does not replace LLMs. LLMs handle planning, writing, explaining, coding, and open-ended reasoning; Jev handles the recurring micro-judgments around those tasks.

1. Model routing. Simple queries, extraction, and local edits go to fast models; architecture design, high-risk ops, and ambiguous tasks go to strong models. Jev decides who answers, not the answer itself.

2. Tool risk checking. Before an agent runs a shell command, Jev can classify it as read-only, recoverable, or destructive — checking for file deletion, Git history rewrite, production touch. LangChain's Jev middleware demonstrates this.

3. Result verification. An agent claiming completion does not mean the task is done. Jev can judge whether tests passed, output complies with policy, or the agent is looping. However, problems solvable by deterministic tests should stay with tests, not models.

The same capabilities apply to support triage, retrieval re-ranking, citation verification, prompt injection detection, content policy review, and bulk document labeling. Common thread: answer space is known, humans can judge at a glance, but the system must repeat the judgment thousands of times.

What Suits Jev and What to Avoid

Jev fails with open-ended answers: it cannot write replies, summarize documents, generate code, or explain reasoning. It is also unreliable for arithmetic, counting, date comparison, and exact string operations — use plain code for those.

If a judgment requires multi-step hidden reasoning, break it into smaller questions or switch to a reasoning model. Jev cannot extract a value from an unknown space; candidates must be identified first.

Current limitations: only processes text or structured state (no vision), weights not open, product in early access, limited independent calibration data. Official charts show promise but are insufficient to hand high-risk workflows to Jev without validation.

Recommended progressive rollout:

Pick a high-frequency judgment with clear answer space and low consequence.

Write explicit rules for each option; don't let the model invent business logic.

Collect real samples, deliberately adding ambiguous and adversarial inputs.

Run in shadow mode: record results without changing existing flow.

Plot accuracy vs. confidence on your data, then set thresholds.

Automate the safest branch first; fall back to human or stronger model on uncertainty.

Version the model, questions, criteria, and thresholds; re-run the same test set after every change.

Questions themselves are part of the program. They should be versioned, reviewed, and tested like code.

Jev belongs where a plain if understands numbers but not semantics. Keep deterministic code for what it does well; hand unbounded answer spaces back to LLMs or humans.