System One models: From generative intelligence to a decision layer for enterprise AI

System One models are arriving at an important moment in enterprise AI. Organizations have become comfortable using large language models (LLM) to generate, summarize and reason, but production workflows contain a second class of work that is easy to overlook: thousands of small semantic judgments that determine what the system should do next. A support case must be routed. A document must be classified. Retrieved evidence must be judged sufficient. A transaction may need review. An agent has to decide whether to call a tool, ask for more context, escalate or stop. These decisions are not naturally “writing” problems, even though many current systems solve them by calling a generative model.

That mismatch matters because architecture follows the interface a model exposes. When every semantic judgment is expressed as a prompt and every result arrives as generated text, orchestration inherits the latency, cost and variability of language generation. System One models propose a different interface: provide the model with a defined state and a bounded set of typed questions, and receive probabilistic decisions that application logic can use directly. TypeSafe AI introduced the category publicly in September 2026 with Jev, describing it as a model built for fast, structured decisions rather than open-ended string generation.

The interesting question for enterprises is therefore larger than whether Jev is faster than a chat model on a benchmark. It is whether decision-focused models can become a distinct computational layer inside enterprise software: a layer that sits between deterministic code and slower generative reasoning, handles high-frequency semantic control, and gives agentic systems a more economical way to decide when deeper intelligence is actually necessary.

What is a System One model?

A System One model is an emerging class of AI models optimized for fast, bounded judgments that software can consume directly. TypeSafe's terminology borrows from the System 1/System 2 distinction in cognitive psychology: System 1 is associated with fast, intuitive judgment, while System 2 is associated with slower, effortful reasoning. The analogy is useful, but it should not be taken literally. A machine model is not reproducing human cognition; the terms describe a division of computational labor.

The defining characteristic is the model interface. Rather than asking for an arbitrary string, the developer specifies the state – the relevant context the model should evaluate, such as a ticket, transaction, policy excerpt, retrieved evidence set or workflow record and the allowed decision shape in advance. The output therefore lives inside a known answer space. Its answer must fall within the options the application has already defined: a routing decision may choose from approved teams, a risk judgment may use an ordered severity scale, and a gate may return the probability that a specific condition is true.

The core abstraction
state -> typed questions -> model inference -> probabilities / typed answers -> application control flow

This makes System One models closer to probabilistic functions embedded in software than to conversational endpoints. The model supplies semantic judgment; the application decides how to use it. Code can compare the returned probability with a threshold, combine several signals, request more evidence, route to human review, invoke a reasoning model or execute a deterministic action.

The term is not yet a standard academic category. At present, it is TypeSafe's name for a model family and programming approach. Related ideas already exist across classification, learned routing, moderation models, ranking, neural decision systems and adaptive retrieval. What is new is the attempt to bring those ideas together behind a general-purpose typed interface with frontier-style semantic understanding, parallel decision evaluation and explicit uncertainty signals.

Jev: the first public implementation

Jev is TypeSafe AI's first public System One model published on 15 September 2026 and built by Diogo Almeida, previously at OpenAI and a co-author of the InstructGPT paper. The public documentation describes it as a hosted, text-oriented model that receives a shared state and one or more typed questions. It returns one answer object per question, including probability information. TypeSafe currently exposes Jev through a System One API and SDKs rather than as downloadable model weights.

TypeSafe positions Jev around four properties: decisions instead of generated strings, type-safe outputs, parallel evaluation of multiple questions and calibrated uncertainty. The company also reports large latency and cost advantages on its own workflow benchmarks. Those numbers are useful as evidence of the intended operating regime, but they are not universal performance guarantees. TypeSafe itself notes that its largest speed and cost ratios are likely at the high end of real-world gains, and its workflow evaluation uses reference probabilities from large external models rather than ground-truth labels.

That methodological detail matters. A benchmark based on agreement with strong LLM outputs can indicate that Jev behaves similarly to those models on selected workflow-style tasks. It does not, by itself, prove that the decisions are correct for a specific enterprise process. For adoption decisions, organizations should evaluate the model against their own labeled cases, reviewer outcomes, operating constraints, latency requirements and cost targets.

For enterprise readers, the useful question is not only what Jev claims to do, but which parts of the model contract are already visible in public documentation and which parts still require independent validation in real workflows.

System One vs structured-output LLMs

The easiest way to misunderstand System One models is to compare them with an old pattern in which an LLM is merely prompted to 'return JSON.' That comparison is no longer sufficient. Modern LLM APIs can enforce structured outputs through constrained decoding. OpenAI's structured outputs, for example, can constrain generation to a supplied JSON schema so that the result conforms to the allowed structure. This removes an important class of formatting failures.

The difference is not simply that Jev has structured/typed outputs while LLMs do not, because modern LLMs can also be constrained to return structured outputs. A frontier LLM can also be wrapped in a type-safe interface. The more consequential differences lie in the model's native objective, inference shape and output semantics.

A structured-output LLM is still fundamentally a generative model. It autoregressively produces a token sequence, even when a decoder masks tokens that would violate the schema. The schema constrains which sequences are legal; it does not change the fact that the model is producing a sequence. A System One model, as TypeSafe [2] describes it, is built around bounded decisions directly and uses a parallel sampler to evaluate outputs without generating an explanatory string.

That difference may matter most when a workload contains many small judgments. A single structured LLM call can absolutely classify a ticket, return a risk score or select a tool. The question is whether invoking a powerful text generator is the most efficient primitive when the task never requires text. System One models bet that specialization can deliver a better latency-cost-reliability profile for that shape of work.

The table below clarifies the practical distinction: structured-output LLMs make generative responses easier to control, while System One models are positioned to make bounded decisions a native part of software control flow.

System One models and the missing decision layer in enterprise AI

Enterprise AI stacks are becoming increasingly capable, yet they often use the same class of model for very different kinds of work. A reasoning model may be asked to interpret a complex policy memo, but the same model is also asked to decide whether a case belongs in queue A or queue B. It may generate a contract summary and then be called again to answer a yes/no question about whether a required clause is present. It may plan a multi-step task and then repeatedly decide which of three tools should execute next. The second set of operations is semantically meaningful, but it is bounded. The system does not need an essay; it needs a reliable branch condition.

This is the architectural gap System One models are designed to address. TypeSafe describes [1] Jev as accepting unstructured or semi-structured state and returning typed probabilistic decisions. The application defines the allowed answer space in advance, so the model is not free to invent a new category, emit an unexpected object shape or wrap the answer in prose. That changes the model’s role from content producer to decision component.

The useful comparison is not “System One versus LLM”

For enterprise architecture, the more productive comparison is between three different responsibilities.

• Deterministic software handles what must be exact: arithmetic, entitlement checks, API calls, persistence, transaction execution and hard policy enforcement.
• System One handles semantic judgments that are fuzzy but bounded: classify, score, rank, route, gate, assess and select.
• System Two handles tasks where the answer space cannot be specified cleanly in advance: reasoning, planning, synthesis, explanation and generation.

The distinction is important because each layer has a different failure model and a different cost profile. Deterministic software is rigid but predictable. System Two is flexible but expensive and often slower. A decision-focused model gives architects a middle layer: learned semantics without the full overhead of open-ended generation. In a mature enterprise stack, the goal is not to replace one layer with another. It is to allocate computation according to the shape of the decision.

Why this matters now

The first generation of enterprise GenAI applications was dominated by user-facing experiences: copilots, search interfaces, drafting assistants and chat. In those systems, one model call could often produce one useful output: an answer, a summary, a draft or a recommendation.

Agentic systems create a different workload. Once software begins acting across tools, records and processes, it repeatedly encounters branch points. Which customer record is relevant? Which policy applies? Is the retrieved evidence sufficient? Which tool should run next? Is this action routine or exceptional? Should the workflow continue, invoke a reasoning model, pause for human review or execute a deterministic step?

This concentration of repeated judgments can be understood as decision density: the number of semantic decisions an application must make to complete one useful business outcome. A chat application may have modest decision density because the interaction often centers on producing a response. An enterprise agent may need dozens of routing, relevance, confidence, verification and escalation decisions before a single workflow step is complete.

Once decision density rises, repeatedly invoking a large generative model becomes expensive architectural overhead: the workflow pays for generation, latency and output handling even when the task only requires a bounded judgment. A procurement workflow, for example, may not need a reasoning model to classify every request type, check whether basic evidence is present or decide whether a case follows a standard route. It may only need deeper reasoning when policy language is ambiguous, spend exposure is material or the request falls outside standard rules.

That is where System One models become architecturally interesting. They give teams a way to place fast, bounded judgment inside the workflow while reserving slower reasoning models for the moments where interpretation, synthesis or explanation creates real value.

This is why System One models may be more consequential for enterprise automation than for conversational AI. The end user may never see a System One output. Its value sits in the control path: deciding what the system should do next, quickly and economically enough that intelligent branching can be used throughout a workflow rather than only at a few expensive checkpoints.

From generation to typed decisions: how the model works

The easiest way to understand a System One model is to look at the contract it creates between software and intelligence.

In a typical LLM workflow, the application sends a prompt and asks the model to generate a response. Even when the response is expected to follow JSON schema or a function-calling format, the model is still working through a generation interface. The application then validates, parses and interprets the generated output before deciding what should happen next.

A System One workflow starts from a different assumption: the application already knows the shape of the decision it needs. The model is not asked to write an answer in natural language. It is asked to evaluate a defined state against one or more typed questions and return decision-ready outputs that software can use directly.

The pattern can be summarized as:

Prepare state → define typed questions → read the structured response → let application code decide the next action

That shift is important because many enterprise workflows do not need a paragraph from a model. They need a bounded judgment: which queue should handle this case, how severe is this issue, is the evidence sufficient, should this action require review, or should the workflow escalate to a deeper reasoning model?

That is why the workflow begins not with a broad prompt, but with a more disciplined design sequence: prepare the state, define the typed question, read the structured response and let application code decide what happens next.

Step 1: Prepare state

State is the context the model uses to answer the question. It should contain the relevant facts needed for the judgment, not an entire business process compressed into one oversized prompt.

In practice, state may be:

• a natural-language message, such as a support ticket, incident note, alert or user report.
• a JSON object containing fields such as customer tier, order value, policy status, workflow stage, region, priority and case history.
• an array of text items, such as related messages, retrieved knowledge snippets or prior interaction summaries.

For enterprise use, state design is where much of the value is created. A weak state forces the model to guess from incomplete context. A well-assembled state gives the model the exact evidence needed for a narrow decision.

For example, a support-routing workflow should not pass a long conversation and ask the model to “handle this customer.” It should pass the customer message, product area, account tier, open incidents, entitlement status and routing rules relevant to the next decision. A procurement workflow should not ask the model to “review this purchase.” It should pass the purchase request, supplier category, contract status, spend threshold, policy references and exception indicators needed to decide whether the case should move forward, pause or route for review.

Current Jev documentation [3] indicates that supported direct inputs include text, JSON objects and arrays of text. Images, audio and video are not currently described as direct input formats. That matters for implementation planning: multimodal workflows may need an upstream extraction or transcription step before a System One decision can be applied.

Step 2: Define typed questions

After the state is prepared, the application defines the questions the model should answer. Each question should represent one clear judgment.

This is a major design difference from broad LLM prompting. Instead of asking one model call to understand the case, decide the risk, select the owner and recommend the action, a System One workflow breaks the work into smaller decision contracts.

For example, avoid a bundled question such as:

“Should we retain this customer, which team should follow up, and what should happen next?”

A stronger design would separate the decision into smaller questions:

• Which team should handle this case?
• Does the case require a retention workflow?
• Is the current evidence sufficient for automated routing?
• Should a human reviewer approve the next action?

This makes the workflow easier to test, tune and govern. Each question has a defined purpose, a bounded answer space and a clear relationship to application logic. Developers can evaluate whether the routing decision is accurate, whether the escalation decision is too aggressive, or whether the evidence-sufficiency threshold needs adjustment.

TypeSafe's public Jev interface currently describes three question primitives: Choice, Score and Noul [4]. Together, they cover many of the branch points that appear inside enterprise software.

The important point is not only that the output is structured. It is that the decision is designed before the model is called. The workflow designer defines what can be answered, what answer space is valid and how the result will be interpreted downstream.

The three Jev primitives turn that design principle into practical decision patterns: Choice selects from known options, Score evaluates against an ordered rubric, and Noul estimates whether a specific proposition is true.

Choice: select from a defined set

Choice is designed for classification, routing and selection. It is useful when the application knows the possible destinations or categories in advance.

Examples include:

• Should this support request go to billing, technical support, implementation or account management?
• Is this document a contract amendment, renewal notice, purchase order or policy exception?
• Should this agent use a fast model, a deeper reasoning model, a retrieval workflow or a human-review path?
• Which policy category best fits this case?

The options should be written with clear descriptions, not just labels. For enterprise workflows, this avoids vague categories that overlap in practice. A routing decision such as “billing” versus “account management” should clarify whether payment failure, invoice correction, renewal negotiation or entitlement dispute belongs in each path.

It is also useful to include an other, unknown or none-of-the-above option when real-world cases may not fit the known categories. Otherwise, the model may be forced to choose the closest invalid answer, which can create false confidence in downstream routing.

Score: rate against an ordered rubric

Score is useful when the application needs an ordered judgment rather than a single category. It can support severity, urgency, priority, satisfaction, risk or readiness assessments.

Examples include:

• How urgent is this customer escalation?
• How sufficient is the evidence package?
• How risky is this transaction based on the provided state?
• What priority should this case receive in the review queue?

The quality of a Score question depends heavily on the rubric. A weak rubric says, “Score urgency from low to high.” A stronger rubric defines what each level means in operational terms.

For example, an escalation rubric may define:

• Low: No immediate customer impact; response can follow normal SLA.
• Medium: Customer impact is present but contained; queue prioritization is needed.
• High: Business-critical impact, executive visibility or contractual exposure may be present.
• Critical: Immediate intervention is required before further automated action.

This makes the score useful in real systems because application code can connect the result to SLAs, queue priority, review requirements and escalation policy.

Noul: judge whether a statement is true

Noul is designed for binary propositions. It returns a yes probability between 0 and 1, making it useful for decisions that can be framed as “Is this statement likely to be true?”

Examples include:

• Is the customer explicitly asking for a refund?
• Is this document relevant to the current case?
• Does this tool call require human confirmation?
• Is the retrieved evidence sufficient for the next workflow step?
• Does this case appear to involve a policy exception?

Noul is especially useful for gating decisions. A workflow can use a yes probability to determine whether to proceed, pause, retrieve more information, escalate to a reasoning model or request human review.

However, complex conclusions should not be collapsed into one binary question. For example, instead of asking, “Should this case be approved?”, a better design may ask:

• Is the required document present?
• Does the requested action match the policy category?
• Is customer approval evidence available?
• Does the case require manager review?

The application can then combine those answers in code. This is easier to test, easier to explain and safer to govern than asking one broad model question to decide the entire outcome.

Step 3: Read the structured response

Once the model evaluates the state and questions, it returns structured answers linked to the question IDs sent by the application.

The returned fields depend on the question type. A Choice question can return the selected option, probabilities across candidates and confidence-related information. A Score question can return the selected score, legend, probability distribution and confidence-related information. A Noul question returns a yes probability.

Responses may also include runtime metadata such as usage information and elapsed request time.

For developers, the practical value is that the response is easier to consume than generated text. The application does not need to infer whether “this probably belongs to collections” means an actual route, a suggestion or a weak recommendation. It receives a typed output that can be mapped to workflow logic.

For enterprise teams, the value is observability. Decisions can be logged as structured events: the state version, question ID, answer, probability, threshold, route taken and reviewer outcome. Over time, those records can support calibration analysis, exception review, threshold tuning and governance reporting.

Step 4: Let application code decide the next action

The model makes the judgment. The application decides what is allowed to happen next.

This distinction is essential in enterprise architecture. A System One model should not become the authority that executes business actions by itself. It should provide a typed probability that application logic can evaluate against policy, thresholds and workflow rules.

For example:

• If routing confidence is high, code can call route().
• If evidence sufficiency is low, code can call retrieve_more().
• If policy risk is above threshold, code can call request_review().
• If the case is complex, code can call a reasoning model.
• If the action is high impact, code can block automation until an authorized reviewer approves it.

This is where System One models become valuable in production. They do not merely return cleaner outputs. They make it possible to design AI-assisted branch points as explicit contracts:

state in → typed probability out → controlled action next

That structure lets organizations separate model judgment from business authority. The model can classify, score or assess. Software enforces thresholds, permissions, audit logging and escalation policy. Human reviewers remain involved where the decision carries risk, financial exposure, regulatory impact or customer consequence.

Why this matters for enterprise workflows

The significance of System One models is not that they make every AI task simpler. It is that they expose a better interface for a large class of decisions that enterprise systems already make thousands or millions of times.

Many production workflows contain small but consequential branch points:

• route this case
• prioritize this exception
• select the right tool
• decide whether evidence is enough
• determine whether a deeper model is worth invoking
• identify whether a human checkpoint is required

When those decisions are handled through open-ended generation, organizations may be paying for more reasoning, latency and output handling than the task requires. When they are modeled as typed decisions, teams can define the answer space, measure decision quality, tune thresholds and connect the result directly to workflow action.

That is the real shift from generation to typed decisions. The model is no longer only a language interface. It becomes a decision component inside software architecture.

Parallel decision inference changes the cost shape

One reason TypeSafe positions Jev differently from structured-output LLMs is its use of a vendor-described parallel sampler rather than ordinary autoregressive decoding. In practical terms, multiple questions about the same state can be evaluated together instead of generating one textual answer after another.

This matters because enterprise workflows rarely need just one judgment. A transaction may need to be classified by exception type, assigned an urgency score, checked for policy relevance and assessed for escalation in the same step.

With an autoregressive model, asking for four answers still means generating tokens that encode those four answers. With a decision model, the application can treat the four judgments as a batch over shared state. The architectural benefit is not simply “faster responses”; it is that the marginal cost of adding another bounded judgment can become low enough to make richer control logic practical.

TypeSafe reports[5] end-to-end Jev latency in the tens to hundreds of milliseconds and publishes large cost and speed advantages on its own workflow evaluations. Those measurements are vendor-reported and should be treated as directional rather than universal. The more important enterprise implication is the shape of the interface: if semantic micro-decisions become substantially cheaper than generative calls, architects can move intelligence deeper into ordinary control flow instead of reserving it for a few high-value prompts.

Calibration is what turns probability into an engineering signal

A typed answer is useful, but a typed answer with meaningful uncertainty is more useful. TypeSafe describes [6] Jev as trained with Reinforcement Learning for Calibrated Decisions (RLCD), with the goal of producing probabilities that more faithfully track when the model is likely to be right. The full training process is not publicly documented, so RLCD should be understood as TypeSafe’s stated training approach rather than a broadly established standard.

The underlying calibration idea is straightforward. If a model assigns roughly 0.8 probability to a large set of comparable judgments, an ideally calibrated system would be correct on about 80 percent of those cases. That does not mean an individual 0.8 prediction is “80 percent correct.” It means the probability becomes useful when aggregated across similar decisions and tested against observed outcomes.

For enterprise workflows, this supports a much richer control model than simple classification. Teams can define different operating bands: high-confidence cases may proceed automatically; medium-confidence cases can trigger additional retrieval or a System Two model; low-confidence or high-impact cases can go to human review. Probability therefore becomes a routing signal inside the workflow rather than a decorative confidence score shown to the user.

The architectural shift
Prompt engineering asks, “How do I get the model to say the right thing?” Decision engineering asks, “What decision is being made, what answer space is legal, what evidence should shape it, how should uncertainty change the path, and who is allowed to act on the result?”

Where System One creates enterprise value

The strongest business case for System One models is not generic productivity. It is the ability to place semantic judgment inside high-volume processes without paying the full cost of generative reasoning at every branch. That creates value in four connected ways: lower decision latency, lower inference cost, more composable workflows, and a clearer boundary between model judgment and business execution.

Where the ROI comes from

The ROI case for System One models should be measured at the workflow level, not only at the model-call level. A cheaper or faster inference call matters, but the larger value comes from changing how work moves through the enterprise process.

In practical terms, System One models can create measurable value in seven ways:

This distinction is important for enterprise buyers. The value of System One is not simply that an individual model call may be faster or cheaper. The larger value is that more decisions can be made closer to where work happens, while expensive reasoning, manual review and high-control actions are reserved for the cases that justify them.

A useful ROI assessment should therefore compare the current workflow with the redesigned workflow.

• How many generative-model calls are avoided?
• How much triage effort is reduced?
• How many cases move faster?
• How often are reviewers focused on the right exceptions?
• How often does the system escalate uncertain decisions instead of forcing a brittle automated path?

Those measures are more meaningful than latency or token cost alone because they connect the model architecture to operating performance.

The right metric is not cost per token; it is cost per governed decision completed.

High-frequency semantic control becomes economically viable

Many enterprise workflows contain decisions that are too contextual for hard-coded rules but too narrow to justify a frontier reasoning call. Consider a revenue assurance workflow processing millions of usage events. Deterministic logic can reconcile totals and apply known thresholds, but some exceptions still require semantic classification: is this variance likely to reflect tariff configuration, provisioning mismatch, partner-settlement timing or an expected commercial adjustment? A generative model can answer that question, but calling it for every candidate exception can dominate the economics of the workflow.

A decision-focused model is attractive when the output is already bounded and the result only determines what happens next. The workflow can classify the exception, assign a probability, and invoke deeper reasoning only when the classification is uncertain or when the financial exposure justifies additional analysis. This creates a cascade in which expensive intelligence is spent selectively rather than uniformly.

Agents can spend reasoning where reasoning has economic value

Agentic systems often use LLMs as both the brain and the workflow controller. The same model plans the work, selects tools, evaluates retrieved context, checks whether a step succeeded and decides when to stop. That design is convenient during prototyping because one model can do everything. In production, it can become inefficient because control decisions are repeated much more often than genuinely difficult reasoning tasks.

System One creates a way to separate those concerns. A fast decision model can handle tool selection, relevance scoring, evidence sufficiency, risk gating and handoff decisions. A reasoning model can then be reserved for the moments that actually require synthesis or multi-step analysis. The result is not a “weaker” agent. It is an agent whose computational budget is allocated according to the complexity of each step.

Structured uncertainty makes automation boundaries easier to operate

Most enterprises do not want fully autonomous software making every consequential judgment. They want bounded automation: routine cases should flow through quickly, unusual cases should receive deeper analysis, and high-impact cases should stop for review. That operating model depends on the system being able to express uncertainty in a way orchestration logic can consume.

Typed probabilities make that boundary explicit. A procurement intake agent might classify a request as standard, non-standard or policy-sensitive. A high-confidence standard request can move directly into deterministic validation. A medium-confidence result can invoke a System Two model to compare the request with policy text. A policy-sensitive classification can route the case to procurement or legal. The value is not just faster classification; it is that the enterprise can define what each confidence band is allowed to do.

Decision logic becomes observable as part of the workflow

When semantic control is buried inside a long prompt, it is difficult to inspect which sub-decisions drove an outcome. Decomposing the workflow into explicit questions changes that. The system can retain the state presented to the model, the typed question, the probability distribution, the selected branch, the threshold in force and the downstream action. That creates a cleaner operational record for debugging, calibration analysis and governance.

This matters in enterprise environments because agent performance cannot be judged only by the quality of the final answer. Teams also need to understand whether the workflow routed correctly, escalated appropriately, used the right evidence and stayed within approved operating boundaries. Teams need to understand where the workflow is losing accuracy, where thresholds are too aggressive, whether certain business segments are drifting, and which decisions most often trigger human review. A decision plane produces telemetry at the same level at which the workflow actually branches.

A practical portfolio: where the System One model fits

The common pattern is more useful than any individual use case. System One is strongest where the enterprise already knows the shape of the decision, needs to make it frequently, and wants the result to control a workflow. If the task requires a novel explanation, a negotiated interpretation or open-ended content, System Two remains the better tool. If the task can be encoded completely as a rule, deterministic software should usually do it. The economic opportunity sits between those two extremes.

How System One and System Two models work together in agentic systems

The most important architectural implication of System One models is not that they replace generative AI. It is that they make it easier to design agentic systems with separate fast and slow layers. Instead of treating the agent as one large model that plans, routes, checks, verifies and writes, architects can separate the decisions that control the workflow from the reasoning that interprets complex cases.

This distinction matters because agentic systems make many decisions before they produce a final output. Some of those decisions are narrow: Which record is relevant? Which tool should run next? Is the evidence sufficient? Should the workflow continue or stop? Others require deeper interpretation: What does this policy mean in context? How should conflicting evidence be reconciled? What explanation should be prepared for a reviewer or customer?

A System One layer is useful for the first class of work. A System Two layer is useful for the second. Deterministic software and human checkpoints still govern what the system is allowed to do.

A three-plane enterprise pattern

A useful production architecture can be understood as three connected planes: decision, reasoning and execution. The decision plane evaluates state and determines the next branch. The reasoning plane handles open-ended interpretation, synthesis and explanation. The execution plane performs deterministic actions under enterprise controls.

The decision plane does not own the business action. It proposes the branch. Enterprise policy determines what that branch is allowed to trigger. A model may judge that a case is probably routine, but policy logic decides whether “probably routine” is enough for straight-through processing, whether another model should verify it, or whether an authorized reviewer must approve the next step.

This keeps semantic intelligence separate from authority. System One can help decide what path the workflow should take, but deterministic controls and accountable roles still determine what the workflow is allowed to execute.

Where Jev-Mem fits: an early research signal, not the whole pattern

Jev-Mem provides an early research example [7] of the fast/slow pattern, but the architecture is broader than memory systems. Agentic memory is useful because it contains many decisions that are semantic, bounded and repeated: how to type a memory, whether two memories are related, where to route a query, which candidates are relevant, whether the retrieved evidence is sufficient and when retrieval should stop.

In Jev-Mem, these control decisions are assigned to a System-One controller, while System Two is reserved for synthesis and final reasoning. In the authors’ LoCoMo evaluation, the architecture reported a memory build time of 158 seconds versus 1,044 seconds for the fastest competing memory system, and average query latency of 0.93 seconds versus 1.47 seconds for the fastest memory-based baseline. The result is early research, not a general enterprise benchmark, but it illustrates an important systems principle: frequent control decisions do not always need to stay on the autoregressive reasoning path.

The same principle applies beyond memory. Retrieval does not always need a reasoning model to decide whether a document is relevant. Tool selection does not always need a chain of thought. A model router does not need to generate prose. A verifier does not need to explain itself unless the workflow requires an explanation. The architecture becomes more efficient when each decision is matched to the simplest form of intelligence that can make it reliably.

Example: a governed invoice-exception agent

Consider an accounts payable workflow that handles invoice exceptions. The agent receives the invoice, purchase order, receipt record, supplier master data and relevant policy context. A System One layer first classifies the exception type, such as quantity mismatch, price mismatch, tax discrepancy, missing receipt, duplicate risk or another defined category. It also scores whether the evidence package is complete enough for the next step. Those decisions determine the workflow path.

Straightforward, high-confidence exceptions can be routed to deterministic checks against the ERP, purchase order and receiving data. If the evidence is incomplete, the decision layer identifies what is missing and the workflow retrieves the required records before deeper reasoning is invoked. If the case requires interpretation, such as conflicting contract language or an unusual commercial term, the workflow calls a System Two model to synthesize the evidence and prepare a review packet.

If the proposed action exceeds policy thresholds or changes a financial record, the workflow stops at the required human checkpoint. After approval, deterministic services execute the update and the workflow records the input state, decision probabilities, reasoning output, approvals and system actions as runtime evidence.

This is a more useful model of enterprise autonomy than one agent reasoning continuously from beginning to end. Intelligence is distributed across the workflow. System One handles the dense layer of semantic control. System Two handles the smaller set of cases that require difficult reasoning. Deterministic services and human approvals retain authority over consequential actions.

Engineering System One into production

Adopting a System One model is less about replacing an API endpoint and more about redesigning how decisions are represented. The quality of the production system will depend on how well the team defines state, decomposes decisions, chooses thresholds and measures outcomes. This is why “decision engineering” is a better frame than prompt engineering for this class of model.

A compact evaluation framework for enterprise teams

Before adopting a System One model, teams should test whether the target workflow actually has the right shape. Not every AI decision needs a System One model. Some decisions are better handled by deterministic rules, traditional classifiers, structured-output LLMs, reasoning models or human review.

A practical evaluation can start with six questions:

If most answers are yes, the workflow is a strong candidate for System One style design. If the answer space is open-ended, the task requires explanation or synthesis, or the organization cannot measure outcomes, a reasoning model or human-led workflow may be more appropriate. If the decision can be expressed as an exact rule, deterministic software should usually handle it.

The framework keeps the adoption discussion grounded. The goal is not to insert System One models wherever a model can make a judgment. The goal is to find high-frequency, bounded decisions where typed probabilities can improve routing, reduce unnecessary generative-model calls, make escalation more consistent and give the enterprise a clearer control record.

Once a workflow passes this evaluation, the next step is to map where those bounded decisions sit inside the process. That map becomes the workflow’s decision topology.

Start with decision topology, not with prompts

Adopting a System One model is not just a matter of replacing one model API with another. The first step is to understand how the workflow actually moves from one state to the next. Every enterprise process contains branch points: a case is routed, evidence is accepted or rejected, a task moves forward, an exception is created, a reviewer is assigned, or a deeper model is invoked.

Before designing prompts or model calls, teams should map those branch points clearly. Which steps are deterministic? Which steps require bounded semantic judgment? Which steps need deeper reasoning or explanation? Which decisions can trigger an automated action, and which ones must stop for review?

This map becomes the workflow’s decision topology. It shows where intelligence enters the process, what each decision controls, what information the decision depends on, and what downstream consequence follows. That view is more useful than a broad use-case label such as “AI for procurement,” “AI for customer support,” or “AI for finance operations” because it identifies the exact points where model judgment changes system behavior.

For example, in an invoice-exception workflow, deterministic code can check whether invoice totals match the purchase order. A System One model can classify the exception type and score whether the evidence package is complete. A reasoning model can interpret unusual contract language or summarize conflicting records. A human approver can authorize any action that changes a financial record. Each layer has a defined role, and each decision has a known consequence.

This is why decision topology matters. It prevents teams from treating the workflow as one large prompt and instead helps them design a controlled sequence of decisions: what state is available, what question is being asked, what answer space is valid, what confidence is sufficient, what action follows, and when the workflow must escalate. In a production setting, that structure is what makes System One useful, testable and governable.

Design state as an engineering artifact

System One decisions are only as good as the state they receive. Passing an entire document or conversation because it is available is rarely the best design. State should be assembled around the decision: relevant fields, retrieved evidence, current process stage, prior outcomes, policy context and provenance. This reduces noise and makes evaluation easier because the team can inspect exactly what information was available when the judgment was made.

In practice, state design becomes similar to feature engineering, but with richer semantics. Teams should document which fields are authoritative, which context is optional, how stale data is handled, how provenance is retained and what happens when required evidence is missing. A System One call should not silently compensate for an incomplete process state that the application could have detected deterministically.

Treat thresholds as operating policy

The model returns a probability; the organization decides what that probability means operationally. A 0.92 classification may be sufficient to route a low-impact service ticket automatically but not sufficient to approve a financial adjustment. Thresholds therefore belong to the operating model, not just the ML configuration.

A mature implementation defines threshold bands by decision type and business consequence. The band may determine straight-through processing, additional retrieval, second-model verification, System Two reasoning or human review. The threshold should be versioned, monitored and changed through an accountable process because a threshold change can alter the effective autonomy of the workflow without changing the model at all.

Evaluate the decision, the branch and the business outcome

Offline model accuracy is necessary but not sufficient. Teams should evaluate at three levels. First, did the model make the right bounded judgment? Second, did the orchestration logic choose the right branch given that judgment and the threshold? Third, did the overall workflow improve the business outcome, cycle time, exception resolution, review load, service level, recovery rate or another process measure?

This prevents a common failure mode in AI programs: optimizing the model metric while ignoring the process. A slightly less accurate decision model can still create more value if it is faster, better calibrated and designed to escalate uncertainty safely. Conversely, a strong model can deliver poor results if thresholds are aggressive, state is incomplete or downstream automation is poorly controlled.

Keep the boundary between judgment and authority explicit

The most important production principle is simple: model confidence is not business authorization. A model can estimate whether an action is appropriate, but policy, permissions and accountable roles determine whether the system is allowed to execute it. This boundary becomes especially important when System One is used for risk, compliance, financial or customer-impacting decisions.

The practical control set is familiar: role-based access, policy gates, human checkpoints, exception paths, model/version logging, input-state lineage, threshold history and runtime audit trails. These are not “limitations” of System One; they are the surrounding controls that make any learned decision service suitable for enterprise use.

How ZBrain can operationalize System One models in enterprise agentic workflows

ZBrain is an enterprise agentic AI orchestration platform for discovering, designing, building, and deploying agentic AI solutions within a governed framework. It provides the orchestration layer needed to combine enterprise data, AI models, deterministic logic, human review and system actions within a controlled operating environment.

System One models can fit into this architecture as specialized decision components. Their fast, bounded judgments can support repeated decision points within an agentic workflow, while larger language or reasoning models remain available for tasks that require interpretation, synthesis, planning or explanation. Deterministic services can continue to enforce exact rules and execute approved actions, while human reviewers retain authority at defined checkpoints.

ZBrain supports this operating model through four core capabilities:

• ZBrain Analyzer acts as the discovery layer of the solution lifecycle, systematically capturing the critical context required for successful technical design. It engages functional teams to capture institutional knowledge, operational workflows, system dependencies, and key requirements, providing the contextual foundation for the downstream design process.
• ZBrain Design helps translate a selected use case into a technical design that defines how models, data, applications, workflow logic, integrations and human review work together..
• ZBrain Solution Builder enables teams to build and validate agentic workflows that can combine System One models with reasoning models, enterprise systems and deterministic services.
• ZBrain Governance provides the policies, permissions, human approval boundaries, monitoring and audit evidence needed to control access, actions and oversight across the solution lifecycle.

Within this architecture, System One models do not operate as standalone decision makers. ZBrain can incorporate their outputs into agentic workflows alongside reasoning models, enterprise rules, application logic and human oversight.

This makes System One relevant not simply as a faster inference mechanism, but as one component of a broader enterprise decision architecture. By combining specialized decision models with orchestration, governance and human control, ZBrain can help enterprises use System One models where fast, bounded judgment is appropriate while reserving deeper reasoning and decision authority for the parts of the workflow that require them.

Endnote

The most interesting possibility raised by System One models is that generative AI may have encouraged developers to overgeneralize the interface for machine intelligence. Text became an extraordinary universal adapter because humans can express almost any task in language. But software does not need a universal adapter at every point in the stack. It often needs a label, a score, a rank, a gate, a probability or a decision about what should happen next.

For enterprise leaders, the strategic question is not whether System One models will replace the existing LLM stack. It is where the organization is currently using generative models for decisions that are fundamentally bounded: classify this case, select this route, assess this condition, verify this evidence, determine whether to escalate or decide whether deeper reasoning is required.

Those branch points matter because they often sit inside the highest-volume parts of an enterprise workflow. When every small judgment is handled as a generative task, organizations can end up paying reasoning-model costs for work that does not require open-ended reasoning. System One models introduce a different design option: represent the decision explicitly, constrain the possible outcomes, return a probability over those outcomes and let application logic determine the next permitted action.

If specialized decision models continue to mature, future AI systems may look less like one large model surrounded by tools and more like a hierarchy of intelligence primitives. Fast decision models could handle local judgment. Reasoning models could be called when interpretation, planning or synthesis justifies the additional cost. Deterministic services could enforce invariants and execute approved actions. Human reviewers could remain concentrated at points of genuine ambiguity, authority and accountability.

That would change the design language of enterprise AI applications. The central question would no longer be only, “Which model should answer the user?” It would become, “Which form of computation belongs at each decision boundary?” In some places, the answer will be rules. In others, it will be a classifier, reranker, System One model, reasoning model or authorized reviewer. The architecture becomes compositional rather than model-centric.

For developers, this shifts part of the engineering challenge from prompt construction to decision design. The important questions become: What state should the model see? What decision is actually being made? What answer space is valid? What confidence is sufficient for automated action? When should the workflow escalate to a reasoning model or an authorized reviewer? And what evidence should be retained around that decision?

In that architecture, System One is not the replacement for generative AI. It becomes the layer that helps the enterprise decide where reasoning is actually worth spending.

That may ultimately be the most important value of the model category: not simply making individual decisions faster or cheaper, but making the entire AI system more deliberate about where intelligence, latency, cost and human attention are used.

Build governed agentic workflows with ZBrain that combine System One models, reasoning models, enterprise data and human oversight. Explore how ZBrain can help operationalize fast, bounded decisions across enterprise processes.