The AI words people use at work, in plain English

The AI words people use at work, in plain English

Most AI vocabulary was written by engineers for engineers, then borrowed by everyone else. This is a plain definition of the twenty-four terms that actually come up in work conversations, written for people who use AI every day and do not write code. No analogies to compilers. Each one says what it means and why it costs you something when you get it wrong.

What the model is working with#

Context window. The total amount of text a model can hold in mind at once, counting everything: your instructions, the conversation so far, and any files you attached. When it fills up, the oldest material stops influencing the answer. This is the single most common cause of a model "forgetting" something you said.

Token. The unit models count in, roughly three quarters of a word in English. Context windows and pricing are both measured in tokens, which is why a long document costs more than a short question.

System prompt. The standing instruction sitting above your conversation, setting behaviour before you type anything. In consumer tools this is called custom instructions or personal preferences.

Project instructions. A standing instruction attached to one workspace rather than to you. Useful because your rules for a client project are not your rules for everything.

Temperature. How much randomness the model uses when choosing each next word. Lower means more repeatable, higher means more varied. Most consumer tools do not expose it, which is part of why the same prompt can produce different answers.

Structured output. Asking the model to answer in a fixed shape, such as a table with named columns, so the result can go straight into another tool without a person tidying it.

What you build around it#

Grounding. Giving the model the actual source material instead of relying on what it absorbed in training. An ungrounded answer is the model's memory of the internet. A grounded answer is your document.

Retrieval. The step that fetches the right source material before the model answers. When people say RAG they mean retrieval plus generation, which is this and then the answer.

Context store. The organised set of material about your work that you feed a model repeatedly: how you write, what your product does, what you decided last quarter. The thing most people mean when they say they wish it "just knew."

Examples. Two or three finished pieces of work shown to the model so it can match the pattern. Sometimes called few-shot. Usually more effective than another paragraph of description.

Agent. A model given tools and permission to take several steps on its own, rather than answering once. The difference is that it acts between your instruction and its result.

Sub-agent. A second agent doing one piece of the work for the first. Useful for parallel work, and the place where two processes quietly write over each other.

Tool call. The moment a model stops writing and uses something: a search, a calculator, your calendar. Most failures blamed on the model are really a tool returning something unexpected.

MCP. A shared standard for connecting a model to your own tools and files, so you are not rebuilding the plumbing per app. Worth knowing the name because it is how "let it read my folder" gets set up.

Fine-tuning. Retraining a model on your own examples so the behaviour is baked in rather than instructed. Rarely the right first move. Better instructions and better examples usually get there for a fraction of the effort.

What goes wrong, named precisely#

Hallucination. Stating something false with the same confidence as something true. Not a malfunction. It is what a system optimised to produce plausible text does when it lacks the fact.

Sycophancy. Agreeing with you because you pushed, rather than because you were right. It looks like helpfulness and it is the reason a model is a poor second opinion unless you build against it.

Drift. A setup that worked in March quietly producing worse results in June, because the model changed underneath it, or the inputs did. Nothing announces this.

Prompt injection. Instructions hidden inside content the model reads, such as a web page or an email, that the model then follows. This is the reason "summarise my inbox" is not the harmless request it sounds like.

Model version. The specific dated release you are talking to. Two people using "the same tool" can get different answers, and a workflow can change behaviour without anyone touching it.

What people say when they mean something specific#

Eval. A repeatable test of whether output is good enough, run against known examples. In plain terms: a way to tell whether a change helped, instead of guessing.

Rubric. The written standard an eval judges against. If you cannot write the rubric, you do not yet know what finished looks like, and neither does the model.

Guardrail. A rule or check that catches bad output before it goes anywhere. A guardrail nobody tested is a guardrail that agrees with everything.

Reasoning. The model working through steps before answering. Better on genuinely multi-step problems, slower and more expensive, and it does not make a wrong fact right.

Which of these actually matters to you#

Most people need four. Context window explains most forgetting. Grounding explains most wrong answers. Drift explains why the thing that worked stopped working. Rubric explains why nobody can agree whether the output is good.

The rest are worth recognising in a meeting. Only those four change what you do on a Tuesday.

Here is a check worth running against a workflow you already rely on.

I am going to describe a workflow I use regularly. Ask me one question at a time until you can answer all four of these about it, then give me your answers:
1. What source material is this grounded in, and what is it guessing from?
2. Where in this does the context window fill up, and what falls out first?
3. What would tell me this had drifted, and how long before I noticed?
4. What is the written standard for "good enough" here?
Start by asking me to describe the workflow.

When the vocabulary is not the problem#

Knowing the words helps you name what went wrong. It does not tell you which of the four is actually broken in your setup, and that is the part that takes someone looking at the specific thing you built.

Ahead pairs you with an expert operator who works on your own setup with you, in your own tools. If you ran that check and did not like your answers, that is a good first hour.