Beyond the LLM: A field guide to AI and Automation

Sit in on enough AI strategy conversations and you'll start to notice a quiet substitution. Someone says "let's use AI for this," and within a few minutes, without anyone deciding it out loud, that has become "let's use an LLM for this." It happens so smoothly that most people in the room never clock the swap. But it's an expensive one, and it's happening in product reviews, innovation pitches, and vendor demos across every industry right now.

The substitution is expensive because a large language model is one tool in a much larger toolbox, not a replacement for the whole box. Automation and machine learning have been solving business problems for the better part of a century, and most of those problems still have a better answer than "route it through a chatbot." The irony is that the current moment, thick with LLM hype, is exactly when it pays to know the rest of the toolbox cold: what each category of tool actually costs to build and run, what data it needs, how fast it responds, how easy it is to explain, and how reliably it behaves from one run to the next.

This is a field guide to that toolbox. It starts with a short history of how we got here, then walks through ten problem archetypes that cover the vast majority of automation and AI use cases, regardless of industry. For each one, it names the tool category that fits and evaluates it against the practical criteria that should actually drive the choice — not just what the tool can do, but what it costs to get there.

A short history, compressed

The pattern across every wave of this field is the same: a new capability arrives, gets over-applied to problems it's a poor fit for, and eventually finds its actual place in the toolbox alongside — not instead of — everything that came before.

In the 1960s through the 1980s, the dominant idea was the expert system: encode a human expert's rules into an if-then engine, and let the machine apply them tirelessly and consistently. These systems were cheap to run and fully transparent, but expensive to build and maintain as rules multiplied, and brittle outside the narrow domain they were built for. That brittleness triggered the first "AI winter," when funding and enthusiasm collapsed through the late 1980s and early 1990s.

What emerged from that winter was statistical and classical machine learning: instead of hand-coding rules, let the system learn patterns from data. Techniques like regression, decision trees, and later ensemble methods (random forests, gradient boosting) matured through the 1990s and 2000s and quietly became the backbone of credit scoring, fraud detection, demand forecasting, and industrial quality control — relatively cheap to train and run, and still doing most of the world's structured-data decision-making today.

The 2010s brought the deep learning wave, unlocked by GPU-scale compute and large labeled datasets — at real cost, both in compute and in the data collection and labeling effort behind it. Neural networks made real progress on perception problems — recognizing images, transcribing speech — that classical methods handled poorly. And starting around 2017, the transformer architecture set up the current era: large language models, trained at enormous cost on internet-scale data, that generate fluent, context-aware text and, since roughly 2022, have moved from research labs into everyday products.

Each wave solved problems the previous one couldn't, and each one has been followed by a period of over-application before the field settled into a more accurate sense of where the new tool actually belongs. We are in the over-application phase of the LLM wave right now. The rest of this guide is about seeing past it.

What actually decides which tool fits

Raw capability gets most of the attention in AI conversations, but capability alone rarely settles which tool belongs in a given job. In practice, five practical criteria do most of the real work, and they matter together, not in isolation:

• Cost and complexity — what it takes to build, run, and maintain the thing: compute, licensing, specialized talent, ongoing upkeep as conditions change.

• Data requirements — how much data it needs, of what quality, before it works at all, and whether that data is something you actually have.

• Latency — how fast it has to respond, and whether the tool can plausibly hit that bar in production, not just in a demo.

• Explainability — can you trace, in terms a stakeholder or auditor would accept, why the system produced this specific output — from fully transparent (a rule you can point to) to a black box you can only judge by its results.

• Determinism and reliability — does the same input reliably produce the same output, and are the failure modes predictable — from strictly deterministic to probabilistic, where outputs vary run to run.

None of these five outranks the others by default. A customer-facing chatbot might tolerate low determinism but not high latency; a certification-critical safety check might tolerate real cost but not low explainability. The ten archetypes below are organized by the type of problem being solved, roughly from the most constrained and well-understood to the most open-ended — which also happens to track the rough order in which the field developed the tools for each.

Ten problem archetypes, and the tool that fits each

1. Deterministic, rule-based problems

Tools: rules engines, decision tables, expert systems, business rules management systems (BRMS) Cost: Low to run, medium to maintain as rules grow | Data needs: None — logic is authored, not learned | Latency: Very low | Explainability: High | Determinism: High

When the logic governing a decision is known, stable, and can be written down — eligibility checks, tax and tariff calculations, approval thresholds, regulatory compliance rules — a rules engine is almost always the right answer. It needs no training data, runs near-instantly, and is completely traceable and deterministic. The real cost shows up later: every change in policy requires a change in the rules, and rule sets that grow for years become their own maintenance burden. The approach also doesn't generalize to logic nobody has articulated yet.

Example: a loan pre-qualification check applying documented underwriting criteria, in any lending market.

2. Repetitive, multi-step process problems

Tools: robotic process automation (RPA), workflow orchestration Cost: Low-medium licensing, ongoing upkeep as UIs/systems change | Data needs: None | Latency: Low | Explainability: High | Determinism: High

Some work isn't hard, it's just tedious: the same sequence of clicks, data entry, and system hand-offs, repeated across systems that were never built to talk to each other. RPA scripts and orchestration platforms need no training data and are deterministic and auditable by construction, which keeps day-to-day cost low. The catch is fragility: a UI change or an unexpected input format breaks the script until someone fixes it, so the real cost is ongoing maintenance rather than upfront build.

Example: reconciling records between an ERP system and a supplier portal every night.

3. Optimization and constraint problems

Tools: linear/integer programming, constraint solvers, classical operations-research heuristics Cost: Medium — compute can grow sharply with problem size | Data needs: Low-medium, mainly accurate constraint and cost inputs | Latency: Varies — seconds to hours depending on scale | Explainability: High | Determinism: High

Finding the best allocation of a limited resource — the shortest route, the tightest schedule, the least-cost mix — under a known set of constraints is a solved mathematical problem for a huge range of cases. Solvers need no learned model, just an accurate formulation, and return a provably optimal (or near-optimal, with a known bound) answer you can inspect constraint by constraint. The real cost driver is scale: large, tightly coupled problems can be genuinely expensive to solve exactly, pushing teams toward heuristics that trade a little optimality for speed.

Example: routing a delivery fleet, scheduling operating rooms, or building a production plan across multiple lines.

4. Prediction problems over structured data

Tools: statistical models (regression, time-series/ARIMA), classical ML (gradient boosting, random forests) Cost: Low-medium to train and run | Data needs: Medium — a reasonable history of structured records | Latency: Low at inference | Explainability: Medium | Determinism: High

Forecasting a number — next quarter's demand, a component's remaining useful life, a customer's likely spend — from historical structured data is exactly what classical statistical models and tree-based ML were built for. These models are cheap to train and run compared to deep learning, need only a moderate amount of clean structured history, and respond in milliseconds once deployed. Given the same trained model and input, the output is consistent, and techniques like feature importance and SHAP values give a real, if partial, explanation of what drove a prediction — one reason these methods routinely match or beat deep learning on tabular data at a fraction of the operational cost.

Example: forecasting inventory demand or predicting equipment maintenance intervals from sensor and usage logs.

5. Classification problems over structured data

Tools: classical ML classifiers (logistic regression, decision trees, gradient boosting, SVMs) Cost: Low-medium | Data needs: Medium — labeled historical examples | Latency: Low | Explainability: Medium | Determinism: High

Sorting cases into known categories — approve/deny, fraud/not-fraud, defect/pass — is the classification twin of the prediction archetype above, and shares its cost profile: cheap to train and run, needing a moderate amount of labeled history rather than internet-scale data, and fast enough for real-time use. A well-tuned gradient-boosted tree is usually cheaper to run, faster to retrain, and easier to explain to a regulator than a neural network, while performing just as well on most structured, tabular tasks. This is arguably the most under-used category in the current AI conversation, precisely because it isn't new or exciting.

Example: transaction fraud scoring, insurance claim triage, or quality-control pass/fail decisions on production data.

6. Anomaly and outlier detection

Tools: statistical process control, clustering, isolation forests Cost: Low | Data needs: Low-medium — enough history to define "normal" | Latency: Low, suitable for continuous streams | Explainability: Medium | Determinism: High

Spotting the observation that doesn't fit the pattern doesn't require a deep model in most cases. Statistical process control charts, distance-based clustering, and isolation forests are cheap enough to run continuously on high-volume streams, need only enough history to establish a baseline, and — because that baseline is explicit — usually let you explain why a point was flagged: it's a certain distance from the cluster, or outside a control limit.

Example: flagging unusual transaction patterns, sensor readings, or network traffic in real time.

7. Perception problems (images, audio, sensor signal)

Tools: computer vision models, signal processing, purpose-built neural networks Cost: High — GPU training and often GPU inference | Data needs: High — large labeled datasets | Latency: Medium, can be optimized for real time | Explainability: Low | Determinism: Medium

Recognizing a pattern in unstructured signal — an object in an image, a defect in a scan, a word in an audio stream — is where deep learning earned its reputation, and it remains the right category of tool for this kind of problem, though it comes at real cost: large labeled datasets, meaningful compute for training, and often specialized hardware for inference. A purpose-built vision or signal-processing model, trained narrowly on the task at hand, is typically more accurate, cheaper to run, and more predictable than a general-purpose multimodal LLM asked to do the same job. Explainability tools exist (saliency maps, attention visualization) but they're approximate, not a full audit trail.

Example: visual inspection of manufactured parts, or automatic transcription of field audio.

8. Control and sequential decision problems

Tools: control theory (PID controllers), classical planning, reinforcement learning Cost: Low for classical control, high for RL training | Data needs: None for control theory, high (simulation/interaction) for RL | Latency: Very low, real-time by design | Explainability: Medium | Determinism: High

Systems that have to observe, decide, and act continuously — holding a temperature, balancing a load, sequencing a robot's next move — are usually best served by classical control theory, which needs no training data, runs cheaply in real time, and has decades of formal guarantees behind it, or by classical planning when the problem is more combinatorial than continuous. Reinforcement learning earns its place when the environment is too complex to model by hand, but it's expensive to train (often requiring extensive simulation), and trades away some predictability in exchange, so it needs careful bounding before it's trusted with anything physical or costly to get wrong.

Example: HVAC temperature regulation, or robotic arm motion planning on a production line.

9. Retrieval and lookup problems

Tools: search and indexing, databases, full-text and vector search Cost: Low | Data needs: Low — needs indexing, not training | Latency: Very low | Explainability: High | Determinism: High

Finding the right existing piece of information fast — the current policy, the relevant clause, the matching record — is a search and indexing problem, not necessarily a generation problem. A well-indexed database or search engine is cheap to run, needs no training data beyond indexing the corpus itself, returns the same result for the same query every time, and shows exactly which document or record it came from. It's worth pausing here before reaching straight for retrieval-augmented generation with an LLM: often the LLM's only real job should be phrasing the answer in natural language after a conventional search has already found the right source, which keeps the expensive, less-explainable part of the system as small as possible.

Example: looking up the applicable clause in a contract library, or the current spec revision for a part number.

10. Open-ended language and reasoning problems

Tools: large language models Cost: High per-query compute, especially at scale | Data needs: Low task-specific data, though built on massive pretraining | Latency: Medium — seconds, not milliseconds, for complex outputs | Explainability: Low | Determinism: Low

This is the archetype LLMs were actually built for, and where they are, genuinely, the best or only tool available: synthesizing an answer across unstructured, ambiguous, or previously unseen combinations of information; holding a natural conversation; drafting or summarizing free-form text; generating first-pass code. They need little or no task-specific training data — a real advantage over the perception archetype above — but that convenience comes with its own cost profile: meaningful compute per query, latency measured in seconds rather than milliseconds for anything substantial, outputs that are probabilistic (the same prompt can produce different results), and reasoning that isn't fully traceable even to the people who built the model. That combination is exactly why the archetypes above this one exist and should absorb as much of the workload as the nature of the problem allows, leaving the LLM for the open-ended remainder.

Example: drafting a first pass of a technical report, summarizing a pile of customer feedback, or answering a novel question that spans multiple unrelated documents.

A quick-reference summary

ArchetypeTool categoryCost / complexityData needsLatencyExplainabilityDeterminismDeterministic, rule-basedRules engines, expert systemsLow to run, medium to maintainNoneVery lowHighHighRepetitive multi-step processRPA, workflow orchestrationLow-mediumNoneLowHighHighOptimization / constraintsLinear/integer programming, solversMedium, scales with problem sizeLow-mediumVariesHighHighPrediction (structured data)Statistical models, classical MLLow-mediumMediumLowMediumHighClassification (structured data)Classical ML classifiersLow-mediumMediumLowMediumHighAnomaly / outlier detectionStatistical process control, clusteringLowLow-mediumLowMediumHighPerception (image/audio/signal)Computer vision, signal processingHighHighMediumLowMediumControl / sequential decisionsControl theory, planning, RLLow (control) to high (RL)None (control) to high (RL)Very lowMediumHighRetrieval / lookupSearch, indexing, databasesLowLowVery lowHighHighOpen-ended language / reasoningLarge language modelsHighLow (task-specific)MediumLowLow

Why this discipline matters even more in regulated, long-cycle industries

Every industry pays a cost when the wrong tool is applied to a problem, but in regulated and long-cycle industries — aviation, medical devices, finance, energy, rail — that cost is structural, not just operational. A decision that can't be explained can't be certified or audited. A system whose behavior varies from run to run can't be validated once and trusted thereafter; it has to be continuously monitored, which is its own ongoing cost — on top of whatever the tool already costs to build and run. None of that is a reason to avoid LLMs in these industries — there are plenty of open-ended language and reasoning tasks even in the most regulated environments — but it is a reason to weigh all five criteria deliberately for a given task before reaching for a tool, rather than starting from the tool and working backward to justify it.

The takeaway

None of this is an argument against LLMs — the open-ended reasoning and language archetype is real, and growing, and LLMs are the right tool for it. It's an argument for diagnosing the problem before prescribing the tool, and weighing cost, data requirements, latency, explainability, and determinism together rather than defaulting to whichever tool is most talked about. Ask what kind of problem you actually have, and what you can actually afford in each of those five dimensions, and the right category of tool is usually already implied by the answer. The teams getting the most durable value out of AI right now aren't the ones using the most LLMs. They're the ones matching each part of their workload to the simplest, cheapest, most reliable tool that actually fits it, and reserving the expensive, probabilistic tool for the part of the problem that genuinely needs it.

InnoStack

Bridging the gap between technical knowledge and product vision.

Empowering leaders to build what matters.

Quick Links

Articles

© 2025. All rights reserved.

Let's collaborate

Stay tuned !

Subscribe for the latest insights and resources

About

Frameworks