Why bounded semantic decisions may become an important layer in agentic AI architecture.

𝗝𝗲𝘃, 𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗦𝘁𝗮𝘁𝗲, and Why I Think of It as 𝗛𝗼𝗺𝗲 𝗗𝗲𝗹𝗶𝘃𝗲𝗿𝘆 vs. a 𝗖𝗹𝗮𝘂𝗱𝗲 𝗕𝘂𝗳𝗳𝗲𝘁

For the last few years, our default AI architecture has been surprisingly simple:

Have a problem? Send it to an LLM.

Need to classify something? LLM.

Need to choose a tool? LLM.

Need to decide whether an agent should retry? LLM.

Need to determine whether a document contains enough evidence? LLM.

Need to choose one option from three possibilities? Again, LLM.

General-purpose models such as Claude are extremely capable, but while experimenting with TypeSafe AI's 𝗝𝗲𝘃, I started asking a different architectural question:

Why hire a chef when all I need is someone to pick the right item from an already-defined menu?

That is where my 𝗛𝗼𝗺𝗲 𝗗𝗲𝗹𝗶𝘃𝗲𝗿𝘆 vs. 𝗕𝘂𝗳𝗳𝗲𝘁 analogy came from.

But before getting to the analogy, it is important to understand what Jev actually is.

What Is 𝗝𝗲𝘃?

Jev is TypeSafe AI's first public 𝗦𝘆𝘀𝘁𝗲𝗺 𝗢𝗻𝗲 𝗠𝗼𝗱𝗲𝗹. Unlike a general-purpose LLM whose primary interface is generated text, Jev is designed for decisions inside software.

The basic idea is remarkably simple:

𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗦𝘁𝗮𝘁𝗲 → 𝗧𝘆𝗽𝗲𝗱 𝗤𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 → 𝗣𝗿𝗼𝗯𝗮𝗯𝗶𝗹𝗶𝘀𝘁𝗶𝗰 𝗗𝗲𝗰𝗶𝘀𝗶𝗼𝗻𝘀

TypeSafe describes the model as taking program state and returning typed decisions that software can consume directly. The possible outputs are defined ahead of time instead of allowing the model to generate an arbitrary string.

That difference is important.

With Claude, I might ask:

Analyze this candidate's experience and explain whether this person would be appropriate for an enterprise AI architecture role.

The output could be several paragraphs.

With Jev, I can instead define a bounded question:

Which role best matches this state?

A. Traditional Backend Developer
B. Generative and Agentic AI Architect
C. Database Administrator
D. Manual Test Engineer

Now I am not asking the model to generate language.

I am asking it to make a decision within a vocabulary that my application already controls.

That is why, as my own mental model, I think of Jev as:

“𝗝𝘂𝘀𝘁 𝗘𝗻𝗿𝗶𝗰𝗵𝗲𝗱 𝗩𝗼𝗰𝗮𝗯𝘂𝗹𝗮𝗿𝘆” — not the official expansion of Jev, but a useful way for me to remember what the architecture is doing.

The vocabulary belongs to my application.

Jev adds semantic judgment around it.

𝗝𝗲𝘃 Starts With the 𝗦𝘁𝗮𝘁𝗲 of the Application

This is the part I find most interesting.

Instead of beginning with a chat prompt such as:

“You are an expert AI architect. Analyze the following information…”

I start by defining the 𝗦𝘁𝗮𝘁𝗲 that exists right now.

For example:

{
  "name": "Sreeni Ramadurai",
  "myboss": "Krishna K",
  "skills": "GenAI, AgenticAI, AWS, Azure"
}

This is not really a prompt in the traditional chatbot sense.

It is a snapshot of what the application currently knows.

The state might contain a customer message, an account status, a transaction, retrieved documents, an agent trace, tool results, user permissions, workflow history, or any other information required to make the next decision.

TypeSafe's own description emphasizes this distinction: Jev inputs are oriented around structured program state, while conventional LLM interfaces tend to be organized around sequential conversational messages.

That gives me a useful mental model:

State is not what I want the model to say. State is what the system currently knows.

Then I separately define what I want the system to decide.

𝗦𝘁𝗮𝘁𝗲 First, 𝗤𝘂𝗲𝘀𝘁𝗶𝗼𝗻𝘀 Second

Using the small state above, I experimented with questions such as:

Is there sufficient evidence of architecture readiness?

Which enterprise AI role best matches the available evidence?

How strong is the evidence?

Does this state support a production deployment claim?

Does this state establish that Krishna K is Sreeni's manager?

Which conclusion would require information that is not present?

Notice the architecture.

I am not putting everything into one large prompt and asking:

“Think about all of this and tell me what you think.”

Instead, the application provides one state and several independent decision questions.

That is very close to normal software engineering.

We define the data.

We define the contract.

We define the permitted outputs.

Then intelligence evaluates the state against those contracts.

Three Kinds of Decisions

In the current Jev interface, these bounded judgments are expressed through typed question forms such as 𝗡𝗼𝘂𝗹, 𝗖𝗵𝗼𝗶𝗰𝗲, and 𝗦𝗰𝗼𝗿𝗲. TypeSafe's public materials describe Jev broadly as returning typed decisions with probabilities and confidence values rather than open-ended generated text.

For example, a binary judgment might ask whether the state contains enough evidence for a particular claim.

A 𝗖𝗵𝗼𝗶𝗰𝗲 might ask:

Traditional Backend Developer
Generative and Agentic AI Architect
Database Administrator
Manual Test Engineer

A 𝗦𝗰𝗼𝗿𝗲 might ask how strongly the available evidence supports enterprise AI capability on a predefined scale.

The important point is not the names of these primitives.

The important point is that the shape of the answer exists before inference begins.

The application owns the decision boundary.

The model judges what belongs inside it.

Jev Playground with my own State

Now the Restaurant Analogy Becomes Clear

Imagine opening a food-delivery application.

The restaurant has only three dishes available:

Pizza
Burger
Biryani

Then I provide some state:

Vegetarian
Likes spicy food
Wants something filling

The menu has already been established.

Jev does not need to invent another meal.

It does not need to write a recipe.

It does not need to explain the history of biryani.

Its job is simply to evaluate the state against the known choices.

The result might look conceptually like:

Biryani    82%
Pizza      14%
Burger      4%

This is why I call Jev 𝗶𝗻𝘁𝗲𝗹𝗹𝗶𝗴𝗲𝗻𝘁 𝗵𝗼𝗺𝗲 𝗱𝗲𝗹𝗶𝘃𝗲𝗿𝘆.

The intelligence is real, because choosing correctly may require semantic understanding.

But the destination is bounded.

𝗛𝗼𝗺𝗲 𝗗𝗲𝗹𝗶𝘃𝗲𝗿𝘆 = 𝗸𝗻𝗼𝘄𝗻 𝗺𝗲𝗻𝘂 + 𝗰𝗼𝗻𝘁𝗲𝘅𝘁 + 𝗷𝘂𝗱𝗴𝗺𝗲𝗻𝘁.

𝗖𝗹𝗮𝘂𝗱𝗲 Is the 𝗕𝘂𝗳𝗳𝗲𝘁

Now imagine walking into a buffet.

I can ask:

What should I eat?

Build me a vegetarian dinner.

Compare these dishes.

Explain why one is healthier.

Suggest something I haven't considered.

Create a completely different meal.

Plan my meals for the entire week.

Now I am no longer choosing from one narrowly defined application vocabulary.

I want exploration.

I want synthesis.

I want explanation.

I may not even know the answer space before I start asking questions.

That is where a general-purpose model such as Claude becomes valuable.

So in my architecture analogy:

𝗝𝗲𝘃 is 𝗛𝗼𝗺𝗲 𝗗𝗲𝗹𝗶𝘃𝗲𝗿𝘆. 𝗖𝗹𝗮𝘂𝗱𝗲 is the 𝗕𝘂𝗳𝗳𝗲𝘁.

Home delivery does not mean unintelligent.

And buffet does not mean better.

They solve different problems.

But Before Jev, There Is Still 𝗖𝗼𝗱𝗲

There is an even simpler layer.

Suppose my application already has this business rule:

IF vegetarian
    remove all meat dishes

I do not need Jev.

And I certainly do not need Claude.

The business has already determined exactly what should happen.

Use code.

That gives me three architectural layers:

CODE
Explicit rule is already known
        ↓
JEV
Options are known,
but choosing requires semantic judgment
        ↓
CLAUDE
Answer space is open,
requiring reasoning, synthesis or generation

Or, using my restaurant analogy:

CODE
"The restaurant rule already decides."

        ↓

JEV — HOME DELIVERY
"The menu is fixed.
Choose the best item for this context."

        ↓

CLAUDE — BUFFET
"Explore, compare, combine,
explain and create."

That distinction is much more useful to me than asking which model is “smarter.”

Where Jev Gets Really Interesting: 𝗔𝗴𝗲𝗻𝘁𝗶𝗰 𝗔𝗜

Now move away from restaurants and consider an enterprise agent.

During one workflow, an agent may need to decide:

Which tool should I call?

Is this retrieved document relevant?

Did the tool actually satisfy the task?

Should I retry?

Should I continue?

Should I escalate to a human?

Is this transaction low, medium or high risk?

Does the evidence support this claim?

Many of these are semantic decisions.

They cannot always be expressed as simple if/else statements.

But they also do not necessarily need paragraphs of generated reasoning.

Their answer spaces often look like this:

Tool
Salesforce | ServiceNow | SharePoint | None

Action
Continue | Retry | Escalate

Risk
Low | Medium | High

Evidence
Supported | Partial | Unsupported

This is where I see Jev fitting naturally inside an 𝗔𝗴𝗲𝗻𝘁 𝗛𝗮𝗿𝗻𝗲𝘀𝘀.

                     AGENT HARNESS
                          │
           ┌──────────────┼──────────────┐
           │              │              │
         CODE            JEV          CLAUDE
           │              │              │
         Rules         Semantic       Reasoning
                       Judgment       Generation
           │              │              │
           └──────────────┼──────────────┘
                          │
                        TOOLS
                          │
                        ACTION

Code controls deterministic behavior.

Jev makes bounded semantic judgments.

Claude handles the parts where broader reasoning or generation is actually necessary.

That architecture interests me much more than simply routing everything through one giant model.

Is Jev's “𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻 𝗦𝘁𝗮𝘁𝗲” Related to 𝗛𝗔𝗧𝗘𝗢𝗔𝗦?

When I started thinking about Jev in terms of application state, another architecture immediately came to mind:

𝗛𝗔𝗧𝗘𝗢𝗔𝗦 — Hypermedia as the Engine of Application State.

There is definitely a conceptual connection, but they are not the same thing.

In REST, HATEOAS means the server representation provides hypermedia controls that tell the client what resources or transitions are available next. Rather than hard-coding every possible navigation path, the client can discover permitted next actions from the representation it receives. This is part of the REST architectural style described by Roy Fielding.

For example, an order might be represented as:

{
  "orderId": 1001,
  "status": "pending",
  "links": [
    {
      "rel": "cancel",
      "href": "/orders/1001/cancel"
    },
    {
      "rel": "pay",
      "href": "/orders/1001/payment"
    }
  ]
}

The current state determines which transitions are available.

That sounds somewhat similar to what we are doing with Jev—but there is an important difference.

𝗛𝗔𝗧𝗘𝗢𝗔𝗦 exposes the allowed next actions.

𝗝𝗲𝘃 can semantically judge which allowed action best fits the current context.

That leads to an architecture I find fascinating.

Imagine the application state says:

{
  "orderStatus": "pending",
  "customerMessage": "I accidentally placed this order twice.",
  "paymentCaptured": false,
  "availableActions": [
    "cancel",
    "continue",
    "escalate"
  ]
}

HATEOAS could tell the application:

These are the actions currently available.

Jev could then answer:

Given the complete state,
which available action best fits the situation?

cancel      94%
escalate     5%
continue     1%

Then deterministic code executes the selected transition subject to whatever confidence threshold, permissions, policy checks, and guardrails the application requires.

So I would summarize the relationship this way:

𝗛𝗔𝗧𝗘𝗢𝗔𝗦 tells the client what it may do next.
𝗝𝗲𝘃 can help the application judge which permitted action makes sense next.

That is not part of the formal definition of HATEOAS, nor is Jev an implementation of HATEOAS.

It is simply a useful architectural connection.

HATEOAS gives us state-driven discoverability.

Jev gives us state-driven semantic judgment.

Put together, they suggest an interesting pattern for intelligent APIs and agents.

𝗦𝘁𝗮𝘁𝗲 → 𝗣𝗼𝘀𝘀𝗶𝗯𝗶𝗹𝗶𝘁𝗶𝗲𝘀 → 𝗝𝘂𝗱𝗴𝗺𝗲𝗻𝘁 → 𝗔𝗰𝘁𝗶𝗼𝗻

This may actually be the most useful way for me to think about Jev.

Not:

Prompt → LLM → Text

But:

CURRENT STATE
      ↓
AVAILABLE DECISIONS
      ↓
SEMANTIC JUDGMENT
      ↓
PROBABILITY / CONFIDENCE
      ↓
BUSINESS RULES + GUARDRAILS
      ↓
ACTION
      ↓
NEW STATE

And then the cycle repeats.

State₀
   ↓
Decision
   ↓
Action
   ↓
State₁
   ↓
Decision
   ↓
Action
   ↓
State₂

Now Jev starts looking less like a chatbot and more like an intelligence primitive inside a stateful software system.

That is the part I find most compelling.

Why Not Just Give Claude Structured Output?

This is the obvious question.

Claude can absolutely be given:

Choose exactly one:

cancel
continue
escalate

It can return JSON.

It can use tool calling.

It can conform to a schema.

So the question is not:

Can Claude make bounded decisions?

Of course it can.

The architecture question is:

If my application needs thousands of small semantic judgments whose output spaces are already known, should every one of them go through a general-purpose text-generation architecture?

Jev was explicitly designed around this narrower machine-facing task. TypeSafe describes it as optimizing for structured, calibrated decisions rather than free-form strings.

This becomes especially interesting inside agentic systems where a single user request may cause many internal decisions.

One model call may be insignificant.

Thousands of decisions across many agents, tools, users, and workflow steps are a different architectural problem.

𝗕𝗼𝘂𝗻𝗱𝗲𝗱 Does Not Mean 𝗖𝗼𝗿𝗿𝗲𝗰𝘁

There is one distinction I think is essential.

Suppose Jev produces:

Biryani 82%

That does not make Biryani objectively correct.

Likewise:

{
  "risk": "high"
}

being perfectly valid structured output does not prove that the risk assessment itself is correct.

𝗧𝘆𝗽𝗲 𝘀𝗮𝗳𝗲𝘁𝘆 ≠ 𝗦𝗲𝗺𝗮𝗻𝘁𝗶𝗰 𝗰𝗼𝗿𝗿𝗲𝗰𝘁𝗻𝗲𝘀𝘀.

So we still need evaluations, thresholds, observability, guardrails, and human review where the consequence demands it.

The difference is that the decision surface is constrained and machine-consumable.

That can make the surrounding system easier to reason about.

How I Would Use Jev in an Enterprise Application

My pattern would be simple:

1. Build the application state
        ↓
2. Define the decisions the application actually needs
        ↓
3. Express those decisions as bounded typed questions
        ↓
4. Let Jev evaluate the state
        ↓
5. Read probabilities/confidence
        ↓
6. Apply deterministic thresholds and policies in code
        ↓
7. Execute a tool, ask Claude for deeper reasoning,
   or escalate to a human
        ↓
8. Update the application state
        ↓
9. Repeat

The model should not own the entire workflow.

𝗧𝗵𝗲 𝗵𝗮𝗿𝗻𝗲𝘀𝘀 𝗼𝘄𝗻𝘀 𝘁𝗵𝗲 𝘄𝗼𝗿𝗸𝗳𝗹𝗼𝘄.

The model contributes intelligence at specific decision points.

That separation matters.

My Mental Model After Using Jev

I now think about AI architecture using three increasingly flexible layers.

𝗖𝗢𝗗𝗘 = 𝗥𝗨𝗟𝗘𝗦

The correct behavior is already explicitly known.

If payment has already been captured, do not cancel automatically.

𝗝𝗘𝗩 = 𝗝𝗨𝗗𝗚𝗠𝗘𝗡𝗧 / 𝗛𝗢𝗠𝗘 𝗗𝗘𝗟𝗜𝗩𝗘𝗥𝗬

The options are known, but the correct choice depends on interpreting context.

Cancel, Continue, or Escalate?

𝗖𝗟𝗔𝗨𝗗𝗘 = 𝗥𝗘𝗔𝗦𝗢𝗡𝗜𝗡𝗚 + 𝗚𝗘𝗡𝗘𝗥𝗔𝗧𝗜𝗢𝗡 / 𝗕𝗨𝗙𝗙𝗘𝗧

The problem requires exploration, explanation, planning, synthesis, or creation.

Analyze the entire situation, explain the trade-offs, and propose a resolution strategy.

This is not a competition between models.

It is separation of concerns.

The Bigger Question: Are We Overusing Generation?

Software architecture has always been about choosing the appropriate abstraction.

We do not use a database where a queue belongs.

We do not use Kubernetes to execute one shell script.

And perhaps we should not use open-ended generation where all we really need is a bounded semantic decision.

That is the larger lesson I took from experimenting with Jev.

The future of AI applications may not be:

Application → One giant LLM → Everything

It may look more like:

Application State
        │
        ▼
      Harness
        │
   ┌────┼────────────┐
   │    │            │
 Code  Jev         Claude
   │    │            │
Rules Judgment    Reasoning
                  Generation
   └────┼────────────┘
        │
       Tools
        │
      Actions
        │
     New State

And once I saw it this way, my restaurant analogy finally clicked.

𝗖𝗼𝗱𝗲 already knows the restaurant rules.

𝗝𝗲𝘃 is intelligent 𝗛𝗼𝗺𝗲 𝗗𝗲𝗹𝗶𝘃𝗲𝗿𝘆 from a defined menu.

𝗖𝗹𝗮𝘂𝗱𝗲 gives me the 𝗕𝘂𝗳𝗳𝗲𝘁 when I genuinely need exploration and creation.

So before making the next expensive generative call, perhaps the architecture question should not be:

Which model is smartest?

It should be:

Does this decision need a 𝗿𝘂𝗹𝗲, intelligent 𝗵𝗼𝗺𝗲 𝗱𝗲𝗹𝗶𝘃𝗲𝗿𝘆, or the entire 𝗯𝘂𝗳𝗳𝗲𝘁?

Sometimes we need the chef.

But sometimes all we needed was someone intelligent enough to pick the right item from the menu.

Sreeni Ramadorai
AI Architect