Use AI Where It Earns Its Place.
The interesting question about AI is no longer whether to use it, but where. Here is the test we apply before adding a model to anything, and what tactical, well-engineered AI looks like in practice.
There is a lot of pressure right now to put AI into everything. Every product roadmap has a column for it, and every feature is expected to wear it. We take a narrower view. AI is a powerful tool for a specific class of problem. Bolt it onto problems outside that class and you get software that is slower, more expensive and harder to trust. That is not modernisation.
After two decades building systems that have to be right, our instinct is not to ask can we add AI here. It is to ask should we. The honest answer is often no, and the discipline to say so is what makes the times we say yes count.
A Test Before A Tool
Before a language model goes anywhere near a feature, it has to pass a simple test:
- Is the problem genuinely fuzzy? Reading unstructured text, weighing soft signals, drafting language – these are good fits. A calculation with a correct answer is not.
- Can a wrong answer be tolerated, or caught? AI output is probabilistic. If being wrong is cheap, or a human reviews it before it matters, that’s workable. If the output silently feeds a billing run or a compliance message, it is not.
- Is there a deterministic alternative that’s simply better? A rule, a lookup, or a bit of arithmetic that always gives the same result is faster, cheaper, auditable, and testable. If one exists, use it.
Most “AI everywhere” ideas fail the second or third question. The ones that pass tend to share a shape: a narrow, language-shaped judgement sitting beside solid deterministic logic, never replacing it.
Where AI Earns Its Place
A concrete example from a CRM platform we build. The product scores sales leads from nought to a hundred. The temptation is to hand the whole thing to a model and let it decide. We didn’t.
The score is computed by a deterministic spine. A fixed set of signals (engagement, recency, deal stage, value, source) combine in sub-millisecond, fully explainable code. Every lead gets a transparent “why” breakdown, and the result is identical every time it runs. That is the part that has to be dependable, so it owes nothing to a model.
The language model does one job the rules can’t. It reads the free-text notes and comments a salesperson leaves, and turns that qualitative colour into a single adjusting factor. That factor is bounded: it can only nudge the score by a small margin, so the deterministic signal always dominates. The model contributes judgement where judgement is genuinely needed, and is structurally prevented from running the show.
The same principle drives our in-product help assistant. Rather than letting a model improvise answers, it retrieves from a curated knowledge base and answers only from what it finds. When it can’t, it says so and logs the question rather than inventing a confident-sounding guess. The language comes from the model; the facts come from the knowledge base.
Engineering The Guardrails
Tactical AI is mostly guardrails. Around those two features sit the things that make AI safe to ship:
- Bounded influence. The model can adjust the result; it cannot decide it. The deterministic score is the spine.
- Caching by change. The model only runs when the underlying data has actually changed, so cost tracks real work rather than page views.
- Budgets and limits. A hard per-customer cap stops runaway usage and keeps spend predictable.
- Graceful degradation. If the model is unavailable or unsure, the feature falls back to its deterministic best and never blocks the user.
- Human authority. AI output is advisory. It never overwrites a value a person has set.
None of this is glamorous, and none of it shows up in a demo. It is also the difference between AI that survives contact with real users and AI that quietly erodes trust.
The Point
Used tactically, AI is genuinely valuable. It reads what rules can’t and drafts what people would rather not. Used indiscriminately, it makes good software worse. The skill is not in adding AI. It is in knowing the few places AI belongs, and engineering it so the rest of the system stays dependable.
If you are deciding where AI fits in your own products, and where it doesn’t, talk to our team.