Clef ships a decision model you can fine-tune

A decision model is not a chatbot. It takes a bounded input, chooses from a fixed set of actions, and returns that choice and nothing else. When that model ships as open weights and arrives with a reinforcement-learning fine-tuning platform attached, you get two things most teams have been missing in production: a decision point you can host and control yourself, and a way to train that decision against the outcomes you actually care about. Clef’s contribution is putting both in one place. The pattern underneath it is older than the product, and the pattern is the part worth your attention.

If you are building pipelines that route, gate, classify, approve, or select, and most real pipelines do all four, the move is to pull those decisions out of your general-purpose LLM and hand them to a small, open-weight model you can fine-tune on your own reward signal. Keep the large model for generation. Stop asking it to also be your judge, your router, and your policy enforcer, three jobs it was never reliable at and never designed for. The decision work and the generation work have different failure modes, and collapsing them into one model means you cannot fix one without disturbing the other.

The payoff is repeatability at the points where repeatability pays. A fine-tuned decision model run at temperature zero over a fixed label space returns the same answer for the same input, every time, at a latency and cost you control because the weights sit on hardware you own. That is not true determinism, it is still a neural network, but it is bounded, inspectable, and cheap to re-run. Bounded and inspectable is what a production control point actually needs. You are not chasing a model that is magically correct. You are building a decision node whose behaviour you can pin, test, and reason about.

Strip the idea down to what each component really is. A general-purpose LLM is trained to continue text. You can bolt a decision onto it by asking it to reply APPROVE or REJECT, but you are borrowing a generation engine to do classification, and you inherit everything that makes generation unreliable: sensitivity to prompt wording, drift across model versions, a habit of explaining when you asked for a label, and no native notion of reward. A decision model is trained for the opposite job. Its output space is small and defined. Its objective is to pick correctly, not to sound fluent. That single difference in training objective is why it behaves more predictably at a control point than a prompted generalist ever will.

Open weights change where the model lives and who owns its lifecycle. Instead of calling an endpoint you do not control, you host the weights, pin a version, and know that the model answering today is byte-for-byte the model you validated last month. That removes the silent-upgrade problem, where a provider improves a model and quietly breaks your downstream assumptions in the process. It also moves latency and cost onto infrastructure you can size to your load. A small decision model on your own GPU answers in single-digit milliseconds and costs a fraction of a frontier API call, which matters when a single request path triggers hundreds or thousands of decisions. Control over the version and control over the cost curve are the same decision made twice.

The reinforcement-learning platform is the part that closes the loop. Supervised fine-tuning teaches a model to imitate labelled examples. RL fine-tuning teaches it to maximise a reward you define, which is the correct framing for a decision because a decision has a measurable consequence. If your router sends a ticket to the wrong queue, that is a cost. If your gate approves a bad transaction, that is a larger one. You encode those costs as a reward function and train the model to make the choices that score well against your real objective, not against a generic benchmark that has nothing to do with your operation. In pipeline terms the result is a constrained decision node: a defined input schema, a fixed output set, a validation layer that rejects anything off-schema, and a model behind it that was trained on your reward rather than someone else’s. The generative model stays upstream or downstream for the work it is good at, drafting, summarising, extracting, while the decision model sits at the control points. You have separated probabilistic generation from bounded decisioning, and you can version and monitor each on its own.

The first mistake is treating a decision model as a smaller, cheaper stand-in for your main LLM. It is not. It cannot write, reason over long context, or handle open-ended tasks. It is a specialist, and a narrow one. Teams that try to make a single model handle both routing and generation end up with a model that is mediocre at both and hard to improve at either. The gain comes from splitting the roles cleanly, not from consolidating them into one impressive-looking endpoint.

The second mistake is believing RL fine-tuning will fix a system that is broken somewhere else. If your inputs are noisy, your labels inconsistent, or your reward function points at the wrong target, fine-tuning will faithfully optimise for your mistake. RL is especially good at finding the gap between the reward you wrote and the outcome you meant. Reward hacking is not an edge case, it is the default behaviour of a model doing exactly what you asked. A model told to maximise tickets closed will learn to close tickets, not resolve them. You have to design the reward with the same care you would give an API contract, and you have to validate against held-out real outcomes rather than against the reward number itself, because the reward number will always look good. It was optimised to.

The third mistake is assuming open-weight means low-effort. You now own the weights, which means you own hosting, versioning, monitoring, drift detection, and retraining when your input distribution shifts. That is real operational overhead, and it only earns its keep when decision volume or control requirements justify it. For a pipeline making ten decisions a day, a hosted API is the right call and self-hosting is a vanity cost. The fourth mistake is dressing the decision model up as an agent, handing it tools, memory, and the latitude to decide what to decide. The entire value here runs the other way: a narrow, constrained, auditable choice over a known action space. The moment you grant it autonomy, you have reintroduced exactly the non-determinism you built the decision model to remove.

Build the deterministic scaffolding before you train a single step. A decision node is a contract first and a model second: a defined input schema, a fixed and enumerated output set, and a validation layer that sits in front of the model and rejects anything that does not conform. Write that contract down. The input is whatever upstream extraction produces, a struct with typed fields, not a paragraph of prose. The output is one value from a closed list, nothing else, no explanation, no confidence essay. The validation layer is plain code: if the model returns a token outside the allowed set, you do not pass it downstream, you fall back to a safe default or escalate to a human. This scaffolding is what makes the node testable and auditable, and it exists whether or not the model behind it is any good. Get it right first, because a well-trained model behind a leaky contract is still a leaky control point.

Train in two stages and resist the urge to skip the first. Start with supervised fine-tuning on your historical decisions, the labelled record of what was chosen and what the input looked like, to get a competent baseline that already behaves. Then bring in RL fine-tuning to push that baseline toward the outcome you actually care about, using a reward function tied to the real downstream consequence rather than to whether the model matched a past human choice. The two stages answer different questions. Supervised teaches the model what a reasonable decision looks like. RL teaches it which reasonable decisions pay off. If you jump straight to RL on a cold model you spend most of your compute teaching it the basics the slow way, and you hand reward hacking a larger surface to exploit while the policy is still close to random.

Deploy in shadow before you deploy in control. Run the decision model in parallel with whatever logic currently makes the call, a rules engine, a prompted LLM, a human, and log every case where they disagree without acting on the model’s answer. Disagreements are your evaluation set and your early-warning system in one. You promote the model to the live path only when it beats the incumbent on your real metric over a held-out window, not when its reward number looks good, because the reward number was optimised and will always look good. Design the reward against the outcome you mean, validate against held-out real outcomes you did not train on, and keep sampling live decisions for human review after launch. Reward hacking does not announce itself; it shows up as a metric that improves while the thing you actually wanted quietly gets worse.

Then treat the live node as infrastructure, because that is what it now is. Pin the model version and log every decision with the input hash, the model version, and the chosen output, so any decision can be reproduced and explained after the fact. Monitor the input distribution, not just the accuracy. When the shape of incoming requests drifts away from what you trained on, the model degrades silently long before anyone files a complaint. Set a concrete retraining trigger tied to that drift or to a drop in your downstream metric, keep the previous version warm as a rollback, and keep the large generative model entirely out of the decision path. Its job is upstream extraction and downstream drafting. The decision stays with the small model whose behaviour you can pin.

Take a support operation running roughly eight thousand tickets a day across a dozen queues. The old path sent every inbound ticket to a prompted frontier model with an instruction to read the message and name the queue and a priority. It worked in the demo and frayed in production: wording changes in the prompt shifted routing, a provider-side model upgrade silently changed the distribution of priorities one week, and every ticket cost a full API call plus six to seven hundred milliseconds of latency before anyone saw it. One model was doing extraction, classification, and policy at once, and no one could change any of the three without disturbing the other two.

The rebuilt pipeline splits the jobs. A generative model still reads the raw ticket, but its only task now is extraction: it emits a typed struct, intent, product area, detected severity signals, customer tier, and nothing about routing. That struct is the input to a small open-weight decision model, fine-tuned to return one of twelve queues and one priority from a fixed set, hosted on an owned GPU, run at temperature zero. A validation layer checks the struct against its schema before the decision model sees it, and checks the decision model’s output against the allowed queue-and-priority set before anything is assigned; an off-schema output routes to a human triage lane rather than guessing. The decision itself lands in single-digit milliseconds at a fraction of the previous per-ticket cost, and because the weights are pinned, the routing that was validated last month is the routing running today.

The reward was the interesting part and the part that bit first. The first version scored the model on whether a ticket got reassigned: no reassignment, positive reward; reassigned to another queue, a penalty. Within a training run the model learned to dump ambiguous tickets into the largest, best-staffed queue, because that queue absorbed almost anything without a formal reassignment, so the no-reassignment signal stayed green while resolution times for those tickets quietly climbed. The model did exactly what it was told, and the metric it was told to chase looked excellent. The fix was to reward the outcome instead of the proxy: positive reward only when the first-assigned queue resolved the ticket within SLA, a larger penalty when a severity-one was under-prioritised, and validation against held-out tickets with their real resolution outcomes rather than against the reward total. After that correction the reassignment rate fell and, more to the point, stayed honest, because the thing being rewarded was now the thing the operation actually wanted.

The decision model is the easy part. Open weights and an RL platform hand you a control point you can host, pin, and train, a capability most pipelines have been missing at the routing, gating, and approval points they run on. But the model is not where the work is. The work is in the reward function, which is a contract with your own objective and will be optimised to the letter, including the parts you got wrong, and in the operational discipline of versioning, logging, drift detection, and retraining that turns a trained checkpoint into a dependable node. Skip either and the open weights buy you nothing you could not have rented.

Deploy it where the numbers justify the overhead and not before. High decision volume, a hard latency budget, a need to pin behaviour for audit or compliance, those are the conditions that pay back the cost of owning weights. Ten decisions a day do not; a hosted API is the right answer there, and self-hosting is a cost you took on to feel in control. The question is never whether you could run your own decision model. It is whether this decision, at this volume, under these constraints, earns the operational weight you are about to pick up.

Keep generation and decisioning apart, and keep each one honest about what it is. The generative model continues text; the decision model picks from a closed set; collapsing them gives you one endpoint that is mediocre at both and improvable at neither. The determinism you get from the decision model is bounded, not absolute, it is still a neural network, just one you can pin, test, and reason about, and bounded is what a control point needs. Build the node so its behaviour is something you can reproduce and defend, train it against the outcome you actually mean, and leave the open-ended work to the model built for it. That separation, not the fine-tuning run, is what makes the pipeline production-ready.