The problem
A webshop is made of thousands of small decisions: who to win back and with what, what to reorder, what to mark down. The owner has time for a few of them a week, so most get made by a fixed rule or not at all. Handing them to an agent is tempting, but most routines don't need a model that reasons. They need a calculation that can be trusted, and a routine with no grip on the shop's data guesses. A confident guess is the most expensive kind of mistake.
What lets a routine run on its own is not capability. It is knowing, for each step, how sure it is and how much evidence that rests on, and having a rule that turns that into act, ask or wait.
How it works
The shopkeeper's routines are rules on the same database the shop's screens use. For win-back, each at-risk customer's actions (an email, a discount, a voucher, a personalised ad, an apology) are scored with _predict: the chance of an order after the action against doing nothing, times the order value, minus the action's cost. The best action and its lift go to a gate, which decides in a fixed order: 1) if nothing beats doing nothing after its cost, stay quiet; 2) if fewer than 10 past rows match this customer's exact situation and action, stay quiet and say so; 3) if the action is one the shop always sends through a person (discounts, vouchers, apologies), queue it; 4) with a lift of 15 points or more, act; 5) with 5 to 15 points, propose it for one-click approval; 6) below that, stay quiet.
The thresholds are the shop's settings, not the model's. The same gate runs a stock check beside win-back. The shop's levers are also exposed as tools an agent can call, running the same code as the screens, so an agent and the owner see the same answer with the same evidence. A model that reads and writes comes in only where a rule can't, such as writing a new product's text.
# The shop's gate, run on every proposed step (first rule that applies wins)
if best_action == "none": quiet # nothing beats doing nothing
elif net_eur <= 0: quiet # not worth its cost
elif matching_rows < 10: quiet # too little evidence, says why
elif best_action in never_auto: ask # always through a person
elif lift >= 0.15: act
elif lift >= 0.05: ask # owner approves with one click
else: quietFor the full architecture, see the technology overview. For the broader narrative across multiple use cases, read The Predictive Application. For the whole picture, see predictive e-commerce.
See it live
This use case runs in the 🛒 E-commerce demo today. Click through to the live application and inspect the queries that produce the result.
Frequently asked
Is this an AI agent?
No, and that is the point. The routine is a calculation: the same data gives the same answer, and every step shows its lift, its euros and the rows behind it. A language model adds cost and variance where a calculation is good enough. In the demo, agents are used where a rule can't do the job, and the shop's tools are open to them with the same evidence attached.
Why stay quiet on a customer when the predicted lift is large?
Because a large lift on one or two matching past cases is a guess. The gate asks for a minimum number of past rows that match the customer's exact situation and the action. Below it, the routine holds off and says how many cases it found, so the owner can decide or wait for more evidence.
Can the shop change the thresholds?
Yes. The act bar, the propose bar, the minimum evidence and the kinds of action that always go to a person are the shop's settings. A cautious shop raises the bars; a shop with a lot of history can lower them.
What happens to the steps that act?
In the demo the run is simulated and nothing is sent. In a deployment, the step that acts calls the shop's email, ad or offer system, and every decision is stored with its inputs so later runs can be checked against what actually happened.
