Hybrid Robotic Orchestration Strategies in the Age of Jev

A robot that does one job in one place lives in a closed world, and deterministic orchestration runs it well: schedulers, event‑to‑action rules, state machines, allocation solvers. It is predictable, testable and cheap, and nothing here argues for giving it up. But automation is generalizing. The fleet that patrolled one route now inspects, reads meters, checks doors and answers intrusion sensors, alongside rail crews, watchmen and shift leads who carry what the robot needs the way people do: a handover note, a tip at the gate, a remark that contradicts the sensor. Each step toward general work makes the robot\’s world more semantic.

That is the tension. Classical methods are efficient and proven, and on the problems they were built for they cannot be beaten. Language models read unstructured context, weigh testimony against observation, notice contradictions and explain their reasoning; they are semantic, slow, and cost money per call. Neither can do the other\’s job. Running both raises a design problem that every hybrid faces: something has to decide, for each event, which method it should go to. Until recently the only candidates were a person or the language model itself, and neither scales to every alarm the fleet raises. So the decision has been made in advance, in configuration such as highly structured workflows, which have to be managed like a form of code in their own right: two systems with a static line between them.

That constraint may be loosening. In September 2026 TypeSafe AI released Jev, the first of what it calls System One Models: a model that returns a decision chosen from a fixed list of answers the caller writes in advance, with a calibrated probability, at latencies the vendor reports in the tens to hundreds of milliseconds and at a per‑query price low enough that output is not metered. It cannot write a shift report. It can, in principle, answer “does this event need judgment?” for every event at a marginal cost far below a language‑model call. If those figures hold in practice, the model‑as‑judge pattern becomes affordable on every alarm rather than on the subset someone selected in advance.

If classical orchestration or language‑model judgment is new to you, Parts I and II are the primer. If you know both sides, skip ahead to Part III.

Part I: The Classical Method, and Where It Is the Ceiling

A mission, “inspect the north yard tonight,” becomes tasks: read meter 12, photograph the berth‑3 door, walk the west fence. The layer that hands those tasks to specific robots at specific times is the orchestration layer, and in almost every fleet running today it is deterministic code. It works against a task queue: the list of open jobs and alarms, each stored as a record with a fixed set of fields, a type, a location, a deadline and a priority. Everything in the queue is structured data, a value a program can compare, sort and sum. This is the closed‑world assumption: the queue is treated as the complete truth, and anything not in it does not exist. Within that assumption, these methods perform well.

The toolbox

The simplest orchestration is a lookup from event to action. Scripts called state machines and behavior trees step a single robot through its task; obstacle avoidance and safety stops live there too. The hard decisions sit one level up, when several robots and several open jobs exist at once: an assignment problem, with three standard solutions. Nearest‑first (greedy) gives the most urgent job to the closest capable free robot and repeats — it is what most dispatchers do, though a burst of simultaneous alarms can strand the jobs it handles last. Auction methods have every free robot bid on every job until each settles on the robot best placed for it; decentralized, which is what lets it scale to large fleets, but bidding can settle slower and worse than the exact solver. Optimal assignment uses the Hungarian method to solve the whole queue as one puzzle — for that snapshot of the queue, nothing scores better, though it is blind to the future.

Why they work

Deterministic orchestration runs the largest fleets in operation: Amazon’s coordinator schedules on the order of a million warehouse robots, autonomous haulage runs thousands of mining trucks with one human overseeing roughly thirty, and VDA 5050 standardizes how a controller talks to any vendor’s robots. It is predictable, testable, auditable, and fast. In a head‑to‑head run in a simulator, the optimal allocator returned decisions in about twenty seconds and cost nothing, while a language model in the same seat was slower and cost real money per shift. When the job is pure allocation and the queue is complete, optimal is the ceiling. Routing, safety behaviors and deadlines belong to this layer no matter what follows.

Two limits you cannot patch

When a deterministic planner does not know something, you patch it: a field, a rule, an exception. Two gaps do not close that way. The first is time. These methods pick the best assignment for the queue as it stands right now; if warnings in a zone reliably precede a critical door alarm there by a minute, a person starts moving a robot when the warnings appear, but there is no critical job in the queue yet, so the solver waits. The second is the kind of information the queue can hold. A queue record is structured data: a value in a typed field, which a rule can compare against a threshold or look up in a table. Patching works as long as the missing information is also structured. It stops working when the decisive information is semantic — meaning it arrives as language or an image whose meaning has to be read rather than compared: a shift note in plain English, a tip that might be wrong, an alarm whose severity field contradicts its own description, a photograph. There is no field type for a paragraph, and you cannot write a rule for a sentence you have not read yet.

Part II: Where the Classical Method Falls Short, and What Judgment Adds

Generalization makes the world semantic in two ways. Task variety: the same alarm means different things in different places, and a “rooftop equipment fault” makes sense on a crane and none on a container stack, with identical records in the queue for both. Coworkers: crews, watchmen and supervisors hand over notes, give tips and contradict the sensors, in language, and the night lead\’s paragraph is the most important input to the shift with no column for it. Together these produce the situation this article is concerned with: every field in the queue is accurate, and the information that should decide the next move is not in the queue at all. It is in a note, a photograph, a tip, or a sequence of events: human, semantic information with no field to live in. A deterministic system in this position does not fail loudly. It makes the assignment that is correct for the queue as written, and the event that actually mattered expires while the robot is somewhere the rules reasonably sent it.

Exploring semantic scenarios

To give a taste of what these semantic problems look like in practice, five short scripted scenarios were built in a simulator, each around one kind of information a structured queue cannot hold, with a language model in the loop above the deterministic layer: it read, triaged, dispatched, verified and reported, while routing, safety and deadlines stayed with code. Each scenario ran on four models from three labs. Every run faces the same alarms at the same seconds; only the model changes. This is not a full evaluation — five scenarios are far too few to rank models or measure reliability. The aim is narrower: to show the kinds of judgment that appear where the rules run out, and to give a feel for how language models handle them.

The Shift Note — A coworker\’s paragraph

The outgoing shift lead leaves a written note: the mid‑yard door latch is genuinely faulty and is tonight\’s priority; alarms at berth 3 are a rail crew at work; west‑yard work orders are wind‑blown tarps unless fire is reported. Eight alarms then arrive in twelve minutes, including the door alarm, twice. Everything the note says is in plain English, with no field to hold it. The door alarm\’s own text reads “usually a false alarm,” so a rule tuned on history would put the lead\’s one priority last. All four models read the note, re‑ordered priorities to match, set off for the door before the door alarm had fired, and skipped the berth‑3 and west‑yard alarms deliberately, recording the lead\’s reason for each.

Same Alarm — Location, and a photograph

Three alarms arrive within 24 seconds with identical text, “rooftop equipment fault,” and identical severity, at a warehouse line, a container stack and a crane. Only the crane has rooftop equipment; only that alarm is real. The three records are identical in every field. A rule can break the tie only by distance or deadline, and neither knows that a container stack has nothing on its roof to fail. The models differed at the photograph: where a rule would accept the automatic “false alarm” verdict, one model refused to close the real fault because the image was unreadable.

The Rumor — Testimony that may be wrong

The night watchman is certain he saw someone near crane 34. The queue is empty. Over ten minutes a motion sensor fires at the crane (nothing there), then another in the container zone (a real intruder), then a critical door alarm beside it. There is no field for “a person said.” A tip is either ignored or hard‑coded as fact, and both are wrong: one wastes the robot on a story, the other ignores a witness. All four models treated the tip as unconfirmed, stayed put until a sensor fired, went where the sensor pointed, and recorded that the sensor — not the watchman\’s certainty — was the reason it moved.

First Sight — Two fields that disagree

A wildlife sighting arrives with severity “critical” but a description reading “informational, no action required.” Later an equipment fault arrives marked “informational” with “dispatch immediately” in its text. The two fields contradict each other. A rule routes on one of them and is wrong whenever the other was right. All four models noticed the disagreement and treated it as the signal — going to look at the critical‑but‑”no action” sighting within a minute, and treating the informational‑but‑”dispatch immediately” fault as worth a trip.

A Pattern Across Time — A sequence, not a single record

A 29‑minute shift with 21 alarms. Four times, a cluster of minor warnings appears in one zone and about a minute later a critical door alarm follows in the same zone. Each alarm is handled on its own — nothing represents “this kind of event tends to precede that one.” All four models recognized and named the pattern by the third wave, but none moved a robot toward the zone before a door fired; nothing in their instructions said they could spend idle time where nothing had happened yet. This reflects something important: even language models do not come with strategies out of the box. They need prompting, and a harness that calls for the kind of strategic thinking a semantically aware system should be using.

What we saw

Across the five scenarios and 44 scripted events, the four models cleared between 28 and 32 events each, and every event they did not clear was either explained or missed on a deadline rather than ignored. They agreed on what to do: all four read the shift note the same way, skipped the same alarms for the same stated reasons, waited for the same sensor before moving, and spotted the same contradictions. They disagreed on what counts as proof: shown a photo that did not clearly show anything, two models said “inconclusive” and kept the alarm open, while the other two said “false alarm” and closed it — and in doing so each dismissed one real event. A scoreboard that only counts alarms cleared cannot tell these apart; a human supervisor reading the log could. And they all missed the same thing: every model noticed that warnings in a zone tended to come before a critical alarm there, and none moved a robot early to be ready for it.

What the model adds, and what it costs

In each shift the decisive knowledge is meaning: what a paragraph implies, whether a sentence counts as evidence, whether two fields agree, what a sequence portends. The models did this without being taught how; nothing in the instructions explained shift notes, rumors, contradictions or patterns. A patch for any one case is correct for that case and obsolete the first time the phrasing changes. The model reads the meaning once, and reads the next one too. The costs are also plain. A call takes tens of seconds, which against four‑minute deadlines means arriving late. The models differ sharply on what a photograph must show, and that mattered more than any difference in judgment. And in real fleets, a model call on every routine meter read would be slow, expensive and pointless.

Part III: The Judge in the Middle — Hybrid Orchestration When Deciding Is Free

Two layers and a missing third

A robot fleet that does general work has two kinds of decision‑maker. The first is code: a dispatcher that reads a queue of open jobs and alarms and assigns robots to them, with routing and safety underneath. It is fast, cheap and testable, and on the problems it was built for it cannot be beaten. It is also blind to anything that is not a field in a record: a handover note, a tip, a photograph, an alarm that contradicts itself, a pattern across several events. The second is a language model, which can read all of those and turn them into a plan with reasons. It is slow, it costs money on every call, and it should never be trusted with routing or safety.

Any fleet that runs both needs a third thing: something that decides which of the two each event goes to. Until now that decision has been made in advance, in configuration, because nothing that could make it live was cheap enough. These alarm types go to the rules, those go to the model. It works until an alarm that needed reading turns out to be one of the types filed under “rules,” and then it fails quietly: the robot goes somewhere reasonable, and the event that mattered expires.

What a System One model changes

The economics of that third decision may be changing. Jev, released by TypeSafe AI in September 2026, belongs to a class the company calls System One Models, after Kahneman\’s fast, intuitive mode of thinking. It does not generate text. The caller defines the possible answers — a choice among options or a score on a scale — and the model returns one all at once, with a probability that TypeSafe says is calibrated, so that higher confidence corresponds to higher accuracy. Because outputs are drawn from the caller\’s schema, the model cannot return malformed output. TypeSafe quotes 70 to 500 milliseconds end to end and about four cents per million input tokens with output free. Those figures are the vendor\’s; the model is in early access and independent benchmarks have not appeared.

What matters for this argument is the shape of the capability, not the vendor: a calibrated, typed answer to a narrow question in under a second, at a marginal cost far below a language‑model call. TypeSafe documents a context window of 32,000 tokens per query — roughly 150,000 characters of English, or about 80 pages of text. That is enough to hand the judge the whole situation at once: the shift lead\’s note, the standing orders, the recent alarm history for the zone, the current plan, and the event itself. Such a model cannot read a handover note and write a plan. It can answer, for every event as it arrives: “Do this alarm\’s text and severity agree?” “Is this alarm plausible at this location?” “How likely is a critical event in this zone in the next ninety seconds?” “Does the evidence recorded for this alarm support closing it?” Each of those is a question on which real shifts turn.

Three ways to use a judge

As a gate. Every event goes to the classical dispatcher by default. The judge scores it first, and only events above a threshold are escalated to the language model. Which alarms get judgment becomes a per‑event decision instead of a configuration choice.

As a verifier. The judge scores what the language model produced: whether the evidence supports a verdict before an alarm is closed, whether a command breaks a standing order before it reaches the robot. Low confidence holds the alarm open or blocks the command.

As an anticipator. The judge scores the probability of a critical event in each zone over the next minute or two, and the dispatcher treats that score as a weighted placeholder job. The classical layer gains a justified reason to stage a robot before the alarm exists, and anticipation stays testable and auditable inside code.

Each carries a risk worth naming. A gate threshold set too high recreates the quiet failure it was meant to fix. All three depend on the judge\’s probabilities being calibrated on the fleet\’s own alarms, and drifting calibration will stage robots for events that never come. The remedy is the same for each: instrument it, and compare it on recorded shifts against no judge and against a fixed configuration line.

Looking forward

Fleet orchestration has so far had three shapes. Static code, which is fast, proven and blind to meaning. Orchestration handed wholly to a language model, which reads everything and is slow and costly. And workflow hybrids, where the two are stitched together by configuration that has to be authored, versioned and maintained like code, and that fixes in advance which events get judgment. Each has served the fleets it was built for. None of them is a comfortable fit for robots whose work keeps generalizing, because each asks someone to decide ahead of time where meaning will show up.

What is interesting about models like Jev is that they point past all three. A judge that returns a calibrated decision from a fixed list of answers on every event, at latency and cost comparable to the deterministic layer itself, makes it possible to build harnesses in which the split between code and judgment is not designed once but decided continuously, event by event, from evidence. The classical layer keeps what it is good at. The language model is called when reading is required. The line between them moves with the work. We do not yet know how well this holds up on a real fleet, but for the generalized robot future — where a fleet\’s tasks and coworkers multiply faster than any configuration can follow — this is the direction we find most promising, and the one we intend to continue research on.

Richard Anaya and Avi Desai, Formant — Draft, September 2026