Fenn: a model that returns choices, not prose
Most language models hand you a paragraph and leave the parsing to you. Fenn returns a typed decision with a confidence score. Here is what that changes and where it fits.
Rui Valente
A model that picks instead of writing
Most of the model tooling we use in client work produces text. We then write code to read that text, check it, and turn it into something our systems understand. Fenn, released this week by a small lab in Ghent, skips that step. You give it a list of allowed outcomes and it returns one of them, with a score.
For the kind of software we build, that is a better fit. A support inbox does not need a paragraph; it needs a label. A booking form does not need a summary; it needs a yes, a no, or a request for a human.
Where the name comes from
Fenn is short for fenland, the flat drained marshes of eastern England. The team picked it because, in their words, the model works on flat ground: a fixed set of options, no open field.
In practice that means two prompts become one schema. The schema doubles as documentation: anyone on the team can read the list of outcomes and know what the system is allowed to do.
What Fenn does, and what it gives up
You define a schema with the possible decisions and the fields each one needs. Fenn reads the input and returns exactly one decision that matches the schema. If it cannot reach the confidence threshold you set, it returns an explicit “unsure” value instead of guessing.
The cost is range. Fenn will not write your release notes or draft an email. It also needs the options up front, so it is a poor fit for open questions.
How it compares to a general model
Latency matters more than it looks. A routing step that takes a second and a half is noticeable on a form; one that takes 150 milliseconds is not. Fenn runs on small hardware and answers inside a normal page request.
| General model | Fenn | |
|---|---|---|
| Output | Free text, parsed afterwards | One typed decision |
| Validation | Written by us | Built in |
| Unsure cases | Often a confident guess | Explicit “unsure” |
| Latency | 600–1,500 ms | 90–200 ms |
| Good for | Drafting, summaries | Routing, triage, checks |
Why the confidence score matters
A score only helps if it means something. In our tests on 2,000 labelled support tickets, decisions above 0.9 were correct 97% of the time. Below 0.6 the accuracy dropped to 71%, which is the point where we send the ticket to a person.
That gives a clean rule for production: act on high scores, queue low ones, and log the rest for review.
We also tested the threshold itself. Moving it from 0.9 to 0.8 sent 9% more tickets through automatically and cost 2 points of accuracy. For this client we kept 0.9; for internal tools we would accept 0.8.
Our test, with numbers
Routing. We replayed one month of a client’s support inbox. Fenn sorted 82% of tickets without a human and sent the rest to the queue. Median time to first response went from 3 hours to 11 minutes.
Form checks. On a booking portal, Fenn flagged incomplete customs documents before submission. False positives stayed under 3%.
Cost. At current pricing, routing the full month cost less than one hour of coordinator time.
Where we will use it
We are adding Fenn to two client projects this quarter: ticket routing for a rental company and document checks for a freight portal. For anything that needs prose, we keep using general models.
If you run a process with a fixed set of outcomes and a lot of manual sorting, this is worth a test. Our contact form is at the bottom of the page.
We also log every “unsure” result. If the share of unsure answers grows, the inputs have changed, and that is a product question before it is a model question.
Every week we sample 50 automated decisions and compare them with what a coordinator would have done. Disagreements go back into the schema as clearer option descriptions, not into a bigger model.