AI to Build Automations vs AI to Run Them: Which One Your Business Needs

A thread on r/automation this week made a point that most people building with AI have quietly skipped past. The poster asked why everyone is so focused on using AI to run their automations when the far bigger win is using AI to build them. It pulled dozens of replies, and the same argument showed up in parallel threads on r/n8n and r/nocode about workflows that cost too much and behave unpredictably in production. That recurrence across three subreddits is the signal worth paying attention to.

The distinction sounds academic. It is not. It is the difference between a workflow that costs you nothing per run and behaves identically every single time, and one that quietly bills you a few cents on every execution while occasionally deciding to do something you never asked for. For a US small business processing a few hundred events a week, that gap is a rounding error. For an agency or an e-commerce operator handling tens of thousands, it is the difference between a system that scales and one you end up switching off.

The two modes, defined properly

AI at build time means you use a model once, during construction. You describe the process in plain English, the model drafts the workflow logic, writes the transformation code, maps the fields between your CRM and your invoicing tool, generates the message templates and produces the edge case handling you would otherwise have spent two days thinking through. Then the model goes away. What ships is a deterministic pipeline of triggers, filters, HTTP requests and database writes. It runs on rules.

AI at runtime means a model is invoked on every execution. An inbound email arrives, the agent reads it, reasons about it, picks a tool, calls the tool, reads the result, reasons again, and eventually acts. The intelligence is live. It is also billed live, and it is non deterministic by construction.

Most people building their first automation in 2026 reach straight for the second option, because that is what the demos show. In practice, a large share of what businesses actually automate does not need a model in the loop at all; it needs a model to have been in the room while the thing was designed.

Why this shows up on your invoice

Run the numbers on a realistic small business case. Say you are a UK or US service company receiving 4,000 inbound form submissions and emails a month.

• Rules based route: your automation platform subscription, typically $20 to $60 per month for a self hosted or entry tier plan, plus near zero marginal cost per execution. Total variable cost of running the logic: effectively $0.
• Single model call per event: one classification or extraction call on a mid tier model usually lands between a fraction of a cent and a few cents. At 4,000 events that is roughly $10 to $80 a month. Still perfectly reasonable.
• Full agent loop per event: an agent that reasons across several steps, pulls in retrieved context and calls three or four tools per run typically consumes twenty to fifty times the tokens of a single call. The same 4,000 events can move into the high hundreds of dollars per month, and it climbs with your volume rather than staying flat.

The point is not that agents are expensive in absolute terms; it is that you are paying a per event tax for reasoning you often do not need. If 90 percent of your inbound messages fall into six known buckets, you are paying a model to rediscover those six buckets four thousand times a month.

The reliability argument is bigger than the cost argument

Cost gets the attention because it is easy to measure. Reliability is what actually kills these systems.

A rules based workflow that routes a lead based on postcode and deal value will make the same decision on Tuesday that it made on Monday. If it is wrong, it is wrong consistently, and you can find and fix the branch in ten minutes. An agent that decides how to route the same lead may be right 96 percent of the time, which sounds excellent until you realise that on 4,000 events a month it means 160 wrong decisions, each one arrived at slightly differently, none of them reproducible from the logs.

That is the failure mode people describe when they say their automation "worked in testing and broke in production". It usually did not break. It just did something reasonable that nobody had anticipated. I have written before about why AI automations break in production, and the single most common root cause is model reasoning placed where a rule belonged.

A decision rule you can apply in thirty seconds

Before you drop an agent node into a workflow, ask one question: could a competent new hire with a one page checklist handle this step correctly?

If yes, it is a rule. Build it as a rule and let AI help you write the rule faster.

If the step genuinely requires reading unstructured language, weighing ambiguous context, or producing original text that a customer will read, then a model belongs there. Specifically, keep AI at runtime for:

• Understanding messy input. Extracting line items from a supplier PDF invoice, pulling intent out of a free text enquiry, transcribing and summarising a sales call.
• Generating text a human will read. A personalised follow up email, a WhatsApp reply that references what the customer actually asked, a quote summary in the client's own language.
• Classifying into fuzzy categories. Sentiment, urgency, or "is this a complaint or a question" where no keyword list will ever be complete.
• Open ended tool use. A genuine research or support agent where you cannot enumerate the path in advance.

Everything else, and it is most things, belongs in deterministic logic: scheduling, deduplication, field mapping, threshold checks, retries, reminders, CRM writes, payment status polling, escalation timers.

The hybrid pattern that actually works

The architecture I use on almost every build looks like a sandwich. AI sits at the edges and rules hold the middle.

1. Model call at the entry point. One structured call converts messy input into clean JSON: intent, urgency, extracted entities, confidence score. One call, not a loop.
2. Deterministic core. Everything downstream is a switch statement. Route by intent. Check the value threshold. Look up the record. Write to the CRM. Fire the webhook. No model involved, fully testable, fully auditable.
3. Model call at the exit point, if a human will read the output. Draft the reply using the structured data plus your tone guidelines. Again, one call.
4. A confidence gate. If the entry call returns low confidence or an unknown intent, the item goes to a human queue instead of guessing. This one branch prevents most of the embarrassing failures.

This gives you roughly 95 percent of the perceived intelligence of a full agent at roughly 5 percent of the cost, with logs you can actually read. When something goes wrong you can point at a specific node.

What people are actually getting paid to automate

A separate thread the same week asked what the most useful "boring" automation anyone had built was, and it drew one of the highest comment counts in the subreddit. Almost nothing in the replies involved an agent. The winners were things like: syncing two systems that should have had an integration and never did, chasing unpaid invoices on a schedule, backfilling cancelled appointment slots, watching a shared inbox and creating tickets, and reconciling payment records against orders.

That matches what I see in client work across the US, the UK and the EU. The revenue is in the unglamorous middle of the business, not in the demo friendly agent. AI earns its place in those builds by cutting the build time from three weeks to four days, not by sitting in the runtime path.

How to retrofit a workflow you have already over engineered

If you already have an agent heavy build running, you do not need to start over. Do this instead:

• Export a month of runs and look at what the agent actually decided. In most cases you will find a small number of distinct outcomes repeating.
• Write those outcomes as explicit branches. Anything covering more than about 5 percent of traffic deserves its own deterministic path.
• Shrink the agent to the residual. Let the model handle only what did not match a known branch, and log every one of those so you can promote new patterns into rules over time.
• Cap the loop. Set a hard maximum on tool calls per run and a spend ceiling per day, so a bad input cannot produce a surprise bill.
• Cache aggressively. Identical or near identical inputs should not trigger a fresh reasoning pass.

Teams that do this typically cut their per run AI spend by 80 to 95 percent and, more importantly, stop getting paged about outputs nobody can explain.

The uncomfortable implication for buyers

If you are hiring someone to build automation for your business, this framing gives you a useful screening question. Ask a prospective builder where the AI sits in their proposed system. If the answer is "an agent handles it", ask what happens when the agent is wrong, what it costs per thousand executions, and how they would reproduce a specific past decision from the logs. A good builder will already have a deterministic core and will be able to answer all three without hesitating.

The industry incentive runs the other way, because agents demo beautifully and justify higher retainers. But the systems that are still running a year later are almost always boring underneath. If you want a second opinion on an architecture, that is exactly the kind of review Gideon Wafula, AI Automation Engineer does before quoting a build, and it is part of the standard scoping process for my AI automation services.

Where to start this week

Pick your single highest volume repetitive process. Write down every decision point on one page. Mark each one as either "a checklist could do this" or "this needs judgement". You will usually end up with eight checklist steps and one judgement step. Build the eight as rules, using an AI assistant to write them fast, and spend your model budget only on the ninth.

That is the whole insight buried in the Reddit thread, and it is worth more than most of the agent tutorials published this year.