Decision model vs agent: the two halves

Almost every job handed to an AI agent is two jobs stapled together: a judging half and a working half. They want different machinery.

A support queue takes 500 tickets a week. Twelve of them need a real reply. The other 488 are duplicates, delivery receipts, out of office bounces, password resets the help article already answers, and a long tail of one-line thank yous.

Hand that queue to an AI agent and it does two unrelated things to every ticket. First it works out what the ticket is. Then, for the few that earn it, it writes something and touches a real system. The first job runs 500 times a week. The second runs twelve.

Almost every job people hand an agent has that shape. There is a judging half (which of these matters, which bucket, how bad, is this real) and a **working half** (write it, send it, file it, chase it). Today one model does both, so you pay agent prices for the judging half. The judging half is the larger half by volume and the cheaper half by nature.

The two halves

They are not two settings on one machine. They differ in almost every property that decides how you build, price and supervise them.

Read the "how many items" row last, because it is the one that pays. In a queue where 12 of 500 tickets deserve a reply, 97.6% of the model calls exist purely to find those twelve, and every one is billed at the rate of something that could have written an essay.

The failure row is the other reason to keep them apart. A wrong label is a ticket in the wrong queue, which the next pass can correct. A wrong action is an email in a customer's inbox, which it cannot.

Eight shapes of judgment

Judgment sounds like one thing. In practice a small number of shapes recur, and naming yours tells you what the answer should look like before you write a line of instruction.

Three properties hold across all eight. The answer comes from a set you declared in advance, so there is nothing to parse and nothing to invent outside the set. Each is one pass with no loop. And each is cheap enough to run on the whole pile rather than on a sample.

The fourth property is the one to write on the wall: **none of the eight produces a sentence.** The moment a job needs prose, you have crossed into the working half, whatever tooling you were using a second earlier.

Which half is which in a real job

Take three kits off the shelf and draw the line through the middle of each.

The left column in all three is drawn from the same short list above. The triager screens for noise (S3), files by product area (S4), rates urgency and routes (S1) and checks the known-issue list (S5). The qualifier adds S6, because "is this a duplicate account" is a match question and not a classification. The tracker is S7 and then S3. Six of the eight shapes, across three ordinary jobs. The right column is different every time, because writing is where the job actually lives. And the ratio holds: the left column runs on every item that arrived, the right on the few percent that got through. So it goes for Follow-Up Tracker and for any worker pointed at a queue rather than at a single item. The reading is constant, the acting is rare.

Why the split changes the economics

The obvious reading is that a cheaper judging pass is a discount on the same bill. It is not. It changes what is worth looking at at all, and that is a much larger effect.

Every organisation has a long tail of piles that somebody should really read all of. Every support ticket, not the ones that escalated. Every inbound reply. Every changed row in a supplier feed. Every competitor post. Nobody reads them, not because reading is hard, but because reading all of them has never been worth a salary, and until recently it was not worth a model call either.

Here is the arithmetic on 20,000 items a month at 500 input tokens each, which is 10 million tokens. WorkerKit adds no markup to model tokens, so the first three rows are each provider's own list price as of 2026-09-16, which is exactly what the reading costs you. The fourth is a purpose-built judging model, priced by its vendor:

That last row is the vendor's own number, and comes from two different places. TypeSafe put Jev into public early access on 2026-09-15, and the price, the speed claims and the waitlist all sit on that launch post: there is no pricing page anywhere in their documentation. The output half of the row is the other source, their API reference, which reports output tokens in the response and does not bill them. TypeSafe say themselves that the rate may be subsidised, and the one cost table in their cookbooks pins it to a dated model version, so read it as a snapshot and not a price list. Their data handling terms were unpublished as of 2026-09-16, which is a question worth asking before you send anyone's mail through anything. The longer look at Jev has the detail.

The shape of the argument survives the row being wrong, though. At $20 a month you argue about whether the pile is worth reading. At $2 you stop arguing. At 42 cents the question disappears, and what is left is the only question that mattered: what do you do with the answer.

There is a second saving nobody costs properly, and it needs no vendor at all. Thirteen questions about one item in a single call read that item once, where thirteen separate calls read it thirteen times and pay thirteen round trips. Batch the questions about one item into one call, whatever you run it on. One caveat where the model generates text: questions in one call share a context and can lean on one another, so check a batched run against separate ones before you bank the saving.

The judging half still needs the same restraints

A cheap wrong label acted on automatically is still a wrong action. Nothing about splitting the job removes a single obligation.

• A [floor](/glossary/confidence-threshold), and a rule for what happens below it. Some judging APIs return a confidence derived from the shape of the answer's distribution rather than from the model's own claim about how sure it feels. Concentrated means confident, spread means not. Useful, and not a truth meter: a typed answer is a guarantee about the interface, not about the world.
• Different floors for different consequences. TypeSafe's confidence page puts this better than we would: different actions within the same system should be gated at different levels depending on the consequences of getting it wrong. Reading a balance and approving a transfer are not the same bet. Their documentation shows three bands in prose, and the numbers in their worked example are illustrative, not a recommendation you can lift.
• An undecided answer is not a middling one. A probability sitting near 0.5 means the two outcomes are equally likely, not that the thing is moderately true. Treating it as "somewhat urgent" is the easiest mistake on this page.
• The working half stays fenced regardless. What the acting worker may touch is decided by the app firewall, per app, at Off, Read or Write, not by how confident the label was. That layer ships on every plan including Free.
• Every run leaves a receipt. The label, what it beat, and what happened next, written down where somebody can read it later.

Below the floor, the honest move is a human. Route it, queue it, mark it for review, and count how often that happens, because the count is your real error rate. Failing safely on an unattended fleet is the longer version of this section.

Where the split is a bad idea

This is the half of the argument that gets left out.

• Small volumes. Under a few dozen items a week, the judging pass costs more attention to build and tune than it will ever save. Let the agent read all 30.
• Jobs where the judging is trivial and the writing is everything. "Reply to this in our voice" is one bit of judgment and a page of craft. Splitting it buys nothing and adds a hop.
• Buckets you cannot enumerate. A closed set needs its options up front, and cannot express an answer outside them. Always include a no-match option, and if most items land in it, you do not have a classification problem yet, you have a research problem.
• Retrieval. A judging pass ranks candidates you already found. Finding them is search, and search is a different tool.
• Arithmetic, lookups and exact matching. If the answer is in a column, ordinary code is cheaper, exact and free.
• Legally consequential decisions about people. Hiring, firing, credit, benefits, discipline. These attract employment law and the EU AI Act whatever the confidence says. Sorting and surfacing for a human reviewer is fine. Deciding is not, and no floor makes it fine.

What the split looks like on WorkerKit today

An agent worker runs on whichever general model you pick at deploy time. A kit brings the instruction, the app permissions and the schedule, not the model: you pick it when you deploy, switch it whenever, and send a single run to another model to compare, starting from the model grade each kit page publishes per model.

Both halves of an agent worker's job then run on that one model, so the split is worth making explicitly, in two places.

In the instruction. Name the buckets. State the floor. Say what happens below it. An instruction that says "handle urgent tickets first" has no judging half you can inspect; one that says "label every ticket as billing, bug, how-to or noise, and only draft for billing and bug" has a left column and a right column you can test separately.

In the fleet. Two narrow workers beat one broad one here. A screening worker on a cheap model whose only output is a label and a priority, and a writing worker on a stronger model that only ever sees what survived. Each has its own key, its own access grant and its own receipt, which is also what keeps the blast radius small. Screening cheap before you spend expensive walks through that setup, and how to pick a model per job covers choosing the two.

The screening worker need not be an agent. A decision worker is the other class WorkerKit runs, which is why Jev is not in the deploy-time model picker: a different shape of worker, not a model option. No loop, no prose, one pass per item, typed questions, routing decided in code. It reads through the same firewall door an agent worker uses, per app at Off, Read or Write, so the model only sees what that worker was allowed to see, already redacted. A floor is required, and below it the worker escalates rather than acts. The meter is the item judged, not the token.

Browse the directory to see which half of your job somebody has already written down.

FAQ

What is the difference between a decision model and an AI agent?

An agent reads a goal, chooses its next step, calls tools and produces text or actions, in a loop. A decision model answers typed questions about something you give it: which bucket, where on this ladder, is this true, with no loop, no tools and no prose. Agents suit the working half of a job, decision models the judging half, which is usually the larger one by volume.

When should I use a classifier instead of an LLM agent?

When the output is a choice from a set you can write down in advance, the volume is high, and nothing needs to be written. Routing a ticket, screening a reply, matching a record, ranking candidates you already found. If the answer has to be a sentence, or the set of possible answers is open, you want a model that writes.

Can a decision model write the reply?

Not the prose. It picks which template, queue, owner or priority applies, and never composes. That is not a limitation you can prompt around, it is the shape of the output. Anything that must produce prose belongs to the working half of the job and needs a model that generates text.

Does splitting a job mean running two models per worker?

Not necessarily. You can split the job inside one instruction, by naming the buckets and the confidence floor explicitly before anything gets written. On WorkerKit a common arrangement is two workers instead: a screening worker that only ever emits a label, and a stronger writing worker that only sees what the screen passed through. The screening one can be an agent worker on a cheap model, or a decision worker, which runs no loop.

Is it safe to act automatically on a classification?

Only where being wrong is recoverable. A confidence score makes uncertainty visible; it does not make the model right, and a typed answer guarantees the interface rather than the truth. Gate each action at a level that matches its consequences, send everything below the floor to a person, and keep the acting worker fenced by per-app permissions so a wrong label cannot become a wrong action in an account it was never allowed to touch.

Browse decision model kits, language model kits, or both types in the directory.