- If a competent person can write the decision as if/then on one page, it's software, not AI.
- AI earns its place with unstructured inputs, judgment at volume, and language — and needs review wherever a mistake costs money.
- Most AI projects that succeed are boring systems with one well-placed model call.
- A vendor who can't tell you which parts are deterministic is selling you a demo.
The request arrives as "we need an AI that…" and ends with a scheduled query and a template. Not because the client was naive — because a budget line that says AI makes every problem look like a model. We build AI systems for a living, and a real share of our first conversations end with us recommending something that has no model in it at all.
Plain software beats AI whenever the input is predictable enough to write the rule and being wrong is expensive. AI earns its place when inputs are unstructured — scans, emails, voice — when judgment is needed at a volume no person can sustain, or when the work is language: summaries, drafts, answers from documents. Everywhere else, the boring tool wins, and it wins on cost, speed, and the fact that it never has a bad day.
Here is how we tell the difference before anyone spends anything.
The AI-shaped hammer problem
When a company decides it needs AI, ordinary engineering problems get renamed. A reporting problem becomes "an AI dashboard." An integration gap becomes "an agent." A data-quality problem becomes "machine learning." The renaming is not harmless: it raises the price, adds a component that can be wrong, and hides the fact that the actual fix is a few days of unglamorous work.
The pattern has a shape. A vendor demo shows a model doing something impressive with clean sample data. The buyer maps that onto a messy internal process. Nobody asks the only question that matters: what part of this process is actually a judgment call? If the answer is "none of it," you are about to pay model prices for rule-shaped work.
We are not against models. We are against paying for uncertainty you didn't need.
Three requests that were never AI problems
The same three requests show up often enough that we recognize them by their opening sentence.
"We need an AI to build our Monday report." Someone spends the first half of every week assembling numbers from several platforms into one document. The request is for a model that "understands the data." What the process needs is a scheduled query that pulls the numbers, a template that lays them out, and a check that flags anything missing. That is a data pipeline, not intelligence.
Field note: For a digital agency drowning in monthly client reporting, the AI layer came last. First came connectors and a small warehouse that consolidated every platform per client; then scheduled transforms; only then did a model draft a weekly brief — what moved, why, what to change — from the numbers. It never computed them. Reporting went from a monthly scramble to a weekly rhythm, and the model's job stayed narrow enough to review.
"Our CRM doesn't talk to our invoicing — can an agent handle it?" Two systems that should share data don't. The request is for an agent that logs into both and copies things over. What the process needs is an integration: a webhook when a deal closes, a call to create the invoice, a record of what was created. Deterministic, testable, and it runs in milliseconds. An agent here is a slower, more expensive way to do the same thing with a chance of doing it wrong.
"Can AI find the duplicates and the late payments?" Duplicate customers, invoices past thirty days, orders without a shipping address. The request is for a model that "spots problems." What the process needs is a database constraint that prevents duplicates, a query that lists overdue invoices every morning, and a form that refuses to submit without an address. These are rules. Rules are free.
A fourth cousin belongs in this family: validation at the door. Most "we need AI to clean our data" requests are really "our forms accept anything." Fix the form and the cleaning problem shrinks to the residue that genuinely needs judgment.
The two questions that decide it
Every workflow we evaluate gets the same two questions. They take five minutes and they sort almost everything.
1. Can you write the rule? If a competent person in the business can describe the decision as if this, then that in under a page — including the exceptions — it's software. Not a small model, not a "simple AI," just software. The moment someone says "well, it depends, you have to look at it," we listen carefully: that sentence is either an unstated rule waiting to be written down, or a genuine judgment call. Usually it's the former.
2. Can you afford to be wrong one time in fifty, and is someone there to catch it? Language models are probabilistic. A good system built on one is right most of the time and wrong in ways that look confident. If a wrong answer costs a customer, a compliance line, or real money, then either a human reviews the output before it matters, or the step should not be a model at all.
The two answers place any workflow in one of four boxes.
| Wrong answers are tolerable (with review) | Wrong answers are expensive, no reviewer | |
|---|---|---|
| The rule can be written | Plain software (rules are cheaper than review) | Plain software, with tests |
| The rule can't be written | AI with a human checkpoint | Don't build it yet — fix the process or add a reviewer |
Notice that AI without a checkpoint appears nowhere in the grid for the businesses we work with. There are workflows where a fully automatic model is fine — ranking search results, suggesting a tag — but they are lower-stakes than most people's intake, billing, or client communication.
Where AI actually earns its place
AI earns its place when the input cannot be made predictable, when the volume of judgment calls exceeds what people can sustain, or when the output is language itself. In those cases no rule will do, and a well-placed model — with validation after it and a person somewhere in the loop — removes work that was previously impossible to automate at all.
Unstructured inputs. Scanned forms, PDFs in forty layouts, email attachments, voicemail. You cannot write a parser for "whatever the client sends." A model can read it, extract the fields you care about, and hand the uncertain ones to a person. This is the highest-value pattern we build, and it's the subject of its own note on turning forms, PDFs, and voicemail into structured data.
Judgment at volume. Triage: which incoming lead is real, which support request is urgent, which exception in an order flow needs a human. Each decision is small; the volume is what breaks people.
Field note: A regional e-commerce retailer ran storefront, delivery scheduling, and carrier coordination in disconnected tools, with exceptions handled by phone and spreadsheet. The system we built is deterministic first — storefront and routing APIs, queues, retries, an audit trail. A model appears in exactly one place: triaging exceptions and drafting customer notifications, each sent by rule or approved by a person. The ops team now runs the day from one screen. The AI is a small part of why.
Language. Summaries an attorney can verify line by line, first drafts of a grant report, answers to staff questions from a policy manual with the source cited. The model is doing the thing models are for, and the review is part of the design.
Field note: For a residential roofing company, leads arrived by phone, web form, and marketplaces and sat unanswered during storm season. Rules route every lead into one queue. A model answers routine questions, collects job details, and drafts estimates for the owner's approval. Response time went from "when someone got to it" to minutes. Rules do the routing; the model does the talking; the owner keeps the decision.
The hybrid most businesses actually need
The systems that survive contact with real operations are boring by design: a deterministic backbone — integrations, queues, validation, scheduled jobs — with one or two model calls placed exactly where a rule can't reach, each followed by a check. You should always know which parts are which. If you can't point at the model step in the diagram, either there isn't one or someone is hiding how much of the system depends on it.
This is also why "AI project" is usually the wrong name. The project is a workflow. The model is a component. Treating it that way changes the budget, the timeline, and — most of all — how the thing behaves on the day the model is wrong. We wrote up the properties of that backbone in why automations break, and how we build ones that don't.
Rule of thumb: Draw the workflow on one page. Mark each step rule, judgment, or human. If there are no judgment steps, you don't need a model. If there are no human steps and money moves, you don't have a system yet.
When not to buy — including from us
There are three situations where the honest answer is not now, and we would rather say it in the first conversation than in the third invoice.
When the vendor can't say which parts are deterministic. Ask any AI vendor — us included — to walk through the workflow and name the model steps. If the answer is "the AI handles it end to end," you are being sold a demo. Real systems have a boring majority and a small, well-fenced intelligent part.
When the process isn't stable yet. If two people in the business would handle the same case differently, no model can learn a process that doesn't exist. Write the process down first. Sometimes the writing-down is the project, and it costs a week instead of a quarter.
When the volume is tiny. A task that takes two hours a week and needs judgment is often best done by the person who has the judgment. Automation, with or without AI, pays back on volume and error cost — not on principle. Our note on what we automate first is about scoring exactly that.
The same goes for the word "agent." Most of what is pitched as agentic is an automation with a language-model step and a nice narrator. That can be a perfectly good system; it just shouldn't be priced or trusted like a new employee. We took that apart in what AI agents for business actually are.
Run it yourself
Take the three most recent "we need AI for…" requests in your business. For each one, answer the two questions in writing — can the rule be written, and can you afford to be wrong with someone catching it — and place it in the grid above.
If all three land in the plain-software row, you just saved a budget, and the work ahead is a few weeks of integration and validation rather than a model project. If one lands in the AI-with-checkpoint box, that is your candidate: it has unstructured input or real judgment at volume, and it needs a reviewer designed in from the start. If anything lands in the bottom-right box, the honest next step is process work, not procurement.
For the fuller version of this exercise — data, process, people, risk, and money, with the answers that should stop you — we keep an honest AI-readiness checklist, the same one we fill in during a first conversation.
Not every problem deserves a model. The ones that do deserve to be built properly, around a backbone that never has a bad day. Knowing the difference is the first thing we bring to a project, and it's the part that costs nothing to check — you can do it this afternoon with a pen. If you'd like a second pair of eyes on the grid, that's what our advisory practice is for.
Questions we get asked
When should AI not be used in a business?
Don't use AI when the decision can be written as a clear rule, when being wrong even occasionally is expensive and nobody is positioned to catch it, or when the process itself is unstable. In those cases a scheduled job, a validated form, an integration, or a database constraint is cheaper, faster, and never has a bad day.
What is the difference between AI and automation?
Automation executes a defined sequence of steps the same way every time. AI makes a judgment call where no rule fits — reading a scanned form, classifying an email, drafting a summary. Most useful business systems are automation with one or two AI steps inside, each followed by validation or a human check.
Is rule-based software better than machine learning?
For predictable inputs and decisions you can specify, yes: rules are transparent, testable, and free to run. Machine learning and language models win when the input is messy or the pattern is too subtle to write down. The right question is not which is better, but which part of your workflow is which.
How do I know if my business actually needs AI?
Take your three most painful workflows and ask two questions for each: can someone write the decision as a rule, and can you tolerate an occasional wrong answer with a person there to catch it? If every workflow lands on 'rule' and 'no', you need software and process work first. AI becomes worth it where inputs are unstructured and the volume is real.
What should I use instead of AI for repetitive tasks?
For repetitive, well-defined work: scheduled jobs for recurring reports, integrations or webhooks to move data between tools, validated forms to stop bad data at the door, and database rules to enforce uniqueness and deadlines. These are cheaper to build, trivial to test, and their behavior never drifts.