Predicting the Next Best Move

Businesses run on decisions.

How much inventory should move to each branch? Which customer should receive an offer? Should this transaction be reviewed? When should a machine be serviced? Some of those decisions are made by people. Others are made automatically by software.

Behind many of them sits a prediction: what is likely to happen next?

The prediction is not the end product. It is an input to an action: something a person can use, a workflow can prioritize, or a system can execute automatically.

Predictions run on tables. LLMs do not.

Most business history lives in rows and columns: transactions, orders, bookings, customers, shifts, machines and events.

LLMs are remarkable with language. They can understand a question, inspect a schema and reason about a sample of data. But they are not good predictive models for millions of tabular records. They are not designed to learn stable patterns across those rows and return a probability you can validate and rely on repeatedly.

Traditional machine learning is very good at exactly that.

The problem is that building a useful ML system has traditionally required much more than training a model. A data scientist still has to understand the question, find the right tables, define the target, prevent leakage, construct features, choose a validation strategy, compare models and make the result usable.

The LLM helps build the predictive system. It does not make the live prediction.

A small game makes the idea visible

Snake is a useful toy example because its decisions are easy to see. At every turn, the game has to choose one of three actions: continue straight, turn left or turn right.

In this case, prediction and decision almost coincide. The model predicts the move an expert would make, and the game immediately executes the most likely answer.

We connected the game data to Predictabl and gave it one sentence:

“Predict the right expert move from a single game-state row.”

The question was simple. The data work was not.

Even for Snake, Predictabl first had to work out what the request meant in data: which table described the game, what one row represented, which column contained the expert’s answer and which fields could accidentally leak it.

The original dataset contained one row per position and 32 signals. Like the feature-assisted representation used by the open-source Laya Snake model, it described whether each possible move would collide, eat, leave enough space or preserve access to the tail. We also included the real path length to the food around the snake’s body.

Starting from that one sentence, Predictabl framed the request as a three-class prediction, selected the relevant columns, excluded the answer-leaking fields, chose a validation strategy and picked LightGBM for the size of the data.

An experienced data scientist could do all of this. But understanding the schema, checking the assumptions and turning the question into a valid training setup would still take hours or days. Predictabl handled the workflow automatically, without hand-written model code or feature SQL.

We also tried removing the hints

Those original columns already contained a lot of useful reasoning. To see how much Predictabl could recover by itself, we ran a second experiment and removed them.

The new dataset contained only a raw 5 × 5 view around the snake’s head, the food and tail positions, its direction and its length. Nothing said “this move is fatal,” “this move eats,” or “this area has enough room.” The cells were stored in fixed board directions, not from the snake’s changing point of view.

We gave Predictabl the same sentence. Nothing more. It rebuilt the board relative to the snake’s direction and reconstructed whether going straight, left or right would be blocked or would reach the food. The collision features never missed a real collision in our checks, and the food features were exact.

Nobody wrote a line of model code or feature SQL. About three minutes later, Predictabl had understood the data, framed the task, built the features, selected the model, trained it and tested it. The raw-board model agreed with the expert on 94.2% of game states it had never seen, with an AUC of 0.989. For comparison, the first model, with the richer precomputed signals, reached an AUC of 0.99996 ± 0.00002 across five folds.

The result is a model, not an LLM answer

Predictabl chose LightGBM for this dataset. It evaluated the model on held-out positions that were not used for fitting, and ran cross-validation before presenting the result.

The important point is not that 94.2% will be sufficient for every application. It is that performance is measured before the model is trusted. Predictabl reports held-out metrics, cross-validation, a confusion matrix and feature importance so a team can decide whether the result is good enough to deploy.

At prediction time, the input is one new raw game-state row. Predictabl applies the saved feature transformation and the trained model returns a probability for each possible move:

The game takes the move with the highest probability. There is no prompt at this stage, no generated text and no LLM in the loop. It is a prediction call to a small ML model whose behavior was tested before deployment.

The model’s own computation takes roughly one millisecond. In the live demo, a complete call through Predictabl’s local API takes about 60–65 milliseconds, mostly from request overhead, and uses zero output tokens.

Businesses do not store Snake moves

They store transactions, orders, bookings, customer interactions, staffing records, sensor readings and machine events.

But the pattern is the same: connect the historical data and describe the outcome that matters in one sentence. Predictabl works out how that request maps onto the tables, builds the features, chooses and validates a model, and serves a prediction that another person or system can use.

Instead of predicting straight, left or right, the output might be:

• the probability that each booking will be cancelled;
• the expected transactions at each branch next week;
• the probability that each scheduled shift becomes a no-show;
• the estimated time before each machine needs service.

Those predictions can inform a person, rank a queue, trigger a workflow or drive an automated decision. They are fast and cheap to call because the live system is a purpose-built ML model, not an LLM guessing from a prompt.

And because the model was evaluated on held-out data before deployment, its quality is explicit. It may or may not be accurate enough for the use case, but that question is answered with evidence rather than confidence-sounding prose.

ML could already do this. The economics are changing.

Machine learning has made decisions from tabular data for years. The model was rarely the expensive part.

The expensive part was everything required to reach it: weeks or months of data discovery, problem framing, feature work, validation and deployment. That is why companies ask a predictive question only when someone can justify a substantial data-science initiative.

Predictabl compresses that surrounding work into an automated path from a plain-language request to a tested, served model.

Snake is just the visible example. The real opportunity is every useful prediction already hiding in a company’s data.

A small comparison

These systems solve related problems in different ways. The figures below come from different hardware and test setups, so this is a product comparison, not a controlled speed benchmark.