A New Kind of Intelligence Needs a New Kind of Harness
Jev enables faster life sciences lab automation workflow drafts at a fraction of the model cost. Below, we share what putting Jev behind LINQ’s protocol-to-workflow assistant taught us about building for a new kind of AI.
From Automata R&D: This article describes an internal experiment, not a currently available Jev-backed LINQ feature. The workflow drafts were checked and simulated against a virtual workcell configuration; no physical instruments were run.
When AI begins shaping workflows that may run on physical instruments, the model is only part of the system. The software around it must constrain, validate and evaluate what it produces before it reaches the lab.
Most AI assistants follow one pattern. A large language model receives a long system prompt and a list of tools, and it decides in free text what to call next and with which arguments. The model carries the plan, the memory and the formatting. The software around it, the harness, mostly passes messages back and forth.
Jev, the recently launched decision model from TypeSafe, breaks that pattern. It never writes text. Every call returns a typed answer (a choice among labeled options, a score on a short rubric or a yes/no) with a calibrated probability, in a fraction of a second and for a fraction of a cent. It has no memory between calls and accepts about 32,000 tokens of input.
In an internal test, we put Jev behind LINQ’s protocol-to-workflow assistant. A scientist describes a protocol, from a one-line request to a detailed procedure, and the assistant builds a workflow draft with labware, steps, device assignments, parameters and timing. LINQ validated and saved the draft, then simulated it in the cloud using a copy of a real workcell’s instrument configuration.
In our early PCR tests, Jev produced workflow drafts 2.5-4.5× faster than Claude Opus 5.5, at roughly 1/200 of the model cost. Against the smaller Claude Haiku 5.5, it was about five times cheaper with comparable quality.
.svg)
For lab and automation leaders, the point is practical: model speed and cost only matter if the workflow it produces can be reviewed and checked against the lab setup before physical execution.
Our first attempt treated Jev like an LLM, and it did not converge. The lesson was not that Jev is weak. It is a different kind of intelligence, and it needs a different kind of harness.
1. Routing becomes classification
An LLM assistant chooses freely among more than 50 tools. Jev can only answer a well-posed question with a small set of labeled options. So we rebuilt the assistant as a state machine.
At the top level, Jev answers one question: discover what the lab offers, add something to the build, validate, finalize, reconfigure, repair an error the platform reported, or extend the workcell with a missing instrument. Each answer narrows the next question until the harness has enough information to build the next platform instruction, including which labware, action and device to use.
Options follow the state: “finalize” appears only when the build validates. Labels carry the meaning, so writing them is part of the programming. And because Jev has no memory, the state it sees must describe the build as it is now. In one replayed decision, adding the raw run history dropped Jev’s probability of finalizing a finished build from 0.54 to 0.04. Old failures read as current ones.
[FIGURE 1: the assistant as a state machine, from the top-level decision to leaf questions]
2. Numbers are not Jev’s job
Lab workflows are full of volumes, temperatures and times, and Jev cannot write any of them. The answer is to turn quantitative data into qualitative choices. The harness extracts candidate values from the request itself, converted into the right unit (“5 min” becomes 300 seconds). Jev then chooses which candidate applies to a step, or none.
If you absolutely must have Jev produce a number, there is a workaround we call the telephone dial: one 10-level Score question per digit. It works, but it turns a single parallel decision into a digit-by-digit procedure. You rebuild an autoregressive generator out of a model whose value lies in not being one, and the speed and cost advantage disappears. Arithmetic and free text belong to code, or to a small generative model such as an open-weight Qwen model running beside Jev.
In our tests, the candidate approach recovered 100% of the values a request stated and 88% of those it implied, with zero wrong values committed. The rest were left visibly unset, which is the right failure in a lab: a wrong value silently corrupts a schedule.
3. The harness owns the context window
Jev’s limit of about 32,000 tokens is a hard edge. Above it, requests are refused rather than degraded. Our LLM assistant’s guidance alone runs to about 30,000 characters, and most of it is irrelevant at any given step.
So the harness maps every piece of guidance onto the graph and swaps it in by stage. Labware rules appear only where labware is chosen, and validation rules only where errors are repaired. Finished parts of the build collapse into a single line. Testing showed that where the rules appeared mattered. Adding them to the initial question incorrectly sent a finished build back for reconfiguration, while applying them only to the relevant final questions corrected a real error. The largest request in a full build was about 4,400 tokens.
Context engineering stops being prompt writing. It becomes part of the state machine.
4. Build the harness in a loop
This is the lesson we would put first: you need a harness-evaluation benchmark.
At Automata, we use an internal protocol-construction benchmark. Realistic protocols are run end to end against a live LINQ stack and scored against the reference protocol. We have evaluated 30 model families on it, and we will publish the results in an upcoming paper.
For Jev it became a development loop:
- Run and capture every decision.
- Score the result.
- Trace each failure to a harness defect.
- Fix it generically.
- Replay the exact captured decision to read how Jev’s probabilities moved.
Because each decision costs a fraction of a cent, every fix can be tested on the exact request where it failed before it touches the lab.
With the loop and the benchmark in place, the whole harness transition took one engineer three days: the new form of the assistant was running within a day and working properly within two more. Holding the model fixed and changing only the harness raised Jev from 1 to 6.5 out of 10. The same change moved Claude Opus 5.5 from 8 to 9 and Claude Haiku 5.5 from 4 to 5.
What it delivered
On PCR, at two levels of protocol detail, the Jev assistant produced workflow drafts that passed structural validation, and were simulated in the cloud against a virtual copy of a real workcell configuration. It scored 2 points below Claude Opus 5.5 running in the same harness, out of 10. It was 2.5 to 4.5 times faster per build and about 170 to 250 times cheaper: about two cents per workflow against roughly $3.50 to $3.90. Claude Haiku 5.5 in the same harness split the two runs with Jev, scoring 2 points higher on the high-level request and 1 point lower on the detailed protocol, at about five times Jev’s cost and 1.6 times its build time.
Jev’s workflows are simpler and more literal, and the gap is real. But much of what both models lost points on traces back to the harness and the platform, and each finding becomes the next turn of the loop. These are early results, one run per configuration.
For a team planning a PCR workflow, the potential benefit is a faster, lower-cost first draft, not a workflow ready to run unattended. LINQ checked the draft’s structure and simulated it against a virtual workcell configuration; a person would still need to review and refine it before physical execution.
The point is not that one model should replace another. It is that different forms of intelligence may suit different tasks, provided the platform can constrain their actions and evaluate their outputs before they influence execution.
.svg)
What this means for teams putting AI into the lab
New kinds of intelligence will keep arriving, each with its own shape and limits. The decision structure, the state and the evaluation loop are not glue code around them. They are the product.
The teams that benefit first will be those with an execution layer that can use different forms of intelligence, evaluate their outputs and keep scientists in control of what reaches the physical lab. They will also have benchmarks that show whether a new approach actually works. That is what makes new AI capabilities deployable, rather than merely impressive in a demonstration.
Separately from the lab-workflow tests described here, we also explored how Jev responds when completing a task conflicts with an explicit constraint in an artificial puzzle. We plan to discuss that experiment in a dedicated technical post.
Related: Watch The Agentic Lab on demand for a deeper discussion of how orchestration, execution data and scientific context support increasingly intelligent laboratory operations.
