AI Systems, Classified: Match the Machine to the Task
A catalog of AI, from expert systems to frontier models.
In the current age of AI and machine learning, there are a lot of machines that can think and act given a direction. Most people reach for the frontier models to just get things done, which is fine for saving time, but it does not buy you a repeatable system for a long-lasting project.
The main aim of AI is to free up our time to do something more productive. The definition of productive is an exercise in itself, but a prominent one these days. So which repetitive tasks can we hand to computers without the fear of breaking them when the winds change direction? Let’s break the tasks into categories and fit the systems to these purposes.
The big labs give you bots that pass the Turing test and do a lot given the right tools. But plenty of jobs get done better, cheaper, and faster by something much smaller, as long as you match the system to the job.
Two axes, not one
The mistake underneath most AI spend is treating task size and model size as the same dial. They aren’t. AI size should grow with task ambiguity, context length, autonomy, risk, and time horizon. Input size is the least of it.
Separate the two and the catalog falls out cleanly: a scale for how big the task is, a scale for how big the system is, and a rule for pairing them.
Task size: T0 to T6
A task grows along more than one dimension. Input size is the obvious one and the least important. A task is large when the goal is vague, the reasoning is multi-step, it carries state, it takes external action, a wrong answer is expensive, or you can’t easily tell whether the answer was right.
| Task size | Task shape | Context | Examples |
|---|---|---|---|
| T0 Signal | one input → one label/action | very small | spam flag, wake word, fraud flag, toxicity score |
| T1 Micro | one small transformation | small | rewrite a sentence, classify a ticket, extract fields |
| T2 Local | one document / page / item | medium | summarize a PDF, answer from one page, explain a fn |
| T3 Composite | several related steps | medium–large | compare products, generate an API spec, debug a bug |
| T4 Workflow | goal + tools + state | large | support workflow, research a topic, open a PR |
| T5 Project | multi-day, multi-file, multi-stakeholder | very large | build a feature, migrate a codebase, design a system |
| T6 Organization | continuous autonomous operation | huge | run sales ops, manage infra, autonomous trading |
The jump that matters is T3 to T4. Below it the system reads and writes; at T4 it starts to act — it holds state, calls tools, and decides which step comes next. T5 and T6 add duration: a project runs for days across many files, an organization task never stops. Autonomy, not token count, is what makes the top of this scale hard.
AI size: A0 to A6
| AI size | Rough scale | Good at |
|---|---|---|
| A0 Rules / heuristics | no model or tiny logic | deterministic routing, validation, thresholds |
| A1 Tiny | <10M params | detection, filtering, simple classification |
| A2 Small | 10M–1B params | ranking, extraction, OCR, embeddings |
| A3 Medium | 1B–10B params | summarization, RAG, domain chat, autocomplete |
| A4 Large | 10B–100B+ params | reasoning, coding, planning, multimodal |
| A5 Frontier | massive / distributed | hard reasoning, long-context work, hard generation |
| A6 System-of-systems | model + tools + memory + workflows | acting over time, using APIs, running projects |
Pairing them
| Task size | Best-fit AI | Why |
|---|---|---|
| T0 Signal | A0–A1 | rules or tiny models are cheaper, faster, safer |
| T1 Micro | A1–A3 | narrow intelligence, not broad reasoning |
| T2 Local | A2–A4 | document understanding or generation |
| T3 Composite | A3–A4 | several reasoning steps |
| T4 Workflow | A4–A6 | tool use, memory, planning, state |
| T5 Project | A4–A6 + human review | architecture, iteration, correctness checks |
| T6 Organization | A6 + governance | monitoring, permissions, auditability, fallbacks |
The failure modes on either side are predictable:
Small task + big model = convenient but expensive.
Big task + small model = brittle.
Big task + big model, no tools = impressive but incomplete.
Big task + model + tools + memory + evals = an actual AI system.Read the pairing off the axes, not the vibe. T0 and T1 want rules or a tiny classifier, and sending them to a frontier model is latency and cost you’ll pay on every call for judgment you didn’t need. T2 and T3 are the home of small-to-large models with retrieval bolted on. Only T4 and up justify the full agent stack.
The catalog: pick the mechanism
Size tells you how big to go. It doesn’t tell you what kind of machine to build. “AI” covers a fraud threshold, a rules engine, a boosted classifier, a vector index, a language model, and a browser agent, and those fail differently, cost differently, explain themselves differently, and need different upkeep. Pick the mechanism from the shape of the task, not from the model you happen to like.
The families run oldest to newest. Most real systems draw from several at once.
Symbolic: specify, don’t learn
When the behavior is already known, write it down. Don’t train a model to rediscover a rule you could state in a line.
| Type | What it is | Reach for it when |
|---|---|---|
| Rule-based system | explicit if/then logic over structured facts | the rule is known, stable, auditable, and creative interpretation would embarrass you |
| Expert system | many rules chained over a knowledge base by an engine | the domain already has formal rules: tax, benefits, underwriting, triage |
| Knowledge graph / ontology | entities and relationships as structured memory | relationships matter more than raw text, or a model needs grounding |
| Search / planning | finds an action sequence from a state to a goal | the question is “what should happen next,” not “what is this” |
| Constraint solver | finds an assignment satisfying hard constraints | the problem is variables plus constraints: scheduling, routing, allocation |
A policy handbook is a set of constraints, not a statistical distribution. Treat it like one.
Learned prediction: labels and numbers
Clean features and a clear label beat prompt engineering. Before fine-tuning a language model, check whether the problem is a tabular prediction wearing a chatbot costume.
| Type | What it is | Reach for it when |
|---|---|---|
| Classification | maps an input to a known class | the answer belongs to a fixed set: spam, intent, defect, risk band |
| Regression | predicts a continuous value | the question is “how much,” and you can return a range, not a false-precise number |
| Trees / gradient boosting | many weak trees combined over tabular data | structured business data with clean features: credit, churn, pricing |
| Ranking | orders candidates by relevance or utility | value comes from ordering options; remember it optimizes what you measure |
| Forecasting | predicts future values from an ordered history | the future still resembles the past enough to matter |
| Recommender | candidate-generation → ranking → filtering pipeline | personalizing abundance; the model is one stage, the system controls the rest |
A ranking model becomes an invisible product manager. Optimize outrage and you get outrage. The organization chooses the metric’s moral shape, not the model.
Structure and uncertainty
Not every task has labels. Some are about seeing shape in data, or reasoning in odds instead of answers.
| Type | What it is | Reach for it when |
|---|---|---|
| Clustering | groups similar items with no labels | you want to discover segments; a cluster is a pattern that still needs a human name |
| Anomaly detection | scores deviation from normal | bad cases are rare and normal is plentiful; emit a review queue, not an irreversible action |
| Probabilistic model | Bayesian nets, Markov/HMM, explicit uncertainty | the decision needs odds and confidence: diagnosis, risk, sensor fusion |
Meaning and retrieval
The invisible layer of most modern systems. These don’t answer; they find.
| Type | What it is | Reach for it when |
|---|---|---|
| Embedding model | maps objects to vectors so similar things sit close | you need semantic similarity: search, dedup, matching, RAG |
| Information retrieval | finds relevant docs for a query, keyword plus vector | the answer already exists in your corpus; find before you generate |
A smaller model with good retrieval beats a bigger model guessing from memory. Bad retrieval makes a frontier model hallucinate with confidence.
Generation and language
Strong where variation is valuable and verification is possible. Risky the moment output is treated as truth.
| Type | What it is | Reach for it when |
|---|---|---|
| Generative model | samples new content from a learned distribution | you want drafts and options you can check: generate, verify, constrain, approve |
| Language model | generates and reasons over text and code | language is the hard part, not enforcing a hard constraint |
| Multimodal model | handles text with image, audio, or video | the decision actually depends on seeing, not just on structured data |
| RAG | retrieval plus generation for grounded answers | the model must answer from your private knowledge |
Most RAG failures are retrieval failures wearing a generation costume: if the system can’t show what it found and how sure it is, it’s a chatbot with a filing cabinet nearby.
Acting over time
Once the system takes actions and gets feedback, you’ve left “pick a model” behind and started designing a loop.
| Type | What it is | Reach for it when |
|---|---|---|
| Reinforcement learning | learns a policy from actions and rewards | the system can explore safely; reward design is the hard, dangerous part |
| Bandit | balances explore/exploit across options | you only need “which option next”: A/B, ad selection, offers |
| Control system | continuously corrects toward a target state | the output is a steering angle or a throttle, not a sentence |
| Robotic system | perception, planning, control, and actuation | the work is physical and the long tail is brutal |
Composite systems
Most production AI lives here: a model wrapped in the boring parts that make it survivable, like identity, permissions, tool contracts, retrieval, evaluation, and rollback. A coding agent is that whole stack with an LLM as one component in it, and usually not the component that breaks.
| Type | What it is | Reach for it when |
|---|---|---|
| Agentic system | model + tools + memory + loop pursuing a goal | the task needs sequencing, tool use, and adaptation; without permissions, audit, rollback, and review it’s a script with a probabilistic intern inside it |
| Multi-agent | several agents cooperating or dividing work | the roles need genuinely different context, tools, or permissions, not one model wearing hats |
| Human-in-the-loop | deliberate approval, correction, or escalation | the decision is high-risk or irreversible; give the human leverage instead of removing them |
| Hybrid | rules + classifier + retrieval + LLM + evaluator | real workflows: split the job and use the right mechanism for each subtask |
A quick lookup
If you know the shape of the task, the starting point is usually obvious.
| Task shape | Start with |
|---|---|
| a hard rule | rule-based system |
| many explicit domain rules | expert system |
| entities and relationships | knowledge graph |
| variables under hard constraints | constraint solver |
| a known class | classification |
| a number | regression |
| tabular business prediction | gradient-boosted trees |
| ordered results | ranking |
| unknown groups | clustering |
| rare, weird cases | anomaly detection |
| future values | forecasting |
| personal suggestions | recommender |
| meaning similarity | embeddings |
| find known facts | retrieval |
| create new content | generative model |
| language-shaped ambiguity | language model |
| mixed text/image/audio/video | multimodal model |
| answer from private knowledge | RAG |
| choose actions with feedback | bandit or reinforcement learning |
| stable behavior over time | control system |
| physical action | robotics stack |
| tool use over multiple steps | agentic system |
| high-risk automation | human-in-the-loop or hybrid |
The winds change direction
There’s a shape to all of this: as task size climbs, the product shifts from model to system. At T0 the model is the product — a classifier ships and that’s the deliverable. At T5 and T6 the workflow is the product, and the model is just the reasoning engine bolted inside it. Most AI systems in the wild are small, and most of the valuable work isn’t frontier work at all. It’s small and medium models wired into workflows that someone bothered to design.
Reaching for the frontier model on everything is the default because it’s the least thinking up front. It also buys the worst repeatability. A frontier model is a moving target: the provider ships a new version, behavior shifts, and a workflow you never touched starts failing in ways you can’t diff. That’s the wind changing. A rule set, a gradient-boosted classifier, a small model you pinned to a version, a plain regex — these fail loudly and predictably, and when requirements move you change one thing on purpose instead of finding drift in production.
So the rule is plain: size the system to the task, pick the type to the task’s shape, and spend the frontier budget only where the task is actually open. A frontier model is very good at absorbing vagueness, which makes it useful at the edge of a system and dangerous at the core. The catalog isn’t a ladder where everything eventually becomes a frontier model. It’s a toolbox. The win isn’t the biggest tool. It’s choosing the tool that fails in a way your system can survive.