AI Term Map

Terms are not a scattered list. Each one lives at a stage of a single call — find the stage and you have its scope and its pitfalls.

The number of terms is not a sign that the subject is complicated — each one attaches to some stage of a single call. Follow the four stages through once and most words settle into position on their own: identify which stage a term belongs to, and you can already tell how far it reaches and where it tends to go wrong.

After reading, you should be able to answer:

• What are the four stages of one call, and which stage does each common term sit on?
• Which six pairs of terms sound like the same thing but are not?
• When someone uses a term you don't know in a meeting, what one question should you ask?

One call is only four stretches of road

Stage one, load the context. The model does not go looking for material. Everything it should know this time is sent by your code in the request: your product's setup and rules (the system prompt), what has been said before (the conversation history), relevant passages pulled from your document store (retrieval, which is RAG), and the sentence the user just typed. Those go into a box with an upper bound — the context window — measured in tokens.

This is the stage you own. All four of those are things you chose to put in, so they are all within your control. The price is that the box fills: overflow it and content gets truncated or compacted, and whatever was dropped is genuinely invisible to the model — nor will it mention the loss.

Stage two, the model computes. It does exactly one thing: work out the most likely next token, sample one, append it, recompute from the start. There are very few knobs you can turn here — temperature is one. Parameter count, capability ceiling, and how much it knows were locked in at the moment of training.

Stage three, it emits text. Note that this is generated on the spot, not looked up from some store — the most fundamental difference from a search engine. The generation mechanism is why, where it does not know, it fills with the most plausible content in the same confident tone — that is hallucination — and also why it does not know what happened after its training corpus ends.

Stage four, it wants to act. Talking is not enough. Put a set of tool descriptions into stage one and it can emit "call this tool with these arguments," which your code executes and feeds back into stage one for it to continue.

The key is that return path: every turn recomputes the first three stages. The context keeps growing, and each round resends and rebills everything before it. The reason an agent is slow and costly comes down to that line, and it is also why the savings are in controlling context length rather than in picking a cheaper model.

Terms on the same stage share the same nature

Sort the common terms by where they land and each pile turns out to have a character of its own. Know the character of a pile and you have learned several words at once, along with their pitfalls.

The terms on stage one are prompt, system prompt, context window, embeddings, RAG, compaction, long-term memory. What they share is that you decide them inside this request, so they are all yours to change.

This pile's most common error is assuming it will remember on its own. Embeddings only turn meaning into coordinates whose distances can be measured; they compute "similar," not "correct." Compaction saves money and loses detail, and what gets lost is often exactly the constraint agreed at the start. Long-term memory is your system storing and re-injecting things for it; it has no memory of its own.

There is also the lost-in-the-middle effect: once context gets long, the start and the end stay clear while the middle gets skipped. The fix is direct — put binding instructions first or last, not buried among the material.

The terms on stage two are next-token prediction, training versus inference, training data, parameter count, temperature, reasoning models, open versus closed. What they share is that they were either fixed at training or are a knob for this call only.

This pile's most common error is reaching for a setting to solve a capability problem: what is not in the corpus cannot be asked out of it by turning temperature to zero. Parameter count only describes size and has nothing to do with context length. A reasoning model writes a stretch of thinking before answering, more accurate on hard problems, but that thinking is billed as output. And training and inference are two separate bills, Training and Inference, and you pay entirely on the inference side.

The terms on stage three are hallucination, knowledge cutoff, multimodality. What they share is that they all speak to whether what came out can be trusted. There is no switch to turn any of them off. Hallucination is a product of the mechanism and can only be blocked from outside. A knowledge cutoff means any "latest" information has to be fed in by you. Multimodality is a capability added on later, reading images by cutting them into tokens, and small print, table rules, and exact coordinates are its high-failure zones.

The terms on stage four are agent, tool calling, the agent loop, Skill, MCP, multi-agent, prompt injection, API versus web app. What they share is that none of them are mechanisms inside the model; they are the layer around it.

This pile is judged by how much authority you have handed out. The tools given decide where its capability boundary sits. Multi-agent is steadier at the cost of duplicating the context several times. Prompt injection is an instruction hidden in material it read, which it then followed; instructions in a prompt cannot patch that hole, because it cannot tell instruction from data. A third-party MCP should be reviewed as granting permissions. And an API and a web app differ in data retention, available parameters, and billing, so settle which one you mean before discussing compliance.

Put the four piles side by side and you have a self-check order: meet an unclear term and do not hunt for a definition first — ask which stage it sits on.

Six pairs that sound alike

Memorising definitions will not help. What actually breaks your judgment in meetings is these six pairs — they sound like the same thing and are not. And the ways they get mixed up come in just three kinds.

The first kind: taking different numbers for the same ruler.

"A token is not a character." The split is decided by the model from its own statistics, so there is no fixed ratio between characters and tokens: in the same batch of text, the parts mixing English with code come out in finer pieces, while solid prose comes through in larger, even blocks.

So "this document is thirty thousand words" tells you nothing dependable about what it will cost, and billing, window length, and rate limits are all denominated in tokens. To estimate, run a real sample through the splitter and read the number.

"Parameter count is not context length." One describes how big the model is, the other how much it can read at once. They are unrelated and pair up in any combination, and model selection is where they get conflated most.

The second kind: taking different layers of remedy for the same layer.

"Fine-tuning is not feeding documents." Fine-tuning changes how it speaks; training costs money and samples, and new facts cannot be taught into it.

Teams have taken the scripts a support desk had accumulated and fine-tuned on the whole batch, only to find that the same question phrased differently still got nothing back: what it learned was tone and phrasing, not the knowledge in those scripts. To make content like your company policies usable to it, the correct answer is nearly always RAG — retrieve the relevant documents first, then place them into stage one. This is the costliest of the six to get wrong.

"An agent is not a smarter model." An agent is the layer around the model, where loop, tools, permissions, and stopping conditions live. Given the same model, a good outer loop gets work done and a bad one goes in circles: call the same tool three times running, get the same result each time, and keep calling it. That is not a dull model, that is a loop with no stopping condition written into it.

The third kind: taking two complementary things for one thing.

"A Skill is not MCP." A Skill is a packaged bundle of knowledge and workflow, loaded only when needed, and it addresses "I keep having to explain this again." MCP is an interface protocol that lets an agent reach external systems, and it addresses "how do I hook up your database and third-party services." The first carries knowledge, the second carries interfaces; neither substitutes for the other.

"Open source is not free." What gets published is usually the weights alone; training data and training code generally do not. You can download and run it, but deployment, scaling, monitoring, and keeping up when the model is updated are all yours. Total it up and self-hosting at small scale usually costs more than calling an API. What it buys is control: data stays in-house, and the model will not be taken down or repriced out from under you.

What to ask in the meeting

One more thing needs saying: these boundaries are genuinely not standard across the industry. The same word "agent" means one thing to a vendor, another to an engineer, yet another in a news article. Some apply it to any tool-enabled chat window; others hold that it must run dozens of rounds before the name fits. Vendors' own published glossaries bear this out: concepts do not line up exactly from one provider to the next. claude-glossary

So what works is not memorising definitions — it is asking in the meeting: "Which step do you mean, specifically?" Have the other person place it on one of the four stages. Most misunderstandings dissolve right there, because once it lands on a stage, its boundaries, its cost, and its risks all become askable. Conversely, if they cannot say either, that usually means the word has not been attached to any concrete step in their own head — which is itself worth knowing.

What this chapter leaves you with

The five articles in this chapter are five faces of one machine. It is only guessing the next token, so it is not a search engine. It is fed once and billed every time, so nearly everything you can change is on the calling side. It reads images by cutting them into tokens too, so accuracy-critical work does not belong to it. And six different machines hide under one name, so their costs must be estimated separately.

Put together, that is one judgment: it is capable and unreliable at the same time, and that is not a contradiction but two faces of one mechanism. So your work splits in two — use its capability to the full, and keep its unreliability out of your product. The first half is selection and organisation; the second half is retrieval, verification, and permissions.

The vocabulary layer ends here too. Look back and every term turns out to be routing around the same fact: it only continues, and continuing fluently is not the same as being right. Know which constraint a word routes around and you need not memorise its definition.

From here, two directions. To decide whether something should go to it at all, and how much of it, Do You Need an Agent at All starts from the bottom rung of the complexity ladder. To let it know what was never in its corpus, RAG: Retrieve Then Answer runs from building the index to assembling the context. Neither path is inside the model — the model layer ends here, and everything after it is systems work.