For the past few years, we have been putting LLMs almost everywhere.
They generate content, classify requests, choose tools, route workflows, evaluate results, decide what should happen next and, increasingly, control parts of our applications.
I understand why. Once you already have a model capable of reasoning over unstructured information, asking it to take on one more responsibility feels much easier than introducing another component into the architecture.
But I think we may be mixing together several fundamentally different responsibilities.
Generating something, making a judgment, enforcing a policy, and executing an action are not the same problem.
Yet many AI architectures increasingly ask one generative model to do all four.
The recent release of Jev by TypeSafe AI made me think about this distinction again. Not because I believe every system suddenly needs Jev, but because the idea behind it raises a much more interesting architectural question:
Should decision-making become a separate primitive in AI software architecture?
We are using generation to make decisions
Consider a fairly ordinary support workflow.
A customer sends this message:
"I was charged twice and I need someone to fix this immediately."
We could send that message to an LLM and ask it to determine the category, urgency, responsible department, and next action.
The response might look something like this:
{
"category": "billing",
"priority": "high",
"department": "finance",
"action": "escalate"
}
We validate the schema, parse the result, and continue the workflow.
There is nothing inherently wrong with this architecture. I have built similar flows myself, and in many cases they work perfectly well.
But look carefully at what actually happened.
We used a generative model to solve a decision problem.
The model generated tokens representing a decision, and our software then converted those tokens back into something deterministic enough to execute.
Conceptually, we built this:
State
↓
Generative Model
↓
Generated representation of a decision
↓
Parsing / Validation
↓
Application Logic
↓
Side Effect
That raises a simple question:
Was generation really the abstraction we needed?
Jev takes a different approach
Jev was released by TypeSafe AI in September 2026 and is described by its creators as a System One model.
Instead of asking the model to generate an arbitrary response, the application provides a state and asks explicitly defined questions about that state.
Those questions can represent constrained decisions such as choosing between alternatives, assigning a score, or evaluating whether something is likely to be true.
The architecture starts looking more like this:
State
↓
Decision Model
↓
Choice / Score / Probability
↓
Application Logic
At the API level, that difference may not look revolutionary.
Architecturally, I think it is much more interesting.
The model is no longer pretending to be the application.
It provides a judgment.
The application still decides what that judgment means.
And that distinction leads to a principle I think will become increasingly important as AI systems mature:
Intelligence does not have to imply authority.
Intelligence and authority are different concerns
Consider a fraud-detection system.
A model might conclude:
Probability of suspicious transaction: 0.87
That is useful information.
But should the model itself decide what happens to the transaction?
Not necessarily.
The application could define the policy:
probability < 0.40
→ continue
0.40–0.80
→ additional verification
probability > 0.80
→ human review
Now the responsibilities are much clearer.
The model evaluates uncertainty.
The policy defines authority.
The application executes the rule.
This separation becomes even more important when AI systems can trigger real-world side effects.
An AI agent may be able to choose another agent, call an API, prioritize an incident, select a workflow, flag a financial transaction, approve a step, or initiate some external action.
Those are not merely generation tasks.
They are decision boundaries.
And decision boundaries deserve architectural attention.
Maybe there is a missing layer
Software architecture has spent decades separating responsibilities because boundaries give us control over change.
Presentation is not business logic.
Business logic is not persistence.
Authentication is not authorization.
Infrastructure is not domain logic.
Then AI arrived, and somehow we became surprisingly comfortable putting several unrelated responsibilities behind a single model call.
Perhaps AI architecture needs a similar separation.
Something like:
Generation Layer
↓
Decision Layer
↓
Policy / Guardrail Layer
↓
Deterministic Application Logic
↓
Side Effects
These do not necessarily need to be separate microservices.
They do not even need to use separate models.
I am talking about responsibility boundaries, not deployment boundaries.
The Generation Layer handles open-ended creation: text, code, summaries, explanations, plans.
The Decision Layer handles fuzzy judgments where deterministic rules are insufficient.
The Policy Layer decides what the system is allowed to do with those judgments.
Application Logic enforces known deterministic rules.
And the Side-Effect boundary is where something actually changes outside the system.
Once we make these responsibilities explicit, architecture becomes easier to reason about.
Confidence can become part of control flow
One part of decision-oriented models that I find particularly interesting is the possibility of treating uncertainty as part of the application contract.
Traditional software likes binary answers:
approved = true
Reality is rarely that cooperative.
Many decisions contain uncertainty, and AI models do not magically remove it. They usually hide it behind a confident-looking response.
Instead of pretending uncertainty does not exist, we can make it part of the architecture:
High confidence
→ automate
Medium confidence
→ verify
Low confidence
→ escalate
This leads to something I find much more useful than the vague promise of "AI-powered automation":
bounded automation.
We automate only inside an envelope of uncertainty that we deliberately accept.
Outside that envelope, the system changes behavior.
That could mean additional verification, another model, deterministic validation, or human review.
The important part is that the boundary is ours, not the model's.
But probabilities do not magically create reliable systems
This is also where we need to be careful with the excitement around decision models.
Returning a probability does not make an architecture trustworthy.
It simply exposes another piece of information.
Someone still has to answer difficult questions:
- How well calibrated are these probabilities for our domain?
- What happens when the input distribution changes?
- Who defines the confidence thresholds?
- How do we measure false positives and false negatives?
- How do we audit historical decisions?
- When should humans override the model?
- How do we detect degradation over time?
- What happens when business policy changes but model behavior does not?
And there is an even more important question:
Which decisions should never become probabilistic in the first place?
I would be extremely uncomfortable seeing something like this:
Authorization allowed: 93% confidence
Some responsibilities belong in deterministic code precisely because uncertainty is unacceptable.
Security boundaries, authorization rules, financial invariants, contractual constraints, and critical business rules are obvious examples.
AI can provide information that contributes to those decisions.
That does not mean AI should own those decisions.
The architecture will probably be hybrid
This is why I do not think the lesson from Jev is "replace LLMs with decision models."
That would simply replace one oversimplification with another.
The more interesting architecture is hybrid:
LLM
creates / explains / synthesizes
↓
Decision Model
classifies / scores / evaluates
↓
Policy
defines authority and thresholds
↓
Deterministic Code
enforces rules and invariants
↓
Human
handles ambiguity and exceptional risk
Different kinds of intelligence belong in different places.
An LLM may be excellent at understanding a complex customer request.
A decision model may be better suited to classify or score that state.
A policy engine may determine whether the resulting confidence is sufficient for automation.
Deterministic code can enforce invariants.
And a human can remain responsible when uncertainty or impact crosses a defined boundary.
This architecture is less magical than "give an agent some tools and let it figure everything out."
That is probably a good thing.
What about Jev itself?
Jev is still extremely new.
TypeSafe AI reports significant improvements in latency and cost compared with frontier generative models for the kinds of decision workloads Jev targets. Those numbers are currently vendor claims, and I would want to see broader independent benchmarking before using them as the basis for an architectural decision.
There are also questions that will only become clearer with real production usage: calibration, observability, model drift, failure modes, integration complexity, and whether introducing another specialized model creates more architectural value than operational cost.
So I would not redesign a production system simply because a new model appeared.
Architecture driven by product announcements tends to age badly.
But I would pay attention to the idea behind it.
Because even if Jev disappears, gets absorbed into another platform, or inspires a completely different generation of models, the architectural question remains.
The bigger question is not about Jev
For the last few years, we have been asking:
How can we put AI into our software?
I think the more mature question is becoming:
Which responsibility should AI actually have inside our software?
Generation?
Judgment?
Policy?
Execution?
These are fundamentally different responsibilities.
And perhaps one of the next important steps in AI architecture is not making our software more intelligent.
It is becoming much more deliberate about where intelligence belongs, how much authority it receives, and where deterministic boundaries must remain.
Good architecture has never been about using the most powerful component everywhere.
It is about giving each component exactly as much responsibility as it should have.
References
Jev is a recently released technology. Performance and cost claims referenced in discussions around the product originate from its creators and should be independently evaluated before being used for production architecture decisions.
Top comments (0)