Fast decisions, deliberate reasoning: why AI quoting needs both

A customer sends a clarification while your team is preparing a quote:

For bracket B-214, please use drawing Rev D for your updated quote. Rev C required anodizing; Rev D specifies an as-machined finish with no coating. The order quantity remains 5,000 units. Please revise your quote to reflect the finish change.

Recognizing that this belongs with estimating is straightforward. Updating the quote takes more work. Someone needs to check Rev D, reconcile it with the governing specification, identify which operations change, and recalculate the estimate.

Those tasks need different tools. A quick classification can get the message to the right place. Interpreting the requirements may need a language model and the relevant documents. The cost change needs explicit inputs and calculations. An engineer still needs to approve the result.

Small, frequent decisions like these are a useful application for System One models. At Nyotta, we tested Jev on synthetic supplier messages, including this bracket clarification, to measure its classifications and repeatability.

What System 1 and System 2 mean here

Daniel Kahneman popularized the distinction between System 1, fast and intuitive thinking, and System 2, deliberate, effortful thinking. It is a useful analogy for designing AI workflows, rather than a literal description of how a model works. Thinking, Fast and Slow

In quoting, recognizing a delivery complaint is a small judgment. Deciding which requirement governs when a drawing and specification disagree requires gathering evidence and working through the conflict. Treating both as the same kind of model request can waste effort on simple tasks or underspecify difficult ones.

The distinction is about the task, too. A general-purpose LLM can classify a message quickly or spend longer reasoning through a problem. And some work belongs in neither category: multiplying an approved rate by a quantity should use a calculation, not a model's intuition.

What is Jev?

Jev is TypeSafe's first System One model. You give it the information to evaluate and questions with defined answer types. Its documented primitives are Choice, which selects an option; Score, which evaluates a rubric; and Noul, which evaluates a proposition with a value from zero to one. Choice and Score also return probability distributions and confidence. TypeSafe documentation

For example, we asked Jev to assign a message to one of these outcomes:

quality | logistics | estimating | purchasing | review | none

The application can use that answer to route work. TypeSafe describes its questions as evaluated in parallel, which makes the interface worth exploring when several small judgments concern the same input. Introducing Jev

When the workflow needs a decision, it does not always need a speech. The joke is about the interface: general-purpose LLMs can also return structured outputs.

What we tested

We tested message classification and request latency using jev-1.13.0 on September 21, 2026. Jev received synthetic text and our instructions, without drawings, order history, or previous conversations. We wrote expected labels before execution.

For 30 business messages, we asked two Choice questions in each call:

1. Which team should handle the request? The options were quality, logistics, estimating, purchasing, review, and none. Review covered unidentified or unrelated issues; none covered explicit no-action updates.
2. What is the information state? The options were clear, conflicting, insufficient, and no_action. Clear meant an identifiable request or issue, rather than verified facts or permission to act.

The messages covered defects, delivery delays, price changes, conflicting reports, missing context, routine updates, and quoting requests. Our routing policy prioritized quality, then logistics, estimating, and purchasing when several issues appeared together. Each message was sent three times to measure repeatability.

For the bracket clarification above, Jev returned estimating and clear on all three calls. It also returned estimating and clear for this message:

The customer specification states, "Reject parts with cracks." This is an acceptance criterion, not a report of defective parts. Please include the required crack inspection in your quotation.

That matched our intended distinction between an inspection requirement and a current defect.

Measure	Result
Team selections matching our labels	90/90 calls (100%)
Information-state selections matching our labels	87/90 calls (96.7%)
Messages matching both labels on every repetition	29/30
Messages returning the same pair of labels across all three calls	30/30 (100%)

The last row measures label repeatability, independently of agreement with our labels. The selected answers stayed the same across repetitions, although the probability distributions sometimes changed. Three calls per input are a small consistency check, not evidence of deterministic behavior across future requests or model versions.

The disagreement involved this message:

Please resolve the issue on PO 4812 that I discussed with your colleague yesterday. Could you ask them for the details and let me know the next step?

Jev returned review and clear on all three calls. We expected review and insufficient because the underlying problem was missing. But our wording allowed clear to mean an identifiable request: asking a colleague for details qualifies. Jev's answer is defensible. Jev matched our expected answers in 87 of 90 calls. The three disagreements came from one ambiguous question repeated three times; either answer was defensible.

This matters when defining a workflow. “Is the request understandable?” and “Do we have enough information to resolve the problem?” need separate questions. A model's confidence cannot repair an ambiguous definition.

How latency changed with more questions

We used one message reporting a late delivery, cracks found during inspection, and a requested price increase on the next order. We defined sixteen proposition questions, including whether the message reported cracks, mentioned a delivery delay, or provided a purchase-order number.

We then asked the first question alone, the first four together, and all sixteen together, with six calls per group:

Questions per call	Median latency	Observed range
1	211 ms	176–285 ms
4	198 ms	190–208 ms
16	237 ms	199–290 ms

These are end-to-end HTTP timings, including network overhead. Calls were sequential, with no application retries or excluded warmups. Asking sixteen questions did not take sixteen times as long in this test. Six observations per group cannot establish production throughput or a speed advantage over another model.

Together with seven diagnostic messages sent three times each (21 calls), the evaluation comprised 129 successful requests, all passing our local response-shape checks. The diagnostic messages tested instruction attacks and unrelated requests; they are excluded from the business-message results above.

How we’re using this approach at Nyotta

In Nyotta, we separate document classification and extraction from numerical estimation. Drawing regions are classified before their features are extracted, and those features retain their source locations for review. Dedicated estimation code uses the resulting inputs to produce estimates and surface warnings.

This gives each component a specific job. Models help interpret engineering information; estimation models and code produce the numerical result. A reviewer can check the source interpretation and the estimate separately.

In the bracket scenario, Jev’s role is narrow: classify the customer’s clarification and route it to estimating. It returned the expected route on all three calls in our experiment. Completing the quote still requires the actual drawing and specification, accepted cost inputs, and engineering approval.

Why use Nyotta instead of asking a generic LLM to quote?

LLMs are part of Nyotta. We use their language understanding and reasoning for interpreting requirements, extracting information, and helping explain what needs review. A quote also needs engineering data, a defined estimation method, calculations, and approval.

In Nyotta, extracted drawing features retain their source locations. Dedicated estimation code handles numerical estimates, checks inputs, and reports warnings. That separation lets a reviewer inspect the source interpretation and the estimate on their own terms.

The roles in a quoting system should be explicit:

Task	Appropriate tool or owner
Interpret a requirement or draft a clarification	A language or multimodal model, with the source available for checking
Classify a narrow request	A rule or decision model evaluated for that task
Reconcile conflicting requirements	Relevant documents, reasoning, and engineering review
Estimate cost or price	A defined estimation model with the required business inputs
Apply rates, quantities, and constraints	Code, formulas, and validation rules
Accept an assumption and release a quote	The authorized engineer or approver

An LLM can call those tools. The calculation still needs to execute against the accepted inputs, and the result needs to retain its basis. In the bracket example, removing anodizing must affect the applicable operation costs; the new price needs to follow from the estimate.

Nyotta's value is in connecting model interpretation to that engineering work. A model such as Jev fits the classification step. Its usefulness depends on the task and the surrounding checks, just as an LLM's does.

The meaningful comparison is a real RFQ: can your team trace requirements to the source, inspect the cost inputs, and see what still needs approval?