Most of the AI posts here lately are about agents and coding assistants, so this one goes the other way. It is about the quiet routing and scoring work sitting inside almost every app we build, and why a language model is usually the wrong tool for that job.
The Pattern
You have a stream of things arriving: support tickets, form submissions, inbound messages, sensor readings, orders. Something has to decide what each one is. Which team owns it, how urgent it is, whether it looks like junk, whether the number is out of line with the last thousand.
The reflex in 2026 is to send it to a language model with a prompt. It works on day one. It gets expensive and inconsistent by month three.
Why A Model Trained On Your Rows Wins Here
Three reasons, in the order they usually bite.
Cost per call. A prompt has a price every time it runs. A local classifier answers in milliseconds on hardware you already pay for, and the marginal cost of the ten thousandth prediction is zero.
Determinism. The same ticket should get the same label on Tuesday that it got on Monday. Generation is sampled, classification is not, and anything downstream that branches on the answer will thank you.
Auditability. When a classifier gets it wrong you can open the training table, find the rows that taught it that, fix them, and retrain. When a prompt gets it wrong you edit the prompt and hope.
The Practical Setup
The workflow is smaller than people expect. Collect a few hundred examples with labels you already have sitting in your database, pick a model class, train, call predict from your code. Text gets vectorized for you, numbers get scaled, and the model lands on disk as a file.
Four families cover nearly everything. Classifiers for categories, regressors for numbers, clusterers for finding groups nobody defined yet, anomaly detectors for the does this look normal question. If you want the whole catalog with plain language notes on when each one fits, the ML Prediction Engine writeup walks eighteen algorithm types and the self hosted setup behind them, PHP for the API and admin, a single file Python worker on scikit-learn for the models.
Where The Language Model Still Wins
Open ended work. Summarizing a thread, drafting a reply, extracting structured fields from a document nobody has a schema for, anything where the output space is language rather than a label. That is real value and no classifier touches it.
The mistake is not using language models. It is reaching for one because it was already in the project, on a problem that has had a cheaper deterministic answer for twenty years.
Takeaway
Before the next prompt goes into a hot path, ask what the output space actually is. If it is one of five labels, a number, or a yes and no, train something small on your own data and keep the language model for the parts that genuinely need language.