Enterprise agents need a decision layer

The smartest model in your stack should not make every decision.

In part one, I introduced the agent harness, the architecture around an agent that gives it context, constrains what it can do, and makes its behavior observable and governable. Part two is about one decision inside that harness. Should the same model make all of them?

Probably not. A collections agent decides whether a customer message is a dispute, which team or sub-agent should handle it, which tool to call next (an action it can take in another system, like pulling open invoices from the ERP or drafting an email), whether it needs more context, how risky an action is, and whether to escalate. Then it has to reason through the exception and draft a nuanced reply.

While all of these are decisions, they are not the same kind. A common agent pattern still sends almost every one of them to the same general-purpose reasoning model. It works, but most of those decisions could be made faster and more cheaply.

A model that cannot write

On September 15, 2026, TypeSafe AI released Jev in early access. Jev does not generate text. You give it some state and a set of typed questions. It returns a choice from a fixed list, a score, or a yes/no probability, each with a confidence. TypeSafe calls this class System One models, after Kahneman's fast, intuitive mode of thinking, and reports end-to-end latency of 70 to 500 milliseconds.

It looks like this: some state, a typed question, and a fixed list of answers.

State

Customer says: "We haven't paid because the delivered quantities don't match our purchase order."

Question

What is the primary reason for non-payment?

Options

pricing_dispute, quantity_dispute, service_dispute, cashflow, unknown

The system is not being asked to write. It is being asked to decide.

Generation and decision-making do not always need to be the same operation.

From one model to a category in two weeks

Jev stood alone for three days. Within 16 days, teams at AWS and Cloudflare had shipped open decision models of their own, and OpenAI had announced a Decisions API.

Sep 15, TypeSafe Jev

The first System One model, in early access as a hosted API.

Sep 18, Laya

Open weights, Apache 2.0, 421 million parameters on a ModernBERT-large backbone.

Sep 29, OpenAI Decisions API

Announced at DevDay in limited preview, built on a version of GPT-6 Luna, for classification, routing and choosing next actions.

Oct 1, AWS Strands Decider 2B

From the Strands Labs team at AWS: a 2 billion parameter open-source model, released with its training data and scripts, built to run on a local CPU or GPU.

Oct 1, Cloudflare Clef and Clef-flash

Cloudflare's first in-house models: 27 billion and 9 billion parameters, Apache 2.0 weights, hosted on Workers AI, Jev API compatible, with an RL fine-tuning service.

Sources: TypeSafe, Laya, OpenAI, Strands Decider, Cloudflare Clef

Three of the five ship open weights, and the interface is converging. Strands Decider, Laya, and Clef all follow Jev's System One API, so a system built against hosted Jev can move to weights you control by changing an endpoint and a model name.

We have been here before

Bounded decisions are not new. Encoder models such as BERT have been fine-tuned for years to classify intent, route documents, and flag sensitive text. The 2018 BERT paper showed a pretrained representation could be adapted to many tasks with a small output layer, and ModernBERT, released in 2024, revisited the design for modern workloads. What changed is that generative LLMs became so capable, and so convenient, that we started using them for nearly everything.

flowchart LR
  A["Classic ML<br/>classifiers"] --> B["BERT-era<br/>task models"] --> C["General-purpose<br/>LLMs"] --> D["LLMs for<br/>every decision"] --> E["Decision<br/>models"]
  classDef plain fill:#ffffff,stroke:#0C1B45,color:#0C1B45
  classDef accent fill:#ffe9e0,stroke:#ff5a28,color:#0C1B45
  class A,B,C,D plain
  class E accent

fig. 1 — Classification never went away. Decision models bring it back with an interface built for orchestration.

Where the decision layer sits

The decision layer sits between enterprise state and execution. Take one incoming customer message in collections. Before anything gets written, the system has to make a chain of bounded calls, from whether the message is a dispute to which sub-agent owns it and whether a person must step in. Only one of those steps needs the reasoning model.

flowchart TD
  A[Customer message arrives] --> B{Is it a dispute?}
  B -->|No| C[Standard collections workflow]
  B -->|Yes| D{Which kind?}
  D -->|Pricing| E[Dispute workflow]
  D -->|Quantity| E
  D -->|Service| E
  E --> F[Pick sub-agent and tools] --> G{Deeper reasoning?}
  G -->|No| H[Continue]
  G -->|Yes| I[Reasoning model]
  H --> J{Human needed?}
  I --> J
  J -->|Yes| K[Human review]
  J -->|No| L[Execute]
  classDef plain fill:#ffffff,stroke:#0C1B45,color:#0C1B45
  classDef decision fill:#E8F4FB,stroke:#4B9AEF,color:#0C1B45
  classDef accent fill:#ffe9e0,stroke:#ff5a28,color:#0C1B45
  class A,C,E,F,H,K,L plain
  class B,D,G,J decision
  class I accent

fig. 2 — A dispute path. A decision model can answer every diamond. Only the highlighted step calls the reasoning model.

The naive pattern gives a large reasoning model a description of every available agent and asks it to choose. But routing is itself a bounded decision.

flowchart LR
  A[Customer event] --> D[Decision layer]
  D --> C[Collections]
  D --> DI[Disputes]
  D --> CA[Cash application]
  D --> CR[Credit risk]
  D --> AM[Account management]
  D --> H[Human review]
  classDef plain fill:#ffffff,stroke:#0C1B45,color:#0C1B45
  classDef decision fill:#E8F4FB,stroke:#4B9AEF,color:#0C1B45
  classDef accent fill:#ffe9e0,stroke:#ff5a28,color:#0C1B45
  class A plain
  class D accent
  class C,DI,CA,CR,AM,H decision

fig. 3 — A decision layer routes a customer event to the agent that should own it, or to a person.

The decision layer does not need to solve the customer's dispute. It only needs to reliably decide who should. Each agent still does its own work. Tool selection works the same way. Choosing between get_open_invoices, get_disputes, draft_email and request_approval is a bounded call that can sit apart from the reasoning about why the agent wants the data.

AWS's own Strands example shows the pattern. Before a tool call runs, Strands Decider answers two yes/no questions about it. One, are the arguments grounded in what the user said? And two, is it too early to call the tool? The harness turns the answers into Proceed, Deny, Confirm, or Guide. AWS calls it an illustration with hand-picked thresholds, but the lesson holds. A decision this cheap can run in places where an LLM call would be too slow or costly.

Four ways to make a decision

An enterprise harness does not have to wrap one model. It can choose between four mechanisms for every decision, and move work between them.

Rules and code

For decisions with no ambiguity, such as a balance above $50,000 requiring approval.

Decision models

For bounded judgment where the answer is not deterministic, such as which sub-agent owns a case.

Reasoning models

For open-ended problems, such as a resolution strategy.

Humans

Where risk, ambiguity or accountability demands it.

flowchart TD
  A[Event or state] --> O[Orchestration]
  O --> R[Rules and code]
  O --> D[Decision model]
  O --> L[Reasoning model]
  O --> H[Human]
  R --> X[Next action]
  D --> X
  L --> X
  H --> X
  classDef plain fill:#ffffff,stroke:#0C1B45,color:#0C1B45
  classDef decision fill:#E8F4FB,stroke:#4B9AEF,color:#0C1B45
  classDef accent fill:#ffe9e0,stroke:#ff5a28,color:#0C1B45
  class A,X plain
  class O accent
  class R,D,L,H decision

fig. 4 — One orchestration layer, four ways to reach the next action.

Confidence is the feature

Jev returns probabilities, and application code can act on them. Here is a clear answer next to an unclear one.

A clear answer

quantity_dispute 0.96, pricing_dispute 0.02, service_dispute 0.01, unknown 0.01.

An unclear one

quantity_dispute 0.39, pricing_dispute 0.31, service_dispute 0.20, unknown 0.10.

Clear answers continue automatically. Ambiguous ones go to a reasoning model. High-risk ones go to a person. The thresholds cannot be assumed from a score. They have to be calibrated and tested against the real domain. Once that work is done, uncertainty becomes something the harness can reason about explicitly.

flowchart LR
  D[Decision] --> C{Confidence / risk}
  C -->|Clear| A[Continue automatically]
  C -->|Ambiguous| R[Reasoning model]
  C -->|High risk| H[Human review]
  classDef plain fill:#ffffff,stroke:#0C1B45,color:#0C1B45
  classDef decision fill:#E8F4FB,stroke:#4B9AEF,color:#0C1B45
  classDef accent fill:#ffe9e0,stroke:#ff5a28,color:#0C1B45
  class D plain
  class C decision
  class A,R,H accent

fig. 5 — Confidence and risk decide where work goes next.

A real use case: the broken promise

Take the promise to pay. A customer tells a collector, or replies to an agent, that an invoice will be paid on Friday. Chasing pauses. On Friday, the money either arrives or it does not.

A broken promise costs twice. The cash is late, and so are the days spent not chasing. The decision that matters is made when the promise is given. Will this one be kept?

That is a bounded question with two or three answers. The state is what the system already holds, meaning the customer's promise history, their payment behavior, the invoice, how the promise was made, and how far off the due date is. The output is a probability, and the decision layer decides what it means.

flowchart LR
  A[Promise to pay logged] --> B{Will it be kept?}
  B -->|Likely kept| C[Pause chasing]
  B -->|Uncertain| D[Reminder before due date] --> F[LLM drafts the message]
  B -->|Likely broken| E[Collector contacts early]
  classDef plain fill:#ffffff,stroke:#0C1B45,color:#0C1B45
  classDef accent fill:#ffe9e0,stroke:#ff5a28,color:#0C1B45
  classDef decision fill:#E8F4FB,stroke:#4B9AEF,color:#0C1B45
  class A,C plain
  class B decision
  class D,E,F accent

fig. 6 — A promise reliability decision. The decision model returns the probability. The thresholds, and what each treatment means, stay with the business.

A promise likely to be kept needs no chasing. An uncertain one gets a reminder ahead of the due date. One likely to be broken goes to a collector early. The thresholds belong to the business, calibrated and set as policy, not left to the model. The LLM writes the reminder in the right tone for that customer. In other words, what it is good at.

It is also a problem that labels itself. The due date passes and the payment either landed or it did not, so every promise your system has recorded already carries its outcome.

The hype is hosted. The opportunity is open weights.

TypeSafe offers Jev as a hosted API, and I could not find published weights. That is fine for a pilot. It is a different conversation for a promise model, which runs on payment behavior and account history for every debtor you have.

Open-weight decision models change the conversation. Run one inside your own perimeter, and you get sovereignty in the sense that matters for an agent: control of the data, because customer text never leaves; control of the model and its IP, because you hold the weights and any fine-tune; and control of the AI economics, because owning inference removes exposure to a third party's per-token pricing.

The open field is no longer a hobby project. AWS says Strands Decider 2B decides in a median of about 115 milliseconds on a local RTX 3090 and about 153 milliseconds on an M3 MacBook for small tasks. Laya's authors report 33 to 40 milliseconds per question on a T4 GPU, for 421 million parameters. Cloudflare reports median latencies of 209 milliseconds for Clef and 39 for Clef-flash against 524 for Jev, in its own tests. These are vendor figures on different hardware and tasks, so treat them as indicative.

Fine-tuning is where it gets interesting

Open does not mean better out of the box. An independent write-up found Laya scoring below the 0.461 you get by always guessing the majority class on TypeSafe's typed-decisions benchmark, until it was fine-tuned.

Typed-decisions, zero-shot

Laya 0.362. Jev 0.727.

Typed-decisions, fine-tuned

Laya 0.766 after fine-tuning on the benchmark's own training split. Jev 0.727.

Banking77, 77 intents

Laya 0.425. Jev 0.870.

Laya's own guidance says it is a fast base to specialize, not a zero-shot decision engine.

Cloudflare reached the same point from the other side. Its own benchmark run shows zero-shot Laya far behind, with a Banking77 macro-F1 of 14.29 against 79.74 for Jev (a different metric from the figures above, so they do not line up). In its Clef launch, Cloudflare says fine-tuning can trade some general-purpose performance for higher accuracy in a specific domain, and it is building support triage, Trust & Safety, and bot classification on years of its own labeled decisions. It launched a reinforcement-learning fine-tuning service alongside the models, hands-on first and self-serve later.

Read that as the opportunity. A general decision model has never seen your debtors. Whether this customer keeps promises is a fact about your portfolio, and the only place to learn it is your own history. A small open model fine-tuned on your own promise outcomes buys accuracy where it counts, and a promise question has two or three answers, which avoids the many-option weakness above. A model trained on payment behavior and promise history is intelligence a company builds from its own data, and a competitor cannot buy it from an API.

The limits are real. Fine-tuning needs clean labeled outcomes, calibration work, and held-out data before any threshold is trusted. Wide option sets are still hard for the smaller open models.

Decision models do not replace LLMs

A decision model cannot write a nuanced customer response if its interface only lets it choose from predefined answers. It cannot construct a recovery strategy or summarize an arbitrary document. Because of that limit, the architecture becomes compositional. A smaller model decides where the work goes, a larger one solves the hard part, and deterministic checks decide whether the action is permitted.

flowchart LR
  A["Decision model<br/>routes the work"] --> B["Reasoning agent<br/>solves hard parts"] --> C{"Policy check<br/>permitted?"}
  C -->|Yes| D[Tool]
  C -->|No| E[Human review]
  classDef plain fill:#ffffff,stroke:#0C1B45,color:#0C1B45
  classDef decision fill:#E8F4FB,stroke:#4B9AEF,color:#0C1B45
  classDef accent fill:#ffe9e0,stroke:#ff5a28,color:#0C1B45
  class A accent
  class B,D,E plain
  class C decision

fig. 7 — A small model routes, a large one reasons, a check decides.

Classification becomes a runtime primitive

Historically, a classifier was a product feature. A support ticket went through an intent model into a queue. Inside an agent harness, decisions are everywhere, and one case can pass through many of them before it reaches a business outcome.

flowchart TD
  A[Input] --> B[Route to an agent]
  B --> C[Choose context, model and tool]
  C --> D[Check output]
  D --> E{Continue?}
  E -->|No| F[Stop]
  E -->|Yes| G{Escalate?}
  G -->|Yes| H[Human]
  G -->|No| I[Next step]
  classDef plain fill:#ffffff,stroke:#0C1B45,color:#0C1B45
  classDef decision fill:#E8F4FB,stroke:#4B9AEF,color:#0C1B45
  classDef accent fill:#ffe9e0,stroke:#ff5a28,color:#0C1B45
  class A,F,I plain
  class B,C,D,E,G decision
  class H accent

fig. 8 — The runtime asks for a decision at every step.

That makes the harness an orchestrator of intelligence. It controls what the agent can do, and increasingly how the system decides what to do next. The agent a user experiences may be deterministic workflows, classifiers, System One decision models, specialist models, frontier reasoning models, sub-agents, and humans. The user sees one system. Underneath, the harness picks the cheapest, fastest, and safest mechanism that can make the next decision.

flowchart TD
  E[Enterprise event] --> H[Agent harness]
  subgraph ORCH[Decision orchestration]
    direction LR
    R[Rules]
    D[Decision model]
    L[Reasoning model]
    SA[Sub-agents]
    HM[Human]
  end
  H --> ORCH
  ORCH --> P[Policy and authorization]
  P --> T[Tools and workflows]
  T --> S[State]
  classDef plain fill:#ffffff,stroke:#0C1B45,color:#0C1B45
  classDef decision fill:#E8F4FB,stroke:#4B9AEF,color:#0C1B45
  classDef accent fill:#ffe9e0,stroke:#ff5a28,color:#0C1B45
  class E,P,T,S plain
  class H decision
  class D accent
  class R,L,SA,HM decision
  style ORCH fill:#fff3ee,stroke:#ff5a28,stroke-dasharray:4 3

fig. 9 — Decision orchestration sits inside the harness, ahead of policy and execution.

Not every decision needs an LLM.

Some need a rule. Some need a classifier. Some need a fast decision model. Some need deep reasoning. Some need a person. The job of the decision layer is to know the difference.