Jev has been coming up quite a bit lately. The part that made me stop and read was that it doesn't generate text. After spending so much time around models that write code and explain their reasoning, a model built around returning a decision felt worth a closer look.

TypeSafe introduced it on September 15 as its first public System One model. The launch post talks about fast decisions that software can use directly. I was curious about the practical side: where would I actually put one of those calls in an agent?

That became dsh-jev-plugin, a small plugin that lets a DeepSeek Harness agent call Jev.

What does it decide?

Think of a support message. Before writing a reply, you might want to know which team should handle it, whether it sounds urgent, or where it falls on a severity scale. Those questions have a small, defined answer space.

Jev takes the relevant information as state, along with a set of typed questions. The three primitives used by this plugin are:

  • noul: the probability that a statement is true, from 0 to 1.
  • choice: a selection from named options, with a probability distribution and confidence.
  • score: a score against ordered levels, also with a distribution and confidence.

The TypeSafe documentation gives the full model of these requests. What appeals to me is how directly the answers fit into code: select a branch, rank a few candidates, or leave an ambiguous case for review.

I wouldn't read “type-safe” as “always right.” An answer can have exactly the expected structure and still be a poor judgment. That distinction matters once the result starts changing what an agent does.

Giving DSH another useful tool

DeepSeek Harness has a plugin architecture, which gave me a convenient place to start. I packaged the integration separately and used dsh.bundle to add a tool-jev entry to a profile.

The agent's existing language model continues to handle the conversation and its work. It gets two additional tools: jev_decide for one question, and jev_evaluate for several questions or more detailed criteria.

The call path is fairly short:

text
DSH agent
  -> jev_decide / jev_evaluate
  -> shared Jev service
  -> TypeSafe /v1/systemone
  -> structured result returned to DSH

Inside the plugin, ctx.tools.register(...) registers the tools against a shared Jev service. That service handles the request path, including configuration, cancellation, timeouts, and retries. Keeping those details together means the two tools don't grow separate versions of the same HTTP code.

Start with one clear question

Here is an example of the arguments an agent could pass to jev_decide:

json
{
  "state": "The customer says their payment failed twice.",
  "question": "Which team should handle this request?",
  "kind": "choice",
  "options": ["billing", "technical", "sales"]
}

state supplies the material to judge. question says what to judge, and options bounds the answer. The plugin turns this into Jev's native questions map, puts the question under decision, and sends it to https://api.typesafe.ai/v1/systemone.

The result comes back to DSH with model, answer, and usage. I keep the complete JSON and add a short readable summary. The Web client can also display a result card with the selected label, probabilities, or score, so inspecting a decision doesn't require digging through a large tool response.

When the same input needs several judgments, jev_evaluate accepts the native question map. For example, a support message can be checked for department and urgency in one request. I would still phrase them as separate, specific questions.

There is another small but useful piece: the bundled jev-decisions skill. Registering a tool makes it available; the skill gives the agent guidance on when to reach for it and how to read the result. Otherwise, it is quite easy to install a decision tool and continue doing every classification in the main model.

The profile is easy to overlook

For a local source installation, the plugin directory first needs npm ci --legacy-peer-deps. With DSH already installed, I use a separate Web profile and provide TYPESAFE_API_KEY to the process that starts it:

sh
export TYPESAFE_API_KEY="your-typesafe-api-key"
dsh --profile jev-dev --from-default-profile web --dump-config
dsh plugin --profile jev-dev add /absolute/path/to/dsh-jev-plugin
dsh --profile jev-dev

The path in that example needs to be replaced with the actual checkout. In PowerShell, the environment-variable line becomes $env:TYPESAFE_API_KEY = "your-typesafe-api-key".

The Web-profile initialization is for a fresh profile name. Adding a plugin directly to a new name creates a basic profile; it doesn't also turn on the Web application. An existing Web profile can skip that initialization. This is an easy detail to miss when all you want is to see the first result card.

The plugin defaults to jev-latest. /jev-status reports its configuration and activity, which helps distinguish a missing key from an integration that has loaded but hasn't been called. The project README carries the installation details as DSH evolves.

A check before a tool runs

Once the explicit tools were in place, I also added an optional check at DSH's tools/pre-execute hook. It sends the selected tool's name and arguments to Jev for a risk score, then uses configured bands to allow the call, ask for approval, or deny it.

That hook is off by default. Enabling it adds a remote evaluation to tool execution, and its default error behavior is to allow the call. Both choices need to be understood before using it in a workflow. A model score also needs testing against ordinary development commands, where unnecessary interruptions are very noticeable.

There is a separate, optional offline rule layer for known command patterns. It runs before the semantic check, so a call already refused by a rule doesn't spend a Jev request reaching the same outcome. I still treat these as aids for a workflow; permissions and isolation have their own jobs to do.

What I want to try next

The question I keep coming back to is which small judgments are worth pulling out of the main agent loop. Classification and candidate scoring seem like reasonable starting points. Arithmetic can stay in code, and a complicated investigation still needs the agent to gather evidence and reason through it.

I also want to keep the input focused. The state is sent to TypeSafe and recorded in the DSH session, so passing the entire conversation by habit would be a poor default. Usually the decision should be explainable from a much smaller piece of context.

For now, the useful experiment is simple: give DSH a well-scoped question, inspect the answer distribution, and see whether it helps with the next action. My next step is to collect a small set of everyday cases and look at the awkward ones, especially where the result changes or the model is uncertain.

The implementation discussed here is the September 22 source snapshot.