A founder sent us a brief last spring for an AI pipeline that would read inbound invoices and book them without human touch. Two days of mapping with her team showed eleven fixed checks and lookups plus one judgment call her senior bookkeeper made in seconds.
The build that shipped had no model in it. An n8n flow reads each invoice from the inbox and matches the sender against the vendor table in PostgreSQL 16. It posts the booking proposal to the accounting queue. Anything that fails a check lands in a review list the bookkeeper clears each morning. Four months in, the client processes around 4,000 invoices a month with two misroutes total, both caught at review.
This outcome repeats across our discovery calls, which run from Berlin with senior engineers in our UAE and Pakistan hubs behind them. A steady share of them arrive labeled AI and leave scoped as plain automation. Nobody on those calls feels shortchanged. The boring build costs less and ships sooner. It also breaks less often once live.
When the brief says AI and the process says rules
The invoice case is typical, so it is worth opening up. The brief asked for software that reads invoices and chases suppliers over discrepancies. Reading turned out to mean extracting fields from documents that almost all carried the same structured export from two accounting tools, so a parser handled them and the odd formats went to review. Deciding turned out to mean four fixed booking rules the bookkeeper dictated in half an hour. Chasing turned out to mean one reminder email with the invoice attached.
Nothing in that chain needed a system that guesses. Every step had a right answer defined in advance, which meant every failure had an address: the exact check that rejected the invoice. That property is the whole case for plain automation. The same input produces the same output, and the log names the step that acted. Such a system is cheaper to test and cheaper to run. Months later you can still explain exactly what it did, because the evidence sits in the log instead of in a transcript of model reasoning.
Our workflow automation service ships this kind of system most often. A trigger, a set of checks, a lookup against the system of record, an action, a log row. The components are decades old, and what makes the project succeed is the care in the mapping: sitting with the person who does the work until every branch in their head is written down as a condition the machine can evaluate.
These projects also get mislabeled for an innocent reason. Founders describe a pain that is real and expensive, and vendors answer it with the newest tool. The pain in the invoice case was forty hours a month of manual booking. The cure was forty hours of mapping plus three weeks of building. No part of that cure required a model, and adding one would have converted a solved problem into a maintenance commitment.
The test we run before a model touches anything
When a brief lands on our desk with AI in the title, we run the same checks. Each check below removes a group of steps from model candidacy. Most steps fail at the first.
How much does the input vary?
This is the check that eliminates the most model spend. A model earns its keep on input nobody can fully predict, such as free-text emails in mixed languages or PDFs from a supplier you have never seen. Rules earn their keep everywhere else: if the input arrives structured or comes from a fixed set of systems, code handles it with higher accuracy at a fraction of the running cost.
The invoice case failed this check in the best possible way. Documents that looked messy to a human eye turned out to be twelve variations of the same form, which is a lookup table rather than a training set. Supplier emails in a related project passed it, because they arrived in every phrasing imaginable, so one classification step inside that flow uses a model.
How bad is a wrong answer?
Some mistakes are reversible annoyances. A misfiled newsletter, a support ticket routed to the wrong queue, a draft that needs one more edit. A probabilistic step is acceptable there, provided a person or a rule verifies the output before it matters.
Other mistakes are wrong payments or wrong entries in records a regulator reads after the fact. Those need deterministic behavior and an audit trail that shows exactly which condition fired. A model transcript does not serve as that trail, because it records what the model said about its reasoning rather than the mechanism that produced the act. Where the error cost is high, we keep the step in code even if a model could do it faster, and we say so in writing during discovery. Clients occasionally push back on this. They stop pushing once we ask who signs off on the first wrong payment.
How often does it run?
Volume decides the economics. A model step costs tokens on every run plus weekly human attention for the review queue and re-validation after upgrades. That burden is tolerable at a few hundred items a week and punishing at hundreds of thousands of runs, where a deterministic flow with near-zero marginal cost wins by orders of magnitude.
Drift also compounds with volume. A model step that misclassifies one item in two hundred is a curiosity in a weekly report and a cleanup project at a million monthly transactions. Rules do not drift: the flow you tested in March is the flow running in October, unless someone edited it, in which case version control names the author.
What plain automation looks like in practice
A plain flow has few parts, and only the mapping takes real thought. The trigger watches an inbox, a folder, a webhook, or a schedule. Checks validate the fields against fixed conditions while a lookup joins the item against the system of record, the ERP or CRM that already holds the truth. The action then writes the result or sends the templated message. The log records what happened at each stage, and the review list collects everything the checks could not place.
Our builds use n8n or plain code depending on who will maintain the flow, with PostgreSQL behind most of them. The invoice flow took three weeks from mapping to production, including the review screen the bookkeeper uses each morning. That screen is the part teams underestimate: fifteen minutes a day on it replaced forty hours a month of manual booking, and the list itself is the test data for any future model step.
Older systems complicate this picture. Many processes we automate sit on software with no API, so the unglamorous work is integration first, usually export routines and a connector. Such engagements often start as product modernization and end as automation.
Where we still bring in a model
None of this makes us anti-model. We ship model steps regularly, and some problems have no good deterministic answer. Reading inbound inquiries that arrive in any language and deciding what each one is about belongs to a model, as does extracting line items from a document layout you have never seen. Report narratives drafted from structured source data can use one too, with a person approving the draft.
The discipline is scope. The model gets a step and never the whole flow. The step sits behind the same review list the rules use. That shape, a deterministic flow with one model step inside and a human checkpoint behind it, is the architecture of most of our AI automation delivery. We have written at length about where the boundary sits in our comparison of agents against plain workflows: variance that rules cannot capture is the only thing a model is strictly better at, so buy the model only for that variance.
The trade-off is maintenance that rules never need. Prompts need tuning when accuracy slips, and provider upgrades change behavior without asking. Someone owns the evaluation set of real inputs with known-good outputs, or nobody can tell whether the step got worse. We accept that commitment where the step earns it.
The running bill, side by side
The table below compresses the comparison we draw on discovery calls. The rows that surprise buyers are the last two.
| | Plain flow | Model step | | Cost per run | Near zero | Tokens plus review time | | Same input twice | Same output | Output can differ | | Failure pointer | Exact step in log | Transcript plus guesswork | | Behavior over time | Stable until edited | Drifts, needs re-testing |
Build cost favors whoever scopes tighter. Running cost is where the options diverge for good: the plain flow runs on infrastructure you already pay for and changes only when edited, while the model step meters tokens on every run and attention every week. None of these amounts alarms anyone alone. Together they form a permanent line item that most vendor quotes omit, which is why we put it in writing before kickoff.
Reversibility differs too. When a plain flow misbehaves, we read the log and fix the condition. The affected items replay cleanly. A degraded model step sends you hunting across prompts and retrieved context while the provider side may have shifted silently, and a replay can produce different output anyway.
Start boring and add intelligence where it earns its keep
The sequence we recommend follows from everything above. Ship the deterministic flow first and measure what it does: hours returned, error rate, cycle time, review minutes per day. The log then shows you exactly which cases resist rules, with real examples attached. If a defined step with genuine input variance emerges from that evidence, give that step a model and keep the review checkpoint. If no such step emerges, you own a finished system at a flat running cost, and the AI budget line can go back into the business.
This order keeps every future option open: the review list becomes the test set and the log becomes the specification, so a model added in six months starts from evidence rather than a blank page.
If you have a process in mind and cannot tell which side of the line it falls on, that is a normal state and a good discovery question. Ours runs from Berlin with senior engineers behind it, and the answer is sometimes a smaller build than you asked for. Send us the process and we will tell you which steps belong in code and whether any step deserves a model.
Frequently asked questions
How do we tell if our process needs AI at all?
Write the process down step by step with the person who does it today. If every step can be stated as a fixed check or a lookup, plain automation covers it and a model adds cost without adding accuracy. If one or two steps require reading free text or judging cases that resist fixed rules, those steps are candidates for a model inside an otherwise deterministic flow.
What does plain workflow automation cost compared with an LLM step?
A deterministic flow costs engineering time to build and almost nothing per run, since it executes on infrastructure you already pay for. An LLM step adds a per-run token charge plus ongoing care: someone must keep the evaluation test set current and staff the review queue, and every provider upgrade forces a re-validation round. At a few hundred items a week that overhead is tolerable, and at hundreds of thousands of runs it dominates the math.
Can we add AI later if we start with plain automation?
Yes, and that order usually produces the better system. The deterministic flow gives you measured error rates and a log of exactly which cases resist rules, so any model you add later has a defined job and a test set drawn from real failures. Starting with the model means paying for guessing across steps that rules would have handled for free.
Does the EU AI Act apply if our workflow uses no AI?
A workflow made only of fixed rules and lookups contains no AI system as the Act defines one, so its obligations do not attach to that workflow. The Act becomes relevant the day you add a model step, especially where output affects hiring, credit, safety, or access to services. Keeping the deterministic core separate from the model step makes that later assessment far simpler.
