AI or Just Automation? Two Questions That Decide It

Quick answer: a step needs AI only if its input is unpredictable in shape or its output requires judgment. If the input is structured and two competent employees would produce the same answer every time, that step has a rule, and a rule should be code. Code costs you once. A model call costs you every single time it runs, forever, and re-derives an answer you already knew.

The most expensive line item in a lot of AI builds is the part that never needed AI.

Where This Shows Up

There is a version of this conversation in almost every discovery call. Someone describes a process they want an AI agent to run. We walk it step by step. By the end, four of the seven steps are pure logic: if the form says commercial, route to Dana. If the invoice is over 30 days old, send reminder two. Nothing in those steps requires judgment. They require a rule that somebody already knows and nobody wrote down.

Handing those steps to a language model does work. It also means you now pay per run, forever, for a decision that could have been a line of code. And the model will occasionally decide differently than it did last Tuesday, for reasons you cannot inspect.

The Two Question Test

That is the whole test. It sounds obvious written down. It is not obvious in a planning meeting, because "let's have AI handle it" is a much shorter sentence than "let's define the routing rules."

What Each One Costs to Run

Deterministic automation has a cost curve that flattens. You pay to build it once. After that, running it is close to free: a cron job, a webhook, a few milliseconds of PHP. Doubling your volume does not double your bill.

Model calls have a cost curve that never flattens. You pay per token on every run. Every invocation re-reads the instructions, re-reads the context, and re-derives the answer from scratch. There is no memory of having solved this exact problem 400 times already. A step that costs a fraction of a cent is invisible at 50 runs a month and very visible at 50,000.

The math is not the interesting part, though. The interesting part is what you get for the money. When you pay a model to apply a fixed rule, you are paying for probabilistic reasoning and receiving a deterministic answer. You are buying the expensive version of an if/then statement, and the expensive version is the one that can be wrong.

The Rule of Thumb

Do not pay a model to rediscover a rule you already know.

If you find yourself writing a prompt that spells out the exact decision logic, stop. You just wrote the specification. Ship the specification. The prompt is a slower, pricier, less reliable copy of it.

Where AI Genuinely Earns Its Keep

None of this is an argument against AI in your stack. It is an argument for putting it where the leverage is. Models are worth every token on work that has no fixed rule:

• Unstructured in, structured out. A rambling voicemail transcript becomes a contact record with a name, an intent, and an urgency score. No regex was ever going to do that well.
• Classification with fuzzy edges. Sorting inbound email into "needs a human today," "route to billing," and "this is a newsletter" is judgment, not pattern matching.
• Summarizing and drafting. Turning a 40 minute call into five bullets, or a set of notes into a first draft reply.
• Extraction from messy documents. Pulling line items out of PDFs that arrive in nine different layouts.
• Genuine ambiguity where a reasonable person would say "it depends."

Notice what those have in common. The input is unpredictable, or the output requires interpretation. That is the fingerprint of an AI-shaped problem. Our six AI agent use cases are all variations on it.

The Pattern That Works: AI at the Edges, Logic in the Middle

The builds that hold up over time almost always follow the same shape. A model at the entry point, turning mess into structure. Deterministic logic in the middle, doing the routing and the record keeping and the conditional branching. Sometimes a model again at the exit, turning structure back into human language.

Concretely: a lead fills out a form and leaves a paragraph of free text. A model reads that paragraph once and returns a clean JSON object: service type, budget band, urgency, a two sentence summary. From there the workflow is ordinary code. Budget band decides the pipeline stage. Service type decides the owner. Urgency decides whether it pages someone or waits for the morning digest. One model call at the front, zero in the rest of the path.

Compare that with the version where an agent supervises the whole process. Same outcome on a good day. Ten to twenty times the token spend, a decision path nobody can audit, and a new failure mode where the agent silently skips a step because the phrasing was unusual. This is the same architectural argument as hub-and-spoke automation design, applied one layer down.

Reliability Is the Other Half of the Argument

Cost is the easy sell. The part people feel later is testability.

Deterministic logic can be unit tested. You can assert that input A produces output B, run it in CI, and know it will behave identically next quarter. When it breaks, the stack trace tells you which line and why.

A model step cannot be pinned that way. It can be evaluated, and it should be, but "passes 98 percent of our eval set" is a different guarantee than "cannot do anything else." When a model step misbehaves, the debugging tool is reading a prompt and guessing. That is an acceptable trade when the alternative is not being able to do the task at all. It is a bad trade for routing a form.

An Audit You Can Run This Week

• Write out one workflow you have automated or want to automate, one line per step.
• Mark each step with the two questions. Predictable input? Same answer every time?
• Count the model calls sitting in steps that got two yeses. That is your waste.
• Replace those with explicit rules. Keep the model calls that survive.
• Re-check the monthly bill in 30 days. That number is the whole argument.

Most stacks we audit come out somewhere around one genuine AI step for every four or five that were only there because AI was the plan. Cutting the other four does not make the system dumber. It makes it cheaper, faster, and possible to reason about at 2am.

Owned, Not Rented

There is a bigger version of this point. Every recurring cost you build into a system is a subscription you signed on behalf of your future self. Sometimes that is the right call. Token spend on real judgment work is a fair price for something you could not otherwise do. Token spend on an if/then rule is a subscription to a decision you already own. That is the same reasoning behind replacing rented SaaS with software you own.

Build the deterministic parts so they are yours. Spend the model budget where it buys you something you cannot write down.

Frequently Asked Questions

How do I know if a task needs AI or just automation?

Ask two questions. Is the input predictable in shape, meaning you could describe it as a structure? And would two competent employees produce the same output every time? Two yeses means the step has a rule and should be deterministic code. A no on either means the step requires judgment or handles unstructured input, which is where a model is worth paying for.

Is AI more expensive than traditional automation?

For fixed rules, yes, and the gap widens with volume. Deterministic automation is built once and runs at near zero marginal cost. Model calls are billed per token on every single run and re-derive the same answer each time. For work that genuinely requires judgment, the comparison does not apply, because deterministic code cannot do the task at all.

Can I use both AI and automation in the same workflow?

That is usually the right design. Put a model at the entry point to turn unstructured input into structured data, run deterministic logic through the middle for routing and record keeping, and optionally use a model again at the exit to turn structure back into human language. One model call at the front instead of an agent supervising every step.

What happens when an AI step gets it wrong?

You often will not know why. Model steps can be evaluated against a test set but not pinned to a guaranteed output, and debugging means reading a prompt and inferring. Deterministic steps can be unit tested, run in CI, and produce a stack trace naming the failing line. That difference is the strongest reason to keep rules out of prompts.