AI Isn't Just ChatGPT, Claude, Gemini — Here's the Rest of the Map

For most people, artificial intelligence is a chatbot. This is just a narrow definition for a diverse set of technology, which fails in its own unique way, and whose behavior depends entirely on the context provided to it.

A relative asked me at dinner a little while ago what it is that I do for a living. "I'm working on building AI systems," I said, only to be met with an immediate follow-up question of "Oh, like ChatGPT?" and the conversation moving right along. I get that all the time. When you talk about AI, the first thing that comes to mind is chatbot, usually ChatGPT, but Claude or Gemini from time to time if you're following tech news. Nobody is wrong here. It's just the easiest solution to a much larger problem.

ChatGPT, Claude, and Gemini are LLMs — next-token predictors trained on enormous text corpora. Impressive engineering, but a single branch of a tree that's been growing for decades, whose other branches solve different tasks, are built differently, and fail differently. The rest of the branches are unknown to most people outside of the field because none of them come with a chat window.

Well, there's an approximate representation of that tree, along with a representation of where this model we all call "AI" fits in it. The only disclaimer before we get into the list is the following: the categories in this list represent different stuff, as some of them deal with the output of the model while others deal with its learning process, therefore the list is not entirely disjointed. But still, this is approximately how I would represent the major types of AI models to somebody:

The mix-up is harmless at dinner. In an engineering org it's expensive: the four major types of AI models fail in four incompatible ways, and if you debug one as if it were another you reach for the wrong instrument. This post maps the branches by their failure signatures — and argues that the failures collapse into a single root cause the taxonomy can't show you on its own: context.

Generative AI

This is the type of AI model that everyone has encountered before. A generative model learns how to generate something based on patterns from an enormous amount of data, such that it creates new examples according to the learned patterns; a new paragraph, an image, a portion of music that was not asked verbatim but fits into place nonetheless. This is where you will find ChatGPT, Claude, Gemini, and image generating software such as Midjourney.

Failure comes from the function itself. The model will generate fluent, confident, and entirely incorrect content, because there is no set "answer" for it to verify itself against. This is called hallucination, and it happens because of what open-ended generation actually is: at the token level the model is sampling from a fixed vocabulary, but at the level of ideas and claims there is no pre-verified answer key it's selecting from — it is composing something new each time, and there is no ground truth to check the composition against. For a closer look at why this variance is a property of the system rather than a bug you can patch out, see Deterministic Behavior in LLM Pipelines.

In production, this failure is caught the same way it's created — the model doesn't know when it's guessing, so something else in the pipeline has to check. Retrieval-augmented generation narrows what the model can draw on, evals score outputs against a rubric or reference set, and grounding forces claims back to a citable source. None of this makes hallucination disappear; it lowers the odds that one reaches a user unflagged. The trade-off is real: grounding a response too tightly to retrieved passages can make it stilted or force it to surface a source that answers a slightly different question than the one asked — over-grounding trades hallucination risk for a different failure mode, not a clean win.

Discriminative AI

But here's the one that doesn't get the chatbot press. Discriminative models don't make things; they discriminate. From any input data, the best fitting label is chosen out of some pre-defined list by the model: whether the thing is spam, fraud, a real image, or a fake one. The bank's fraud detector, the medical imaging triage, the spam filter that's been quietly at work for two decades – all discriminative models.

I learned this distinction on my own project. SynthScan, a platform I built to detect AI-generated images, uses a Swin Transformer to decide whether a photo is real or synthetic. Someone once described it to me as "generative AI." It isn't — it's discriminative. It's not creating anything; it's making a yes-or-no call on something that already exists. The mix-up isn't just semantic. A discriminative model fails by misclassifying — a bounded, measurable kind of wrong I can check with a confusion matrix. A generative model fails by hallucinating — an open-ended kind of wrong with no fixed answer to check against. Debug one assuming it's the other, and I'd be solving the wrong problem with the wrong tools.

The corresponding production check is a confusion matrix, not a vibe check: false positives and false negatives are counted, weighed against the cost of each (a fraud model's false negative is not the same expense as its false positive), and the decision threshold is tuned accordingly. When the input distribution drifts — new fraud patterns, a camera sensor swap — the matrix degrades quietly until someone re-evaluates it.

Predictive AI

The regression counterpart to discriminative classification: instead of choosing a label from a fixed set, it predicts a continuous value — the temperature tomorrow, the revenue next quarter, the likelihood of default on a loan. (Formally both are discriminative; I split them here because they fail and get monitored differently, which is the distinction that matters operationally.) This is the boring kind of AI that has been driving forecasting, pricing, and risk models for years now — thought of most simply as a model-as-function mapping input to output, the same abstraction that underlies the other branches. No one takes pictures of quarterly forecasts and uploads them to the Internet, but it quietly runs pricing, forecasting, and credit risk — domains where the cost of a wrong answer is money, not embarrassment.

The guardrail here is distribution-drift monitoring: track whether the inputs the model sees in production still resemble the inputs it was trained on, and alert when they don't. A model can have excellent backtested accuracy and still be dangerously wrong the month the underlying economy shifts, because backtesting only proves the model fit the past. See Model as Function for more on why this abstraction is useful — and where it breaks down.

Reinforcement Learning

It is different from the other three in the sense that it does not start its learning process from having seen a large set of annotated samples. It starts with acting, receiving rewards or penalties for success or failure and refining the process through thousands or millions of iterations. That is how game-playing systems learned how to defeat world champions in chess and Go and how robots have been taught to walk and pick up things and stand back up if they fall.

RLHF, Reinforcement Learning from Human Feedback, is also, not very noticeably, one of the ways in which language models become aligned in the post-training phase – human annotators rate system responses and the system is updated to prefer good responses. The branches of the tree are not as distinct from each other as they appear to be.

What's unique about the failure mode is the nature of how the reward function is fulfilled in a way that fails to meet what I want, but meets all the requirements needed, through a loophole the algorithm finds that no one could have anticipated blocking. The mistake isn't one made through being inaccurate like a classification or a hallucination.

Catching a reward hack before it ships means red-teaming the reward function itself — deliberately hunting for the loophole rather than waiting for a user to find it — and reward-shaping to close it once found. This is iterative and adversarial by nature; a reward function is rarely correct on the first try.

The Fifth Variable: Context

All of the model types mentioned above have one thing in common: they know nothing that wasn't told to them. Generative models, in particular, rely solely on the context – the prompt, the instructions, the chat history, the files pasted into the input – to understand what you want from them. They do not know what you mean. They only know what you say.

Take Obsession, the 2026 horror film directed by Curry Barker. Bear, a music store employee, buys a supernatural charm called a One-Wish-Willow and uses it to wish that his co-worker Nikki would love him "more than anyone else in the world." The wish is granted exactly as worded: Nikki's devotion curdles into obsession, hallucination, and violence, and Bear learns there's no way to undo the spell short of dying himself. Barker has said the premise grew out of the "Treehouse of Horror" riff on the classic monkey's-paw story, where wishes are granted to the letter and nothing else. That's the same mechanism at work here: the wish is fulfilled precisely as stated, and the gap between what was said and what was meant is where everything goes wrong. This is the problem with AI systems failing in their operation – the gap between what they are told and what they are supposed to infer from what they are told.

This happens in every class of models, but just with other terminology. It's reward hacking in RL, prompt drift or context collapse in LLMs, and training distribution mismatch in discriminative models. The terminology varies, but the fundamental issue remains: the model did its best optimization on what was asked of it, and that was not quite right.

This is how it works:

• Ambiguity in the context leads to a wrong, but plausible result. If you ask an LLM for a code review and say "clean this up" without specifying what exactly "cleaning up" entails – whether readability, performance, or brevity – you'll receive any one of those, and the choice will be made by the model, not by you.
• Context not found is made up through the priors of the model. If you have a forecasting model based on data from before 2020 on past sales, and you use it to predict next quarter's sales, there's no way for the model to know the world has changed. It will still return a number — a confidently precise one — and nothing in the output tells you it's built on a stale distribution.
• Conflicting context leads to unpredictable output. You plug in a 40-page requirements document into your LLM and ask for the main risks. If those requirements contain contradictions, which all real-world requirements documents contain, the LLM will gloss over those contradictions. You will receive a clear-cut answer about something that isn't clear-cut.

Lastly, there is one more limitation to be mentioned: the context window. All models have a certain window size of text that they can process at once — a fixed property of the model's architecture, not of your subscription tier, though cheaper tiers and smaller self-hosted models do tend to ship with smaller windows (see our handbook on running local LLMs). When a conversation exceeds that window, the application around the model decides what happens next: truncate the oldest turns, summarize them, or throw an error. Many chat products choose to truncate silently — the model doesn't announce what it dropped, and the interface often doesn't either. It only works with whatever survives that cut: your previous conversation, the document you pasted, the initial instructions, whatever didn't make it through. For the mechanics of how that budget is actually spent, see Token Caching and Context Windows.

This is why it might seem that in the middle of the conversation with an LLM the model suddenly "forgot" something that you said to it an hour ago.

Context Engineering as a Discipline

The fix is rarely a bigger model; it's treating context as an engineered input with the same rigor you'd apply to any interface contract.

• Specify the negative space. An underspecified instruction has multiple plausible-but-wrong satisfying interpretations; each constraint you add (no discounting language, assume prior product exposure) collapses that space. Constraints are the spec, not decoration.
• Order for the token budget. Under a bounded window, position is priority — the middle and tail are what truncation eats first, so load-bearing instructions go first.
• Treat long sessions as stateless. When outputs drift from earlier turns, assume the window has advanced past them; re-materialize load-bearing constraints rather than trusting recall.
• Separate context, constraint, and task. Present them as three labeled blocks, not one prose blob — the same discipline you'd want in any well-formed request contract.

Back to the Dinner Table

And thus, the next time when someone will ask me if I work with models like ChatGPT, my honest answer will be: yes, this is a generative model. But on the very same day, I can also check how discriminative classifiers make decisions concerning the authenticity of images or look through forecasts generated by some predictive model about next month. These are three different approaches, three different uses, and three different possible mistakes — all of them in the form of three identical letters.

And in each of these three cases, there is the same implicit variable — the context. It is something that no taxonomy of model types can reflect since it is not a property of the model but rather a property of the discussion that takes place around it. The model will always execute the deal according to the terms that were set up before.

Understanding which exact type of model I am dealing with is the first important question I need to ask myself. And knowing what exactly I have given to work with is the second one.