The most useful thing we do on a lot of engagements is talk a client out of using a language model. Not because models are not remarkable. They are. But because a model is a probabilistic component, and a lot of the work people want to point it at is deterministic, auditable, and unforgiving of the occasional confident mistake.
Here is the rule of thumb we come back to. Reach for a model when the input is messy, the output tolerates a range of good answers, and a human is close enough to catch the rare bad one. Reach for a rule when the logic is knowable and the cost of being wrong is high.
Three questions before the model
Before we write a single prompt, we ask three things about the task. Each one quietly pushes the work toward a model, a rule, or a person.
Put the model where it is cheap to be wrong
The pattern that works, again and again, is to let the model do the messy first pass and let a rule or a person own the commit. Drafting, extracting, summarising, routing, ranking. These are places where a good-enough answer moves the work forward and a wrong one costs a click, not a customer.
The boundary is the design
So the real design work is not the prompt. It is the seam. Deciding exactly where the probabilistic part ends and the deterministic part begins, and making that seam visible, testable, and honest.
