System 1 vs System 2 starts with the shape of the work

Consider two questions about the same code change. “Does this touch authentication?” and “Will existing sessions survive this deployment?” Both fit in a sentence. The second can hide an investigation: find how tokens are issued, follow how they are validated, inspect compatibility, then test what actually happens.

That is the useful engineering distinction behind System 1 and System 2: a focused judgment over available evidence versus a process that develops intermediate results. With Jev making the first a dedicated model interface, my rule is to route work by its dependencies first. Confidence becomes useful after we have given the model an appropriate job.

What System 1 and System 2 mean for AI

Daniel Kahneman popularised the distinction in Thinking, Fast and Slow: fast, intuitive judgment alongside slower, deliberate thought. In AI, I use these labels as a working analogy. They describe the kind of computation we want to organise; they do not specify a universal model architecture.

For a System 1 style task, the evidence is already present and the question is narrow. Given a diff and a clear rubric, classify the affected subsystem. Given a retrieved paragraph and a question, judge relevance. Whether a particular model does either reliably still needs evaluation.

System 2 style work builds something along the way: an intermediate conclusion, a plan to test, a result the next step depends on. The chain-of-thought research by Jason Wei and colleagues, first submitted in January 2022, demonstrated improvements across several reasoning tasks by eliciting intermediate steps. That supports spending computation on a reasoning process. It does not make a longer explanation proof of correctness.

The useful question in a design review is therefore concrete: what must be established before this decision can be made?

Why Jev makes the distinction practical

TypeSafe introduced Jev on 15 September 2026 as its first System One model. Its interface takes state and typed questions, then returns structured judgments. The deliberate specialisation is the interesting part: choosing and scoring become small operations that software can call repeatedly.

TypeSafe's documentation says questions in one request are evaluated independently against the same state. Several questions can examine the supplied evidence together. An answer that must become evidence for a later question still needs another stage in the workflow.

The boundary is visible in TypeSafe's own Jev 1.13 limitations, reviewed on 17 September. Additional indirection can reduce accuracy. Precise arithmetic and date comparisons belong in code. These are useful constraints for an engineer designing the work.

I covered the broader opportunity in Jev explained and the rise of the decision layer. Here, the design choice is narrower: where does a focused judgment end, and a dependent investigation begin?

Dependencies can live in code or in a reasoning process

Return to the deployment example. This is a hypothetical design, not a Jev experiment I have run.

I would let a fast model help classify the diff and identify relevant evidence. The application would fetch the referenced code and run known compatibility checks. If the release policy requires a session migration test, that test runs regardless of how confidently the diff was classified.

Some dependencies are already understood. A parser extracts a version, code compares it with supported versions, and a test checks the required behaviour. We can make those steps explicit once and execute them repeatedly.

Other dependencies emerge during investigation. A changed token field leads to an older validator; the validator leads to a cache assumption; that assumption suggests a missing test. A reasoning model can help investigate and propose the next check. Its conclusions still need evidence.

My architectural bet is that useful systems will move between these modes within a single task. A deliberate investigation can produce a small question for a fast model. A fast judgment can expose ambiguity that deserves investigation. The application preserves the state and enforces the checks across both.

The order of decisions matters. Use this sequence for each stage, and reassess when a result changes the task:

rendering diagram…

If required evidence cannot be obtained, the decision stays unresolved. More reasoning cannot substitute for a test result nobody has collected.

Confidence has a scope

TypeSafe's confidence documentation makes a distinction worth preserving. For Choice and Score, confidence summarises the shape of the returned probability distribution. Noul returns a probability without a separate confidence field. Operating thresholds must be tested on the actual task.

A confident authentication label tells us about that classification. It says nothing by itself about session compatibility. Passing its confidence threshold should not quietly promote it into evidence that the deployment is ready.

This is why I would design escalation in two stages. First, task requirements decide whether evidence collection, exact computation or dependent investigation is necessary. Then uncertainty within an eligible fast judgment can trigger further review. A known dependency should never have to wait for the model to sound unsure.

To test that design, take a labelled sample from one real workflow. Include clear classifications, ambiguous cases and cases with missing prerequisites. Measure incorrect decisions that passed the fast route, the work sent for further investigation, and total completion time and cost. Tune thresholds on one set and check them on another.

What's in it for you

• Split one broad agent instruction into judgments, known computations and dependent investigations. Assign each an explicit owner.
• Record what each confidence score actually measures. Keep required evidence and checks outside that score.
• Compare completed outcomes at the same acceptable error rate. A faster intermediate answer only helps if the whole workflow benefits.

Choose the reasoning process from the work it must complete; use confidence inside that boundary.