TypeSafe's System One: code orchestrates

TypeSafe has published documentation for a model called Jev, which it describes as the first of a class it names System One models. The pitch is narrow and the argument underneath it is not.

The narrow version: large language models are built to produce text for a person to read, so using one inside software means coercing prose into structure and parsing it back out again. Jev skips that. You send a state and a set of typed questions in one call, and you get back typed values, probability distributions and a confidence number your code can branch on. No generation, no parsing.

The argument underneath is about who owns the control flow, and it is worth stating in their words rather than ours: "System One is TypeSafe's model for building AI-powered software, not agents. It does not generate code or choose its own next action."

That sentence is the whole disagreement with how most teams are currently building.

1. The three primitives

TypeSafe exposes three question types and calls them AI primitives, on the grounds that like software primitives they are modular, composable and fast enough to compose freely.

All three can be mixed in one request. Each question is evaluated independently and in parallel against the same state, which has two consequences TypeSafe is right to emphasise. Adding questions barely moves the response time. And because no question sees another question's answer, there is no accumulating context to rot.

The house style that follows from this is decomposition. Rather than asking a model to rate a startup pitch, you ask separately about market size, technical feasibility and differentiation, then combine the three with a formula you own. When the priorities change you edit a coefficient, not a prompt. That last detail is the part worth stealing even if you never call this API, because a weighting that lives in version control is testable and a weighting buried in a paragraph of instructions is not.

The naming is a nod to Kahneman. System 1 is the fast, intuitive judgment; System 2 is the slow deliberate one. The claim being made is that a great deal of what we currently send to reasoning models is System 1 work being billed at System 2 prices.

2. RLCD, and why calibration is the actual product

The AI primer is the more interesting of the two pages, because it explains the training objective rather than the API.

TypeSafe places itself as a third branch off pretrained language models, the architecture whose original design decisions we audited in Attention Is All You Need, nine years on. All three branches below start from the same place and diverge only in what they are rewarded for:

• RLHF, reinforcement learning from human feedback, which turned pretrained models into chatbots by training them toward responses people prefer.
• RLVR, reinforcement learning with verifiable rewards, which produced reasoning models that are strong at things like mathematics but slower and more expensive.
• RLCD, reinforcement learning for calibrated decisions, which is theirs. The model does not generate text. It returns decisions and probabilities, and a higher probability is meant to correspond to a greater chance the answer is right.

There is a nice piece of provenance here: the docs note that RLHF, used to train InstructGPT and ChatGPT, was co-invented by Diogo Almeida, a TypeSafe cofounder. The critique of RLHF in that page is therefore coming from someone with standing to make it.

The critique itself is the part to read twice. Optimising for human preference rewards sycophancy and confident-sounding hallucination, because both are preferred by raters. It also causes mode dropping, where the model narrows toward a favoured style and suppresses other valid outputs, a milder relative of the mode collapse that breaks generative adversarial networks. Their summary is blunt and correct:

An output can be compelling to a person without being reliable enough for unattended automation. Human preference and machine trustworthiness are different optimization targets.

Calibration is the alternative contract. Across many predictions, outcomes assigned a probability of 0.2 should happen about 20 percent of the time, and outcomes assigned 0.8 about 80 percent. The docs are careful to say this describes groups of predictions, not a guarantee about any single answer, and that caveat matters more than it looks. A calibrated model does not tell you this answer is right. It tells you how often answers that look like this one turn out to be right, which is exactly the input a threshold in your code needs and exactly the thing a fluent paragraph cannot give you.

This is the same complaint we made about benchmark aggregates in AGI talk measures the wrong axis. The industry optimises what reads well. Production needs what behaves predictably, and those have quietly become different targets.

3. Where your framing is right, and where it inverts

The prompt for this note was a reading we were sent, roughly: this confirms that deterministic core software being fast and cheap is the important thing, and that the LLM is the orchestrator, at least for now.

The first half is right, and TypeSafe says it more plainly than we would have dared to in a vendor document. Their first design step is "keep deterministic work in code. It is reliable and cheap," followed by advice to avoid agent loops where an ordinary software workflow expresses the same behaviour. A vendor whose revenue depends on model calls telling you to make fewer of them is worth noticing.

The second half is inverted, and the inversion is the most useful thing in this whole document.

TypeSafe is not arguing that the LLM orchestrates. It is arguing the opposite. Their three-way comparison puts it cleanly:

• Traditional software. A decision tree built from reliable primitives, composed into higher abstractions.
• LLM agents. The model reads instructions and picks its next step. This works when a person is watching, and, in their words, "every loop introduces another opportunity to go off the rails."
• AI-powered software. Code owns the control flow and handles the deterministic work. The model appears only where the system needs programmable common sense or has to interpret unstructured input, and each call is kept atomic and constrained.

They are selling the third. The second is the one your framing describes.

3.1 Two jobs that got fused

The confusion is worth naming precisely, because it is not a slip. The word orchestration has come to cover two separate jobs:

1. Owning the control flow. Deciding what happens next, in what order, under what conditions, with what permissions.
2. Interpreting unstructured input. Reading a message, a document, an image, a half-broken CSV, and turning it into something a branch can be taken on.

The agent pattern fuses them and hands both to the model. That is a genuine capability and it is why the pattern spread. But job one is a solved problem with fifty years of tooling behind it, and job two is the part that was actually hard until recently. Fusing them means paying model latency, model tokens and model variance for the half you already knew how to do reliably and for free.

So the refinement we would offer: the deterministic core stays in charge, and the model is a function call inside it. Not an orchestrator. A typed dependency with a probability attached.

3.2 Where you are still right

Two things keep your original reading alive, and we do not want to flatten them.

The first is that "for now at least" is doing real work. Most shipped agentic systems today do put a language model in the loop, and that is a fact about the world rather than a mistake everyone is making. It became the default because it was the fastest route from demo to something that worked at all, and because until very recently there was no typed, cheap, calibrated thing to call instead. Architectures follow the tools that exist.

The second is that there is a real class of work where the model should orchestrate: tasks where you genuinely cannot enumerate the control flow in advance. Open-ended research, debugging an unfamiliar codebase, anything where the next step depends on what the last step found. Coding agents are the obvious case, and they are the best argument the pattern has.

The honest rule is therefore not "never let the model drive". It is: know which of the two you are building. If you could draw the branches on a whiteboard before you started, you are paying agent prices for a flowchart. If you genuinely could not, an agent is the right tool and the cost is the price of the uncertainty.

4. The economics are the argument, not the philosophy

The reason this is more than an architectural preference is that the two designs sit in different cost classes.

TypeSafe reports that most queries complete in about 100 milliseconds, and states a target of a better than 100 times intelligence-to-speed-and-cost ratio, on the bet that cheaper intelligence creates much more demand for it. Treat both as vendor figures until somebody independent measures them. But the shape of the claim holds regardless of whether the specific numbers do, because it follows from the design rather than from optimisation.

A single call carrying many questions, evaluated in parallel, changes what a question costs. Their speculative fan-out pattern makes the point well: when triaging a support ticket, ask about category, bug severity, reproduction steps, refund intent and customer frustration all at once. If the ticket turns out to be a feature request, your code ignores the bug severity answer. The irrelevant question cost almost nothing because it ran alongside the others, and it saved a round trip in every case where it mattered.

Compare that with the agent version of the same triage, which is a sequence of turns, each one a full round trip, each one carrying the accumulated conversation, each one billed on input and output tokens that grow as the conversation does. We went through those mechanics in detail in what tokens actually cost, and the conclusion there was the same one that applies here: the metric that settles a production decision is cost per completed task, not cost per token or score on a leaderboard.

This is also the argument we made from the opposite direction in the small language models note. Capability and appropriateness are different axes. A model that can do far more than the task needs is not a free upgrade when you are paying for the headroom on every request in the hot path.

There is a longer-standing version of this lesson in our own work. The GPU query engine is fast for exactly the reason this API is: the expensive general-purpose thing is kept out of the inner loop, and the inner loop is made narrow, typed and predictable. Different decade, same principle.

5. Confidence is the part most teams will underuse

Every Choice and Score answer carries a confidence value from 0 to 1, derived from the shape of the probability distribution the answer already contains. A distribution concentrated on one outcome means a confident read. A flat one means the model has no clear winner, or the levels are ambiguous, or the state simply does not contain enough to go on. Noul answers do not carry one, since the returned probability is already the answer.

The documentation's framing is the right one:

If an intelligent system, whether human or machine, cannot express honest uncertainty, the system cannot be trusted.

The suggested pattern is three bands. High confidence acts automatically. Medium confidence proceeds carefully, asking the user to confirm or flagging for review. Low confidence does not act at all and routes to a person. The important refinement, and the one teams skip, is that a confidence threshold is not one number for the whole system. Their worked example is a voice banking interface with a floor of 0.6 for anything, and a bar of 0.85 before a transfer is approved without asking. Checking a balance at 0.6 is fine because the worst case is reading out the wrong number. Moving money is not.

Put that next to what we wrote about the GPT-6 Astra system card ten days ago and the two documents rhyme in a way neither company intended. That card's lesson was that chain-of-thought monitorability is degrading, action-level monitorability is improving, and the controls that survive are the structural ones: constrain what is reachable, gate the consequential actions, keep an immutable log of what was actually done. A typed answer with a calibrated probability, gated in your code at a threshold you set for the stakes, and written to a log, is that architecture. You are not reading the model's reasoning and hoping. You are recording a number, a threshold and an outcome.

It is the same conclusion we reached in governed autonomy about approval lanes, arrived at this time from the model side rather than the process side.

6. What we would want to know before building on it

Honest gaps, written as questions.

Does the calibration hold on your data? This is the whole product, and it is measurable. Take a few thousand labelled examples from your own domain, bucket the predictions by returned probability, and check whether the 0.7 bucket really is right about 70 percent of the time. Until you have done that on your own distribution, you have a vendor's word about a statistical property, which is not the same as a property.

What happens at the edges of the option set? Constraining output to the supplied options is what makes the response type-safe. It also means the model must distribute probability across options you wrote, including when the right answer is none of them. A flat distribution is the signal for that, which is exactly why the confidence floor is not optional.

How does it degrade on inputs it has not seen? Narrow models trained for a specific output contract tend to be excellent inside their distribution. The failure mode to test for is the adversarial or simply unusual input, and nothing published so far tells you what that looks like.

Text only, for now. Jev accepts strings, JSON and arrays of text. No images, audio or video yet. A good deal of real unstructured input in operations work is a photograph of a delivery note, so this bounds the use cases today.

Does the decomposition discipline survive contact with a team? The architecture asks you to keep questions atomic and hold the weighting in code. That is good engineering and it is also a habit, and habits erode under deadline. The failure mode is a Score question that quietly grows into a multi-factor judgment again.

We have not run Jev on our own workloads. Everything above is a reading of published documentation from a company describing its own model, and the speed, cost and calibration figures are its own. We will test it against the same tasks we test everything against and write up what we find, including if it contradicts this.

7. What to take from it

You do not need to adopt this API to take the useful part.

1. Write the control flow in code. If you can draw the branches, you should not be paying a model to rediscover them on every request.
2. Keep judgments atomic. One question, one dimension, combined by a formula you own.
3. Put the weights in version control. A coefficient is testable. A sentence in a prompt is not.
4. Demand a number, not a paragraph. If a decision gates money, access or safety, the thing your code branches on should be a value with a distribution behind it.
5. Set thresholds by consequence. One confidence bar for the whole system means the cheap decisions are over-gated and the expensive ones are under-gated.
6. Log the decision, the number and the threshold. That record is what you will have when somebody asks why the system did what it did.

The deeper point in your original reading stands, and we would put it more strongly than you did. The deterministic core is not the boring part that AI is slowly replacing. It is the fast, cheap, testable, auditable part, and the last two years have mostly been the industry rediscovering why it was built that way. What has genuinely changed is that we can now call a reliable judgment from inside it, cheaply enough to put in a hot path. That is a new primitive, not a new architect.

If you are deciding where the model belongs in a system you are about to build, or you suspect you are running an agent loop around a flowchart, talk to us, or see how we build systems for businesses.

8. Sources

1. TypeSafe, Introduction, the Jev overview, the three primitives and the atomic-questions guidance quoted above.
2. TypeSafe, AI primer, RLHF, RLVR and RLCD, calibration, mode dropping and the preference-versus-reliability argument.
3. TypeSafe, System One, the model class, the Kahneman naming and the text-only input limitation.
4. TypeSafe, How to build with TypeSafe, the three architectures, the "not agents" statement, the 100 millisecond figure and the 100 times ratio target.
5. TypeSafe, Confidence and Confidence-gated routing, the three bands and the stake-scaled thresholds.
6. TypeSafe, Speculative fan-out and Intent routing, the single-call pattern and the route-to-the-cheapest-handler example.
7. Daniel Kahneman, Thinking, Fast and Slow, 2011, the source of the System 1 and System 2 distinction the model class is named for.

Vendor documentation describes a product the vendor is selling, and every performance number above originates with the company that makes the model. We have flagged which claims are theirs rather than measured. The architectural argument, though, stands on its own reasoning and does not require you to believe any particular benchmark.

This note sits in our Engineering track, alongside the agentic, system design and foundation models threads. The full library is at Research.