Which layer of AI does your project actually need?

Every few months a new model drops, benchmarks spike, and the same conversation restarts: should we switch to GPT-5, fine-tune something ourselves, or wait for the next release? These are not bad questions. They are just the wrong ones to start with.

Before you pick a vendor, a framework, or an architecture, there is a more basic question that most teams skip: which layer of AI does this problem actually belong to? The layer determines whether the solution is explainable or not, whether it needs labeled training data or hand-coded rules, whether you are building something that runs in milliseconds or something that spins for thirty seconds calling APIs. Getting the layer wrong is expensive in ways that are hard to recover from once you are six months into the build.

There are six layers. They are cumulative, not interchangeable. Here is what each one is, where it belongs, and what it costs you when you misapply it.

Layer 1: Classical AI

Classical AI is rule-based. If X, then Y. An expert writes down the logic, a system executes it. The most cited early example is MYCIN, a 1970s system for diagnosing bacterial infections. It contained around 600 handcrafted rules and in some studies outperformed junior physicians. It was not learning anything. It was executing a very precise decision tree.

This layer still runs a significant fraction of the world’s decision-making software: fraud scoring rules, credit approval logic, clinical pathways in hospital systems, content moderation blocklists. The advantages are real. Rules are fast to execute, easy to audit, and easy to update when policy changes. If a regulator asks why the system made a decision, you can point to exactly which rule fired.

The limitation is equally obvious: if the rules are wrong, the system is wrong, and someone has to go fix them. And writing comprehensive rules for genuinely complex, ambiguous problems is not always possible. That limitation is what drove the field toward the next layer.

The mistake teams make here is deploying a generative model to do something that a rule set would handle more reliably and cheaply. A classification task with five clearly defined categories does not need a 70-billion-parameter LLM. It needs a well-maintained decision tree and a person who keeps it current.

Layer 2: Machine learning

Machine learning is where the rules stop being written by hand. Instead of encoding logic explicitly, you give the system labeled examples and let it learn statistical patterns from the data. Supervised learning classifies or predicts given a label. Unsupervised learning finds structure without one. Reinforcement learning optimizes behavior through reward signals, which is how AlphaGo learned to beat world champions at a game where explicit rules would never have been sufficient.

For most business prediction problems, this layer is still where the most reliable work gets done. Churn prediction, demand forecasting, fraud detection on tabular transaction data, recommendation systems, anomaly detection in time series. The models are interpretable enough to validate, fast enough to run at scale, and cheap enough to train without specialized hardware.

The cost of this layer is explainability, and it compounds as models grow more complex. A linear regression is fully transparent. A gradient boosted ensemble is harder to explain. A deep neural network is harder still. For any domain where you need to explain individual decisions to users, regulators, or courts, the choice of model is a legal and compliance question, not just a technical one.

The mistake here is jumping past ML to generative AI for tasks that ML handles well. If you have labeled training data and a well-defined output, a traditional ML model will be more accurate, faster to serve, and easier to maintain than an LLM wrapping the same problem.

Layer 3: Neural networks

Neural networks take the statistical learning framework and add depth. Inspired by how biological neurons connect, they stack layers of simple operations into architectures that can learn representations the engineer did not specify.

Convolutional neural networks reshaped computer vision. Recurrent networks handled sequences before transformers arrived. Both required significant advances in hardware, training techniques, and data availability to become practical. Backpropagation, the algorithm that makes training deep networks feasible, was described in the 1970s but only became computationally viable in the 2010s when GPU clusters became accessible.

What neural networks added, beyond accuracy on complex tasks, was the ability to learn features directly from raw inputs. You no longer needed a domain expert to hand-engineer the right signal for an image classifier. The network learned what to look for. That changed what was buildable and by whom.

The cost is opacity and compute. Training a deep network requires data at scale, hardware budgets that most small teams cannot sustain, and significant expertise to tune. Debugging a failing network is not like debugging a failing rule. You are inspecting gradient flows and activation patterns, not reading a logic tree.

Layer 4: Transformers

The 2017 paper “Attention Is All You Need” introduced a new architecture that changed the trajectory of the field. Transformers replaced the sequential structure of RNNs with self-attention: a mechanism that lets every token in a sequence attend to every other token, regardless of distance. That change allowed models to be trained in parallel and to capture long-range relationships that RNNs struggled with.

GPT, Claude, Gemini, LLaMA, and every major language model in production today is a transformer. The architecture also spread beyond text. Vision transformers replaced CNNs in image classification benchmarks. Protein folding models like AlphaFold 2 use transformer attention on amino acid sequences.

The practical consequence for builders is that transformers are generalist. A single pretrained model can be fine-tuned or prompted to handle tasks that previously required separate purpose-built systems. That generalism is genuinely useful, and it has also created the expectation that a transformer can do everything. It cannot. Transformers are excellent at pattern completion and language generation. They are bad at precise counting, arithmetic, and enforcing strict logical constraints without additional scaffolding.

The cost is the same as the rest of the neural network family, but larger. Inference on a large transformer is expensive. Hosting it in production is expensive. Keeping it current as the underlying model is updated is its own maintenance surface.

Layer 5: Generative AI

Generative AI is what happens when you scale transformers and train them on enough data to generate novel content: text, images, audio, code. Large language models generate text and code. Diffusion models generate images (Stable Diffusion, DALL-E, Midjourney). Multimodal systems combine both, along with video, audio, and structured data.

Most current product building is happening in this layer. Copilots, writing assistants, code generation tools, customer service bots, document summarization. The generation quality at this layer is genuinely impressive, which is why the gap between demo and production system is so consistently underestimated.

A generative model in a demo runs on curated inputs and tolerates hallucinations because no one is catching them. A generative model in production runs on adversarial inputs, must handle edge cases it was never shown, and needs to fail gracefully rather than confidently wrong. Closing that gap takes significant engineering work in evaluation, guardrails, and retrieval augmentation. Most teams budget for the model. They underbudget for the system around it.

The other common mistake at this layer is using generation where retrieval is sufficient. If your application is answering questions about a fixed document corpus, you do not need to generate answers from model weights. You need a retrieval system that finds the right passage and surfaces it. RAG architectures get this right. Naive prompting often does not.

Layer 6: Agentic AI

Agents add three things to the generative layer: memory, planning, and tool use. A language model alone generates a response. An agent takes a goal, breaks it into steps, uses tools to execute those steps, observes the results, and adjusts its plan. It can call APIs, write and run code, search the web, read files, and interact with external systems.

The most common current implementations are coding agents (automated pull request generation, debugging loops), research agents (multi-step web search and synthesis), and workflow automation agents (connecting SaaS tools without custom integrations). The promise is real. So is the failure mode.

Agents that work in demos often fail in production because the reliability of the system compounds across steps. If each step has a 95% success rate and the task requires ten steps, the probability of a clean run is about 60%. In production, that number means one in three tasks requires human intervention or a retry loop. Designing for this, with checkpoints, fallbacks, and human-in-the-loop escalation, is the engineering work that separates production agents from impressive demos.

The reliability question at scale is still genuinely open. This is the right layer for problems that require multi-step reasoning across systems and cannot be decomposed into simpler tasks. It is the wrong layer for problems that a well-designed API call or a simple classifier can handle.

Before you pick the tool, place the problem

The practical framework is straightforward. Does the decision require clear explainability for regulatory or legal reasons? Layer 1 or 2. Does it involve unstructured input at high volume where meaning matters more than strict precision? Layer 4 or 5. Does it require autonomous, multi-step execution across systems with minimal human involvement? Layer 6. Is it tabular prediction with a well-defined label and historical training data? Layer 2, probably just XGBoost or LightGBM.

The mistake that costs teams the most is building at layer 5 or 6 when layer 1 or 2 would work. A rules engine wearing a transformer’s clothes is a maintenance problem. An agent doing the work of a classifier is an accountability problem. More powerful does not mean more appropriate.

The stack is cumulative. Each layer builds on the ones below it, and choosing a higher layer means inheriting the costs of all the layers beneath. More compute. More data requirements. More opacity. More infrastructure to maintain. Those costs are worth paying when the problem genuinely requires them. They are not worth paying because the demo looked good.

At Boosty Labs, this is how we approach AI engagements: establish the right layer first, then select the implementation. The layer determines the architecture, the cost model, the explainability requirements, and whether the thing will actually work in production over time. Every conversation about tools, vendors, and models starts after that question is answered.