When building an application that uses AI, the most common choice today is almost always an LLM.
Application sends a prompt:
Context + Instruction
↓
LLM
↓
Generated response
We use GPT, Claude, Gemini, or other models to chat, summarize, generate content, write code, analyze documents, and so on.
But there is a rather interesting question:
What if the application does not need AI to generate text?
For example, the application only needs AI to answer:
- What category does this ticket belong to?
- Which team should this request be routed to?
- Is this document related to the case?
- Is this transaction suspicious?
- Which branch should the workflow follow?
- Does this user belong to group A or B?
In these cases, the application does not really need a long answer.
It only needs:
Input
↓
Decision
This is where the concept of an AI Decision Model becomes interesting.
One notable example is Jev. And if you are looking for an open-source/self-hostable approach for this type of workload, Laya is a project worth exploring.
1. What is Jev?
Jev is an AI decision model from TypeSafe AI.
The fundamental difference between Jev and a typical LLM is the intended use case.
LLMs are designed to process and generate language.
For example:
User:
I cannot login to my account.
LLM:
It looks like you're having trouble accessing
your account. Please try resetting your password...
Meanwhile, a decision model focuses on a different question:
User message
↓
Which category?
↓
ACCOUNT
Instead of asking the model to generate a free-form answer, the application defines a decision space in advance.
For example:
BILLING
TECHNICAL
ACCOUNT
SALES
Then the model selects one result from these options.
The result could contain a decision and probability, for example:
{
"decision": "ACCOUNT",
"probability": 0.94
}
This is quite an interesting abstraction for a software system:
AI does not always need to talk to the user. Sometimes AI only needs to provide a decision to the application.
2. Why not use an LLM for this?
This is a completely reasonable question.
We can tell an LLM:
Classify this support ticket.
Possible categories:
- BILLING
- TECHNICAL
- ACCOUNT
- SALES
Return JSON only.
Then receive:
{
"category": "ACCOUNT"
}
So why do we need a separate decision model?
Not because LLMs cannot do it.
LLMs are very good at this.
The issue is the fit between the model and the workload.
When using an LLM, the flow is still:
Prompt
↓
Understand context
↓
Reason
↓
Generate tokens
↓
Produce JSON
↓
Parse response
While the application only needs:
Input
↓
Classification
↓
Result
If your workload is primarily classification, routing, scoring, or yes/no decisions, a model designed for decision tasks can be a reasonable approach.
This is not about:
Decision Model is better than LLM.
It is about:
Choose the type of model that fits the type of workload.
3. What is Laya?
Laya follows a similar AI Decision Model approach.
What makes Laya interesting is its open-source/open-weight and self-hostable approach.
Instead of the application being completely dependent on an external decision API, developers can deploy the model within their own infrastructure.
From an architecture perspective:
Hosted approach
Application
│
▼
External AI API
│
▼
Decision
Self-hosted approach
Application
│
▼
Laya Server
│
▼
Decision Model
│
▼
Decision
This provides another option for teams that want more control over:
- Data
- Network
- Deployment
- Infrastructure
- Cost
- Model lifecycle
Especially for enterprise applications, being able to run a model within internal infrastructure can sometimes be very important.
4. How can Laya replace Jev?
This is probably the most important part.
If Jev represents the approach:
AI as a Decision API
then Laya can be considered another option for the same class of workloads.
For example, the application needs to classify a ticket:
Incoming Ticket
│
▼
Decision Model
│
├── BILLING
├── ACCOUNT
├── TECHNICAL
└── SALES
If using Jev, the decision is made through the Jev service.
If using Laya, the developer can deploy the decision model within their own infrastructure.
However, "replace" here should not be understood as:
Laya is a drop-in replacement for Jev in every case.
The two systems may differ in:
- Model
- API
- Performance
- Capability
- Deployment
- Ecosystem
The main point is:
If your workload is suitable for an AI Decision Model, Laya can be an option to consider alongside Jev.
Especially if your requirements include:
Decision Model
+
Self-hosting
+
Open-source/open-weight
then Laya becomes more interesting.
5. How is Laya different from an LLM?
It can be viewed simply as follows:
AI Models
│
┌─────────┴─────────┐
│ │
▼ ▼
LLM Decision Model
│ │
▼ ▼
Generate content Make decision
LLMs are suitable for:
"Write an email."
"Summarize this document."
"Explain this code."
"Generate a report."
"Answer this question."
Decision Models are more suitable for:
"Which category?"
"Which route?"
"Yes or No?"
"Which option?"
"What score?"
An important point is that a Decision Model does not necessarily have to replace an LLM.
They can be used together.
6. Combining Laya and an LLM
This is where the architecture becomes interesting in production.
For example, imagine building a Customer Support system.
The user sends:
"I was charged twice for the same transaction."
The first step could use Laya:
User Message
↓
Laya
↓
BILLING
Then the application routes the request to the billing flow:
BILLING
↓
LLM
↓
Generate response
Architecture:
User Message
│
▼
┌─────────┐
│ Laya │
└────┬────┘
│
▼
Classification
│
┌─────────┼─────────┐
▼ ▼ ▼
Billing Account Technical
│
▼
LLM
│
▼
Generate Response
Here, each model has a clear responsibility.
Laya:
Where should this request go?
LLM:
Now that we know which flow the request belongs to, generate the response.
This is how AI can become part of the software architecture instead of simply being a chatbot called from somewhere in the application.
7. Another use case: Workflow
Imagine a workflow for processing documents.
Upload Document
↓
Extract Information
↓
Decision
↓
┌───────────────┐
│ APPROVE │
│ REVIEW │
│ REJECT │
└───────────────┘
A decision model can act as a source of a decision signal:
{
"decision": "REVIEW",
"probability": 0.81
}
Then the business application decides what to do:
probability >= 0.90
↓
automatic flow
0.60 - 0.90
↓
human review
< 0.60
↓
fallback
The important point here is:
AI does not necessarily have to have the authority to decide the entire workflow.
AI can simply provide a signal.
The business application still controls:
- Business rules
- Authorization
- Validation
- Workflow
- Audit
- Final action
This is an approach worth considering when introducing AI into enterprise systems.
8. Problems that are suitable for Laya
Laya is particularly worth experimenting with for problems that have a relatively clear decision space.
Classification
Document
↓
INVOICE
CONTRACT
ID_DOCUMENT
OTHER
Routing
Request
↓
TEAM_A
TEAM_B
TEAM_C
Binary decision
Request
↓
YES / NO
Scoring
Input
↓
Risk Score
0.0 ───────── 1.0
Workflow decision
Application
↓
Decision
↓
Next Step
Intent detection
User message
↓
LOGIN
PAYMENT
REFUND
ACCOUNT
These are all very common operations in backend systems.
9. Self-hosting: Why does it matter?
One of the reasons developers may be interested in Laya is its self-hosting capability.
With an external AI service:
Your System
↓
Internet
↓
AI Provider
With a self-hosted model:
Your System
↓
Internal Network
↓
Laya
↓
Model
This can be suitable for systems that need tighter control over data or infrastructure.
But self-hosting is not free in terms of operations.
You will need to care about:
- CPU/GPU
- Memory
- Deployment
- Monitoring
- Scaling
- Availability
- Model updates
- Security
- Operational cost
Therefore, the question should not simply be:
"Is Laya open-source?"
Instead, it should be:
"Does self-hosting actually fit my workload and infrastructure?"
10. Laya vs Jev
If we look at them at the architecture level, we can place the two approaches side by side:
Decision AI
│
┌──────────┴──────────┐
│ │
Jev Laya
│ │
Hosted Decision Self-hostable
Service Decision Model
The differences to consider are not only model accuracy.
When evaluating a solution in practice, developers should look at:
- API compatibility
- Model capability
- Latency
- Throughput
- Accuracy on real-world data
- Hardware requirements
- Deployment complexity
- Monitoring
- Cost
- Data privacy
- Licensing
- Ecosystem
In particular, you should not benchmark using only a few simple examples.
A model may perform very well in a demo but produce different results when running on production data.
11. When should you not use Laya?
Not every application needs a Decision Model.
If the problem is:
Generate a 2,000-word report
then an LLM is more suitable.
If you need:
Have a conversation with user
then an LLM remains the natural choice.
If you need:
Analyze a large document
and explain the reasoning
then a generative model is also more suitable.
A Decision Model is most suitable when:
Input
↓
Defined decision space
↓
Structured result
If the decision space is too open-ended or the application needs generated content, you may be using the wrong abstraction.
12. A Different Way to Look at AI Architecture
What I find most interesting about Laya is not the question:
"Can Laya replace LLMs?"
But rather, it raises a different question:
Does every AI problem necessarily need an LLM?
In software engineering, we do not use the same technology for every workload.
There are many types of databases.
There are many types of message brokers.
There are many types of storage.
There are also many programming languages.
AI can follow a similar direction.
Instead of:
Everything
↓
LLM
We could have:
AI Layer
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
LLM Decision Model Embedding
│ │ │
▼ ▼ ▼
Generation Decisions Retrieval
AI then becomes a collection of capabilities rather than a single LLM.
13. Conclusion
Laya is an interesting project if you are interested in AI Decision Models and want to explore an open-source/self-hostable option alongside decision services such as Jev.
The important point is not to view Laya as a "new LLM."
It solves a different type of problem:
Input
↓
Understand
↓
Decision
↓
Application takes action
Instead of:
Input
↓
LLM
↓
Generate everything
This opens up a rather interesting way to design AI applications.
LLMs can handle generation.
Decision Models can handle decision-making.
The application still retains control over business logic and the final action.
Therefore, if you are building an AI-powered application, perhaps the first question should not be:
"Which model should I use?"
Instead:
"What does my application actually need AI to do?"
If you need to generate → use a generative model.
If you need to retrieve → use embeddings/retrieval.
If you need to make decisions → a Decision Model such as Laya can be an option worth trying.
And that is exactly what makes Laya interesting:
AI does not necessarily have to generate everything. Sometimes, AI only needs to help software make a structured decision.
Top comments (0)