Give Your Agent a Fast Path

Small decision models offer a way to handle routine judgments quickly, provided we are clear about which judgments they should make.

A customer writes to say that a parcel arrived broken. Before anyone composes a sympathetic reply, the software has a few things to work out. Is this a delivery problem? Is there enough information to find the order? Which team should handle it? Much of the work happens before the first sentence is written.

These are the kinds of questions that make System 1 models interesting. TypeSafe's Jev, for example, takes information about a situation and returns answers within a structure the developer defines, along with probabilities. Give it a set of possible destinations for a ticket and it can choose among them. The application already knows how to use the answer.

There is a practical difference here from asking a language model to write a reply that happens to contain a decision. A decision model can score the available options directly. Fastino's GLiDE family does this without generating answer tokens, with models ranging from 0.4 billion to 27 billion parameters. The category includes small models, although smallness alone does not define it.

For a repeated task, that is an appealing arrangement. We can avoid spending time on an explanation nobody will read, and keep the surrounding workflow simple. A small model that handles one useful judgment well could have a place in software that has no chat window at all.

But return to the damaged parcel. Suppose the permitted answers are billing, deliveries and technical support. The model can choose a valid answer and still choose badly. Restricting the output gives the program something it can process. It does not establish that the customer reaches the right person.

What if the customer has described two different orders? What if the order belongs to somebody else? The useful next step may be to ask a question. If our list of choices leaves that out, we have asked the model to choose from an incomplete account of the situation.

I am building eSlams to explore how AI models make decisions through games. That makes this distinction familiar: a legal move can still be a poor move. The rules tell us what a player may do. What happens next tells us something about the quality of the choice.

In a business workflow, we also have to decide which judgments belong to the model. Reading a messy customer message may benefit from one. Checking whether an order number exists is usually a straightforward database query. Permission to issue a refund should remain an explicit rule that the application enforces.

The probabilities deserve the same care. A high number can be useful evidence, but its meaning has to be checked against real outcomes. Across comparable cases, do answers assigned high probabilities turn out to be right as often as expected? A confident answer to one ticket cannot settle that question.

I would begin by letting the model make recommendations alongside an existing workflow. Include ordinary requests, ambiguous ones and cases where the correct next step is to leave the decision to somebody else. Look closely at the errors before deciding which recommendations can become actions.

Then ask two questions together: how much work did it handle, and how often was that work handled correctly? A system that sends almost everything to a person may produce a comforting accuracy figure while saving very little effort. One that accepts everything can make the queue look wonderfully efficient until the corrections arrive.

Those corrections belong in the measurement. So do the time spent retrieving records and the work passed to another model or a colleague. The customer experiences the whole process. A quick classification is useful when it helps the case reach a satisfactory conclusion sooner.

Over time, the questions may change. A new product creates a new kind of complaint. A policy changes what a team can resolve. The examples used to judge the model need to keep up with the work we are actually giving it.

I like the possibility of giving these ordinary decisions a fast path through software. To trust that path, I would want to see the routine cases move through cleanly and the uncertain ones arrive with the person or system able to resolve them. That is where a quick answer becomes useful work.