# Anatomy of AI > The whole site as one document. An interactive explanation of the machine behind the phrase "AI": how a large language model is built, how it is run, and what the ordinary software around it does. Written from first principles for someone with no background. Source: https://www.agenticprosperity.com/ The subject is one machine, not the field. This is the system built around a large language model: the parts that make one, the parts that run one, and the ordinary software that surrounds both. Every figure below states whether it was measured or asserted, and the interactions on the site compute their numbers in the browser rather than calling an API. ## How it is organised The machine is described in five stages: 1. **Build.** Text becomes a file of numbers. Runs once, long before you arrive. Parts: The corpus, Tokens, Embeddings, Parameters, Training, Post-training, The weights, Scale. 2. **Assemble.** Everything the model will see is gathered into one string. Parts: Interfaces, Markdown files, The prompt, Retrieval, Memory, Tools, The stores. 3. **Run.** The file is run over the context, producing one token. Parts: The context window, The forward pass, Attention, Sampling, Reasoning, Cost and latency. 4. **Loop.** A program repeats the whole thing, deciding what goes back in. Parts: Agents, Context engineering, Context sharding, Orchestration. 5. **Constrain.** What measures the output, and what limits what it can do. Parts: Evaluation, Guardrails. Three separate graphs describe the same subject, and they disagree on purpose. The learning graph orders the parts by what you must understand first. The dataflow graph orders them by what moves between them at runtime. The stage graph groups them by when they happen. Training depends on the weights in one and produces them in another; both are true, and they answer different questions. # The parts ## What we mean by "AI" here "AI" now labels a dozen unrelated machines. This one is ours **The problem.** The word "AI" is applied to spam filters, chess programs, image generators, self-driving cars and chatbots at once. Nothing accurate can be said about all of them together. This site explains one machine: the system built around a large language model. It has two halves, and confusing them causes most misunderstanding. First the model is made. Text is collected, turned into numbers, and used to adjust an enormous set of values until it predicts text well. That produces a fixed file. Second, that file is run: given text, it produces more text, one piece at a time. Everything else here, the tools and agents and memory, is scaffolding built around the second half. **Not this.** Not every automated system is this. Image generation, robotics and classical statistics are different machines with different physics. **Numbers.** - 2: halves: built once, then run - 1: file at the centre of all of it **In depth.** The boundary is worth drawing precisely. Multimodal models extend this same architecture to images and audio by tokenizing those too, so the mechanism generalizes even though the explanations here do not, and they are named and set aside rather than covered. Classical machine learning, meaning regression and trees and clustering, shares the idea of fitting a function to data but not the architecture, and almost nothing said here transfers to it. Rule-based systems, which is what "AI" meant for several decades, share neither. What genuinely unites everything on this site is a single sentence: a fixed function, learned from data, applied to a sequence. If a system does not fit that description, this site is not about it, and reasoning about it from what you read here will lead you wrong. **What you can do with it here.** What this site covers, and what it deliberately sets aside. *Provenance: A boundary drawn by the authors, not a taxonomy anyone else maintains.* ## The corpus Text, gathered at a scale no person could read *Stage: Build.* **The problem.** A new model has no experience of anything. Everything it will ever be able to do has to arrive as text, before it exists. Training data is an enormous collection of text: web pages, books, code, transcripts. It is collected, then filtered and deduplicated hard. It is not stored inside the finished model, and the model cannot look anything up in it afterwards. The data’s only job is to be predicted, over and over, while the model’s numbers are adjusted. What remains is a statistical residue of which words follow which, in what structures, under what conditions. What gets thrown away shapes the result as much as what is kept. **Not this.** The model does not contain the data and cannot retrieve a document from it. Nothing is stored; something is absorbed. **Numbers.** - ~1.5: tokens per English word - 20–50%: of raw web crawl removed as duplicates **In depth.** Composition matters as much as scale. Code in the mix improves reasoning on tasks that are not code, and a small fraction of carefully curated text can outweigh a large fraction of crawl. The filtering stack usually runs language identification, then deduplication (exact first, then near-duplicate), then quality classification, then safety filtering, then decontamination against known benchmarks. Ordering effects are real but poorly understood. Two consequences travel with the model for the rest of its life. There is a knowledge cutoff: nothing after the collection date exists to it. And there is inherited distribution: whose writing is over-represented in the corpus becomes whose assumptions are over-represented in the output. Neither can be fixed afterwards by prompting. Licensing and consent are unresolved and actively litigated. That is an open question rather than a settled practice, and this site does not pretend otherwise. **Where the field disagrees.** Whether data quality or sheer quantity dominates at frontier scale is contested, and the labs that know publish little. **What you can do with it here.** Toggle a filter. Watch what survives, and what it cost. **Sources.** - [Common Crawl](https://commoncrawl.org/) ## Tokens Text cut into pieces a machine can count *Stage: Build.* **The problem.** Computers do arithmetic. They cannot do arithmetic on letters. Something has to turn text into numbers before anything else can happen. A tokenizer cuts text into tokens, which are chunks of characters that appeared often in the training data, and gives each one an ID. Common words become a single token. Rare words split into several pieces. The vocabulary is fixed when the model is built and never changes. From here on the model never sees your text. It sees a list of integers. Everything measured about these systems, including cost, context limits and speed, is counted in tokens rather than words. **Not this.** Tokens are not words and not syllables. They are whatever chunks were statistically efficient to store. **Numbers.** - ~1.5: tokens per English word - ~4: characters per token in English - 100k: entries in this tokenizer's vocabulary **In depth.** The standard method is byte-pair encoding. Start from individual bytes, repeatedly merge the most frequent adjacent pair, and stop at the target vocabulary size. The merges are learned from the training data, so the vocabulary reflects what that data contained. A few consequences show up constantly. Leading spaces are usually part of the token, so " the" and "the" have different IDs, which is why a stray space in a prompt can change the output. Numbers fragment unpredictably, and the model never sees the digits as a quantity, which contributes to arithmetic errors. Languages that were under-represented in training cost two to three times more tokens per word, so they are literally more expensive to use and they fill the context window faster. Character-level tasks like counting letters or reversing a string are hard for the same reason: the model never sees characters at all. Tokenization is also a reliability surface. Unusual byte sequences produce tokens the model saw almost never during training, and behaviour on those is poorly characterised. **Trade-offs.** - A larger vocabulary means fewer tokens per document, but a larger embedding table and more parameters spent on rare entries. - Byte-level fallback guarantees any input can be encoded, at the cost of very long sequences for unusual text. **What you can do with it here.** Type anything. The count is what you are billed and limited by. **Sources.** - [Sennrich et al., Neural Machine Translation of Rare Words with Subword Units (2016)](https://arxiv.org/abs/1508.07909) - [OpenAI, tiktoken](https://github.com/openai/tiktoken) ## Embeddings Meaning stored as position in space *Stage: Build.* **The problem.** An ID is arbitrary. Token 4021 is not "more" than token 4020. The model needs a representation where similarity actually means something. Each token ID is swapped for a list of numbers, a vector, which acts as a coordinate in a space of thousands of dimensions. Those positions are learned during training, so tokens used in similar ways end up near one another. Direction carries meaning too: the offset separating one related pair often separates another. All of the model’s later arithmetic happens in this space. What the model has instead of definitions is geometry: nearness, direction and distance. **Not this.** Positions are not assigned from a dictionary. They are learned from usage and contain no definitions. **Numbers.** - 1k–10k: dimensions per vector - ~400M: numbers to store a 100k vocabulary at 4,096 dimensions **In depth.** The initial embedding is context-free. One vector per token ID, identical every time. Context is added by the layers above, so by the final layer the representation of "bank" in a river sentence differs from "bank" in a finance sentence. That distinction between static input embeddings and contextual hidden states causes most of the confusion when people talk about "the embedding" of a word. Similarity is measured by cosine, the angle between two vectors, rather than by straight-line distance. Magnitude tends to encode frequency rather than meaning, so ignoring it is deliberate. The famous analogy arithmetic works partially and unevenly. It is a real property of the space and it gets oversold: the nearest result is often the input word itself, which is why demonstrations quietly exclude it. The same idea scales up from tokens to whole passages, which is what makes retrieval possible later on. **What you can do with it here.** Two dimensions standing in for several thousand. *Provenance: Real word vectors, projected to 2D. Captured at build time.* **Sources.** - [Mikolov et al., Efficient Estimation of Word Representations (2013)](https://arxiv.org/abs/1301.3781) ## Parameters The adjustable numbers, and the shape they sit in *Stage: Build.* **The problem.** Coordinates alone produce no answer. Something has to transform them, repeatedly, and that something needs knobs that can be turned. A model is a stack of layers. Each layer multiplies its input by large grids of numbers, adds, and reshapes the result. Those numbers are the parameters. They begin random and mean nothing at all. Training changes them, and only them. Everything the finished model appears to know, whether grammar or facts or style or code, exists as values in these grids. More parameters gives more capacity to hold patterns, and more arithmetic for every token it ever produces. **Not this.** Parameters are not facts, rules or memories. No individual number holds any one thing. **Numbers.** - 10⁹–10¹²: parameters in a modern model - ~140 GB: to store 70 billion parameters at 2 bytes each **In depth.** Each transformer layer has two parts. Attention mixes information between positions, and a feed-forward network transforms each position independently. Most of the parameters sit in the feed-forward blocks: about two thirds in the older designs, and closer to four fifths once grouped-query attention shrank the attention side. That is where most factual association appears to live, distributed across many parameters rather than localised in any one. Precision is a real lever. The same model at 16, 8 or 4 bits per parameter differs in size and speed by multiples, with quality loss that stays small until it suddenly does not. Mixture-of-experts architectures hold many parameters but activate only a fraction for each token. That decouples storage cost from compute cost, and it makes parameter counts a poor basis for comparing two models. **Where the field disagrees.** Why capability improves so predictably with scale is described empirically and explained poorly. **What you can do with it here.** Change the size. The file and the price per token follow. ## Training Guess, measure the error, nudge every number *Stage: Build.* **The problem.** The parameters begin as random noise. Nobody writes them by hand, because there are too many and no one knows what they should be. They have to be found. Show the model some text with the next piece hidden. It guesses. Compare the guess with what actually came next, and the size of that gap is the loss. Then work backwards through every layer to calculate how much each parameter contributed to the error, and nudge each one slightly in the direction that would have reduced it. Repeat, trillions of times. Nobody specifies what should be learned. Whatever reduces that single number is what gets learned. **Not this.** No facts or rules are programmed in. The only instruction ever given is "predict the next token". **Numbers.** - 1: number being minimized - 0: human-written rules **In depth.** Backpropagation computes the gradient of the loss with respect to every parameter. An optimizer then applies it, scaled by a learning rate, with momentum and adaptive per-parameter scaling. Training runs in batches, and the learning rate follows a schedule that warms up and then decays. Loss falls fast, then logarithmically. The last increments are enormously expensive, which is most of why frontier training runs cost what they do. Capabilities do not appear smoothly. Some tasks sit at chance for a long time and then improve sharply, which makes progress genuinely hard to predict from a loss curve. People watch loss curves obsessively anyway, because a diverging run can waste weeks of compute before anyone notices. The whole process is one optimization problem. It is very large and very expensive, and conceptually it is simple. **What you can do with it here.** Real gradient descent. Turn the rate up and break it. ## Scale More of everything, and what that actually buys *Stage: Build.* **The problem.** Nothing about predicting the next word explains why one model can write code, summarise a contract and argue with you. That generality is the surprising part, and it is not in the mechanism. It came from size. More text, more parameters, more compute, and the same single objective throughout. Loss falls smoothly and predictably as you add all three, which is what makes the enormous runs worth financing. Capability does not. Some tasks sit at chance for a long time and then work, at no threshold anyone can name in advance. Generality was not designed: it is what predicting text well enough turned out to require. **Not this.** Scale is not understanding, and a smooth loss curve is not a roadmap. The thing that improves predictably is not the thing anyone cares about. **Numbers.** - 1: objective, unchanged throughout - 3: things that get turned up: data, parameters, compute - 0: reliable ways to predict a capability before the run **In depth.** Scaling laws relate loss to data, parameters and compute as a power law over many orders of magnitude, and they hold well enough to plan a training run against. The compute-optimal ratio between data and parameters has been revised more than once, which is worth remembering when a current figure is quoted as settled. Emergence is contested rather than mysterious. Part of the sharpness is real and part is an artifact of grading: a task scored pass-or-fail jumps when partial competence crosses the threshold, while the underlying improvement was smooth all along. How much of it is measurement is an open question. The practical consequence is uncomfortable for everyone involved. You can predict what a run will cost and roughly how well it will predict text. You cannot predict what it will be able to do, which means capability is discovered after the money is spent. **Where the field disagrees.** Whether emergent capability is a real discontinuity or an artifact of how it is measured is genuinely unsettled. **What you can do with it here.** Train the small model on more text. Watch what improves, and what does not. ## The weights A file of numbers, and nothing else *Stage: Build.* **The problem.** People say "the model" as though naming an entity. It is worth knowing exactly what the noun points at, because almost every misconception downstream starts here. When training stops, the parameters are frozen and written to disk. That file, a very large array of numbers, is the model. It has no memory, no state, no clock, and it does nothing on its own. Copy it and you have two identical models. It does not change when you talk to it, and it does not change when it is wrong. Anything that resembles learning during a conversation is happening in the text around the model, never in the file. **Not this.** The model does not learn from your conversations. The file is read-only from the moment it ships. **Numbers.** - 1: file - 0: bytes changed by any conversation, ever **In depth.** What ships is a set of tensors, a config describing the architecture, and a tokenizer vocabulary. There is no database, no index and no runtime state. Serving it means loading it into memory and running arithmetic against it. The same file behind an API and on a laptop produces the same distribution given the same input and settings, which is what makes the API a convenience rather than a different machine. Fine-tuning creates a new file, or a small companion file of adjustments called an adapter. It does not edit the original. This is why "the model remembers me" is always wrong, and always describes something else happening outside the file: a transcript being resent, a note being stored, a document being retrieved. Every one of those is a program somebody wrote, and every one of them shows up in the stages that follow. **What you can do with it here.** What changes when you talk to it: the text, never the file. *Provenance: Scale comparison drawn from published corpus and checkpoint sizes.* ## Post-training Why it answers you instead of continuing your sentence *Stage: Build.* **The problem.** A model trained only to continue text does exactly that. Ask a raw one a question and it may cheerfully write five more questions. After pretraining, the model is trained further on examples of the behaviour we want: a request, then a good response. Responses are then ranked against each other, either by people or by another model trained on people’s rankings, and the parameters are adjusted to make preferred responses more likely. This adds almost no knowledge. It changes which of the model’s existing behaviours come to the surface, so it answers rather than continues, declines rather than complies, structures rather than rambles. **Not this.** Post-training does not teach new facts. It reshapes which behaviours the model reaches for first. **Numbers.** - 10¹²: tokens in pretraining - 10⁵–10⁶: examples in post-training **In depth.** There are two stages. Supervised fine-tuning teaches the response format and the assistant role. Preference optimization then adjusts the model toward outputs humans rated higher, historically through a learned reward model and reinforcement learning, and increasingly through direct methods that skip the separate reward model. A third stage trains against verifiable outcomes: did the code run, is the proof valid. That is what produces long deliberate reasoning traces. Post-training is where the personality, the refusal behaviour and the formatting habits come from. It accounts for most of the visible difference between two models built on similar pretraining. It is also fragile. Heavy alignment training can measurably reduce capability on some tasks, and that trade-off is not solved. **What you can do with it here.** Same prompt. One continues it; one answers it. *Provenance: Real captured completions from a base and a post-trained model.* ## The forward pass One token at a time, from a standing start, every time *Stage: Run.* **The problem.** The file does nothing on its own. Something has to run it, and what running it produces is far narrower than most people assume. Give the model a sequence of tokens. It passes them through every layer once and produces a probability for every token in its vocabulary, which is a ranked guess at what comes next. One token is chosen and appended to the sequence. Then the whole thing runs again from the beginning, with the sequence now one token longer. That is the entire operation. A paragraph is that loop, several hundred times, with no plan anywhere except the visible text. **Not this.** It does not draft the sentence first and then write it. There is no hidden plan, only the tokens already on the page. **Numbers.** - 1: full pass per token produced - ~750: passes for a 500-word answer **In depth.** Each pass is deterministic given identical input and settings. All the variation comes from sampling, in the next part. The final layer produces a vector of raw scores over the vocabulary, called logits, which softmax converts to probabilities. Reasoning models exploit this loop rather than escaping it. They are trained to generate many intermediate tokens before the answer, so "thinking" is literally more tokens through the same mechanism. That is why it costs more and takes longer, and why you can watch it happen. The recomputation described above is avoided in practice by caching, but the conceptual model holds exactly. Nothing carries over between passes except the token sequence itself. **What you can do with it here.** The model has no answer. It has a distribution. *Provenance: Real captured logits for three fixed prompts.* ## Sampling and temperature Why the same question gives different answers *Stage: Run.* **The problem.** The model outputs a probability for every possible next token. It never outputs an answer. Something else has to pick one. The simplest rule, always take the most likely token, produces flat repetitive text and identical answers every time. So the token is usually drawn at random, weighted by its probability. Temperature controls how much those odds are flattened. Low temperature concentrates the choice on the top few candidates, and high temperature spreads it across the long tail. Set it high enough and the text drifts into nonsense. This dice roll is the only reason the same question can give different answers. **Not this.** Variation is not the model reconsidering. It is a weighted dice roll over a fixed set of odds. **Numbers.** - 0: temperature that always takes the top token - ~100k: candidates at every single step **In depth.** Temperature divides the logits before softmax. Below 1 it sharpens the distribution, above 1 it flattens it. It is usually combined with truncation. Top-k keeps the k most likely candidates. Top-p, also called nucleus sampling, keeps the smallest set whose probabilities sum to p. Repetition and frequency penalties suppress tokens already used. Low temperature suits extraction, classification and code. Higher suits drafting. Neither is more creative in any sense the machine would recognise. Note that temperature zero still does not guarantee identical output in production. Batching and floating-point non-determinism on GPUs introduce small variations, and those variations compound over a long generation. Deterministic is a setting rather than a promise. **What you can do with it here.** Reshape the odds. Watch the text hold, then break. *Provenance: Real logits, with seeded continuations captured per temperature bucket.* ## Reasoning Thinking out loud is more tokens through the same loop *Stage: Run.* **The problem.** Models that pause and work through a problem look like they are doing something different from models that answer straight away. People reason about them as though a second mechanism had been added. Nothing was added. A reasoning model is trained to produce a long stretch of working before its reply, and that working is ordinary tokens from the ordinary loop. Every one costs what any token costs and takes as long as any token takes. The gain is real on problems where writing intermediate steps helps, because each step lands in the window and the next pass can read it. The model is using its own output as a scratchpad, which is the only memory it has. **Not this.** The visible working is not a window into the computation. It is generated text, and it can be wrong while the answer is right. **Numbers.** - 1: mechanism, the same one as before - 10–100×: more tokens before the answer starts - 0: guarantee the stated reasoning is the actual reasoning **In depth.** This is test-time compute: spending at the moment of answering rather than during training. It buys accuracy on problems with checkable intermediate steps, mathematics and code most clearly, and buys very little on recall or style, where there is nothing to work through. The faithfulness problem is the one worth carrying away. Studies that alter a model’s inputs in ways that change its answer often find the stated reasoning unchanged, still fluent, and no longer describing what happened. A chain of thought is a plausible account rather than a log, which matters enormously if you are relying on it to audit a decision. The scratchpad framing is the most useful one. The model has no state between passes, so the only way to carry a partial result forward is to write it into the window, where the next pass can read it. Thinking out loud is not a metaphor here. It is mechanically the only option available. **What you can do with it here.** The same question, answered directly and worked through. Count the tokens. ## The context window Everything the model can see. There is nothing else. *Stage: Run.* **The problem.** The model keeps nothing between passes. So how does it know what you said thirty seconds ago? It is told, every time. The whole conversation, including standing instructions, your messages, its previous replies, retrieved documents and tool results, is concatenated into a single sequence of tokens and fed in as the input on every turn. That sequence is the context window, and it has a fixed maximum size. Everything the model can take into account is inside it. Nothing outside it exists. When it fills, something has to be dropped, or summarized, or the conversation ends. **Not this.** The model is not remembering you. It is re-reading a transcript that a program rebuilt this turn. **Numbers.** - ~200k: tokens is roughly a 400-page book - 1: rebuild per turn - 0: information carried outside the window **In depth.** Position within the window matters. Information at the very start and the very end is used more reliably than information in the middle, and the effect worsens as the window fills. So a large window is a capacity rather than a guarantee. Filling it degrades accuracy on details while staying technically within limits, which is the most important practical fact about these systems and the reason context engineering exists as a discipline at all. Eviction strategies each lose something different. Dropping the oldest loses early instructions. Summarizing loses detail. Retrieving on demand loses whatever the retriever missed. The loss is silent in every case. The model does not know what was removed and will answer with the same confidence either way. Nothing in the output distinguishes a complete context from a gutted one. **What you can do with it here.** Overfill it. Choose what to drop. Read what you get. *Provenance: Precomputed answers for each eviction path.* ## Attention How each token decides which others matter *Stage: Run.* **The problem.** A long input runs to thousands of tokens, and for any given word almost all of them are irrelevant. Something must decide which ones are not. At every layer, each token compares itself against every earlier token and produces a weight for each one, which is how much to draw from it. It then pulls in a blend of their information, weighted by those scores. Run that across many parallel comparison heads and many stacked layers, and each position gradually accumulates the context it needs: which noun a pronoun refers to, which bracket is still open, which instruction still applies. Attention is how a token finds out what it is about. **Not this.** Attention is not focus, intent or interest. It is a similarity score, computed and applied. **Numbers.** - n²: comparisons for n tokens - 10s: of heads per layer, across dozens of layers **In depth.** Each token is projected into a query, a key and a value. The query is compared against every key by dot product, scaled, and softmaxed into weights, which are then applied to the values. Heads specialise. Some track syntax, some track the subject of the sentence, some attend mostly to the immediately previous token. Nobody assigns that; it emerges from training. The quadratic cost is the central engineering constraint of the field. Doubling input length roughly quadruples the attention work, which is why long context is expensive and why so much research targets cheaper approximations of exactly this operation. Interpretability research reads these patterns to reverse-engineer specific behaviours, with real but partial success. Most heads are not legible, and the ones shown on this site were chosen because they are. **What you can do with it here.** One model, a few legible heads, chosen deliberately. *Provenance: Real attention weights for three sentences, quantized at build time.* **Sources.** - [Vaswani et al., Attention Is All You Need (2017)](https://arxiv.org/abs/1706.03762) ## Cost and latency What you actually pay for, and why it feels slow *Stage: Run.* **The problem.** These systems are metered in a unit nobody has intuitions for, and they feel slow in two different ways that have two different causes. You pay per token in both directions: everything sent in, and everything produced. Because the entire conversation is resent every turn, a long chat costs more each turn even when your message is short. Speed splits the same way. Reading the input happens in one parallel pass, which is fast but grows with length. Writing the output happens one token at a time and is unavoidably sequential. That is why the first word takes a moment and the rest arrives at a steady drip. **Not this.** A long conversation is not free to continue. You re-send all of it, and pay for all of it, every turn. **Numbers.** - 2: prices: input and output, output usually higher - 100: re-sends of the same system prompt in a 100-turn chat **In depth.** Prefill, which is reading the prompt, is compute-bound and parallel. Decode, which is writing the answer, is memory-bandwidth-bound and sequential. That is why output tokens cost more, and why generation speed barely improves on a bigger machine. Two mechanisms make this manageable. The KV cache stores the intermediate keys and values for tokens already processed, so each new token attends to them without recomputation. This is why the naive picture of re-running everything from scratch is conceptually right but not literally how it is served. Prompt caching extends that across requests. An unchanged prefix, such as a system prompt or a long document or a set of tool definitions, can be reused at a large discount. Which gives a concrete rule with real money attached: stable content goes at the start of the context, and volatile content at the end. **What you can do with it here.** Compose a conversation. Watch what it actually costs. ## The prompt and its roles Roles, and the fact that it is all one string *Stage: Assemble.* **The problem.** A chat interface shows tidy bubbles from separate speakers. The model receives no such thing. Before each pass, everything is flattened into a single sequence with markers naming who said what: a system section holding standing instructions, then alternating user and assistant turns, then any tool results. The roles are simply labelled text. Their authority comes from post-training, which taught the model to weight the system section heavily, rather than from any rule the machine enforces. Change what the labels contain and the behaviour changes. There is no privileged channel underneath. **Not this.** Roles are not permissions. Nothing at the level of the machine enforces them. **Numbers.** - 3–4: role types - 1: string - 1: full rebuild every turn **In depth.** The flattening uses a chat template, a set of special tokens marking role boundaries, and the template is specific to each model family. Using the wrong one degrades output noticeably and quietly. Because roles carry no hard authority, text arriving from outside can contain instructions the model may follow. A web page, a document, a tool result: any of them can say "ignore your previous instructions" and land in the same string as the system prompt. That is prompt injection, and it is not a bug waiting to be patched. It is a structural consequence of everything being one string, and it gets handled with permissions rather than with wording. Ordering follows from how caching works. Stable content goes first so it can be reused across requests, and the actual request goes last, where it is attended to most reliably. **What you can do with it here.** Bubbles on the left. The literal string on the right. ## Markdown and the plain-text interface Why plain text became the interface for instructions *Stage: Assemble.* **The problem.** If instructions are just text in the window, they need a format both a person and a model can read without any special tooling in between. Markdown is plain text with a few visible conventions: hashes for headings, dashes for lists, backticks for code. A model reads it directly, because it saw millions of examples during training and learned that the structure carries meaning. A person reads it directly, because it is just text. It needs no application, diffs cleanly in version control, and can be edited anywhere. That is why instructions, project rules, agent briefs and notes all converged on files ending in .md. **Not this.** The file is not configuration the system parses. Its contents are pasted into the window as text. **Numbers.** - 200–2,000: tokens in a typical instructions file - 1: re-send per turn - 0: parsers involved **In depth.** Structure earns its tokens. Headings give the model handles to refer back to, lists reduce ambiguity, and code fences mark regions to be treated verbatim. Frontmatter, a small block of YAML at the top, is a common convention for machine-readable metadata sitting above human-readable prose. It is used to attach names, descriptions and triggers to a file that is otherwise just writing. The real constraint is that every token in an instructions file is paid for on every turn, and competes for attention with everything else in the window. Files that grow to thousands of tokens of rules routinely perform worse than tight ones, which follows directly from how the context window behaves. The format also makes the instructions a durable artifact: version-controlled, reviewable, diffable, and portable between tools. Its main virtue is that it has no lock-in. **What you can do with it here.** Edit the file. Watch the behaviour change, and the bloat cost you. ## Tools and function calling How a text machine acts on the world *Stage: Assemble.* **The problem.** A model can only produce text. It cannot check a price, read a file, run a query or send anything anywhere. You describe some functions to it as text in the window: a name, a purpose, arguments. When the model decides one is needed, it does not run it. It writes a structured request naming the function and its arguments. Your program parses that request, decides whether to allow it, actually runs the code, and pastes the result back into the window as more text. The model then carries on with that result in view. Every capability an AI system has is an ordinary program somebody wrote and chose to expose. **Not this.** The model does not execute anything. It asks. Your code decides, and your code runs. **Numbers.** - 2+: model passes per round trip - 50–500: tokens per tool definition, re-sent every turn **In depth.** Tool definitions are usually JSON Schema, and the model is trained to emit calls that match them. The description in that schema is the only documentation it gets, so description quality drives call quality more than anything else does. A few constraints show up quickly. Too many tools crowd the context and degrade selection: a dozen is comfortable, fifty is not. Tools should be designed around a model’s failure modes rather than mirrored from an internal API, which usually means fewer of them, at a higher level, harder to misuse. Errors should come back as informative text rather than thrown exceptions, so the model can correct itself. Tool results are also where untrusted content enters the window, which makes this the origin of most real security exposure in these systems. **What you can do with it here.** Model asks. Your code decides. The result comes back as text. *Provenance: A real tool round trip, captured and replayed step by step.* ## Retrieval Fetching the right paragraph before answering *Stage: Assemble.* **The problem.** The window is finite and the model’s training stopped at some date. Most of what you actually need was in neither. Cut your documents into passages. Convert each into a vector, the same kind of coordinate as a token embedding but for a whole passage, and store them. When a question arrives, convert it the same way, find the passages nearest to it, and paste those into the window before the model answers. The model is not searching anything. It is handed a few paragraphs by a separate system that ran first, and then reads them like any other text. **Not this.** Retrieval does not give the model knowledge. It puts text in the window, for this one turn. **Numbers.** - 200–800: tokens per passage - 3–20: passages retrieved per query - ms vs s: retrieval time against model time **In depth.** Chunking is the decision that matters most and gets the least attention. Too small and passages lose the context that made them meaningful. Too large and each one spends window on irrelevance. Splitting on document structure beats splitting on character count almost every time. Pure vector search misses exact terms: names, error codes, part numbers. Production systems combine it with keyword search and merge the rankings, then often re-rank the top candidates with a slower, more accurate model. Retrieval quality can be measured on its own, without the model, and it should be. If the right passage was not retrieved, no amount of prompt work will rescue the answer. The failure mode to watch for is confident synthesis from a passage that was plausible and wrong. **What you can do with it here.** Corpus to chunks to neighbours to prompt, in four panes. ## The stores Four kinds of store, and what each is for *Stage: Assemble.* **The problem.** Talk of "the AI’s database" usually covers four different stores doing four different jobs, only one of which is specific to AI at all. A relational database holds structured records and answers exact questions: orders, users, prices, counts. A vector database holds embeddings and answers "what is most similar to this". A key-value store returns things by name, very fast, which suits sessions and caches and prior summaries. A graph store holds relationships and answers what connects to what. None of them is inside the model. They are ordinary infrastructure the surrounding program reads before it assembles the prompt. **Not this.** None of these is the model’s memory. The model only ever sees what the program pastes in. **Numbers.** - ms: for an exact lookup - 10s of ms: for similarity search over millions of vectors - 0: of them inside the model **In depth.** Choosing wrongly is a common and expensive mistake. Similarity search cannot answer "how many orders last Tuesday", and a relational query cannot answer "which support tickets feel like this one". Real systems use several, and the interesting work is routing: deciding which store a question needs. That is often done by giving the model a tool per store and letting it choose. Vector indexes are approximate by design, trading a little recall for a lot of speed. They also need re-embedding whenever the embedding model changes, which is a migration people consistently underestimate. A plain relational database with a vector column is frequently the right answer, and specialised infrastructure is frequently premature. **What you can do with it here.** One question, four stores. Watch three of them fail. *Provenance: Queries and results written by hand against each store type.* ## Interfaces Chat, API, SDK, MCP. The same machine, four doors *Stage: Assemble.* **The problem.** The same model reaches people through several very different-looking doors, which makes it look like several different products with different abilities. A chat window is a program that keeps a transcript and calls an API. The API is an HTTP endpoint that takes the assembled context and returns tokens. An SDK is a library wrapping that endpoint in your language. MCP is a shared convention for exposing tools and data, so any client can connect to any provider without bespoke wiring for each pair. Behind all four sits the same file of weights running the same forward pass. What differs is only who assembles the context. **Not this.** The chat product is not the model. It is a context-assembling program wrapped around one. **Numbers.** - 1: endpoint behind all of them - 4: common doors **In depth.** The chat product does a lot of invisible work: a system prompt you never see, conversation trimming, retrieval, tool wiring, safety filtering. That is exactly why the same model can seem more or less capable depending on where you meet it. Working directly against the API means you own all of that. It is both the cost and the point. MCP matters because it turns an N times M integration problem into N plus M. Tool providers implement one server, clients implement one client, and neither has to know about the other in advance. When people compare models they are almost always comparing whole products. A fair comparison holds the assembled context constant, which is rarer than it sounds and harder than it looks. **What you can do with it here.** Four interfaces, one identical assembled context. ## Agents A model in a loop, with tools and a goal *Stage: Loop.* **The problem.** A single pass answers a question. It cannot carry out a task whose steps are not known in advance. Put the model in a loop. Give it a goal, some tools, and a context. It writes one step. Your program runs the tool it asked for. The result goes back into the window, the model looks at the new state, and writes the next step. Repeat until it declares completion, hits a limit, or fails. The intelligence is in the model. The agency is in the loop, which is a while loop somebody wrote with a stopping condition. That is the whole difference between a chatbot and an agent. **Not this.** An agent is not a persistent being. It is a loop over a stateless model, and it stops. **Numbers.** - 5–50: iterations for a real task - 1: context, re-sent in full every iteration **In depth.** The loop’s design choices are the engineering. What goes in the initial brief, which tools are available, how errors are surfaced, how many iterations are allowed, what counts as done, and what happens on failure. The failure modes are specific and they repeat. Looping on a failing tool. Declaring success without verifying. Drifting from the original goal as the context fills with intermediate noise. Taking a plausible wrong path early and never reconsidering it. The mitigations are unglamorous: hard iteration caps, explicit verification steps, restating the goal late in the context where attention is reliable, and checkpointing so a failed run does not lose everything. Worth noting that autonomy is entirely a property of the loop and its permissions, not of the model. **What you can do with it here.** Step the loop. Watch the window fill up as it goes. *Provenance: A real recorded agent run, captured and replayed.* ## Context engineering Deciding what goes in the window, and what stays out *Stage: Loop.* **The problem.** The window is finite, everything in it costs money and time, and irrelevant content measurably degrades the answer even when there is room to spare. So the real work becomes selection. Which instructions, how much history, which retrieved passages, which tool results, and in what order. Too little and the model lacks something it needed. Too much and the important parts get diluted, cost rises, and accuracy on details buried in the middle falls. Most of the difference between a system that works and one that does not is this selection, rather than the choice of model or the wording of the prompt. **Not this.** This is not prompt phrasing. It is deciding what information exists for the model at all. **Numbers.** - n²: attention cost as length grows - middle: the least reliably used region **In depth.** The working toolkit is short. Put stable content first so caching can reuse it, and the actual request last where attention is reliable. Retrieve on demand instead of preloading. Summarize completed work rather than carrying whole transcripts. Strip tool output down to what is needed instead of pasting raw responses. Restate the goal late. Measure rather than guess. Token counts per component, plus a fixed set of test cases, will show that removing content often improves results. That is counterintuitive enough that people do not believe it until they see it on their own task. The discipline resembles cache management more than it resembles writing. A fixed budget, competing claims on it, and a real cost to every inclusion. **What you can do with it here.** Allocate the window. Including everything is not the best score. ## Context sharding Splitting work so no one context holds it all *Stage: Loop.* **The problem.** Some tasks involve more information than any window can hold, and a long-running agent’s window fills with intermediate clutter regardless. So you split, in one of three ways. Split documents into passages so only the relevant few are ever loaded. Split the task across separate runs, each with its own clean window and a narrow brief, then combine what they return. And when a window fills anyway, compact it: replace a long history with a short summary and carry on. All three are the same move. No single context has to hold everything. The price is coordination, plus whatever the summarizing threw away. **Not this.** Sharding is not parallel thinking. Each shard is a separate run that cannot see any of the others. **Numbers.** - 200×: reduction when a subagent returns 500 tokens after reading 100,000 - 3: mechanisms: chunk, delegate, compact **In depth.** Delegation works when a subtask is genuinely separable and its result compresses well: search something, read a large file, review one dimension. It fails when the work needs shared judgement, because each shard sees only its brief and the coordinator sees only summaries. Compaction has the same shape of failure. Whatever was dropped is dropped silently, and the model afterwards cannot tell that anything is missing, so it answers confidently anyway. A few design rules hold up. Give each shard a brief narrow enough to be answered in isolation. Require structured returns rather than prose, so the coordinator can combine them mechanically. Keep the raw material addressable so a shard can be re-run. And never compact the goal. **What you can do with it here.** One task, two strategies. Each wins once. ## Orchestration Arranging many runs: in sequence, in parallel *Stage: Loop.* **The problem.** One agent in a loop is one worker doing one thing at a time. Some work needs several of them, arranged deliberately. The arrangement is a program, not a conversation. Run steps in sequence when each needs the previous one’s output. Run them in parallel when they are independent, and wait for all of them only if you genuinely need every result before continuing. Pipeline them when many items each pass through the same stages, so nothing waits at a barrier. Send one problem to several runs and have another run judge the answers. Whoever writes the orchestration determines cost, wall-clock time and reliability far more than any prompt does. **Not this.** The agents are not collaborating. They cannot see each other. A program passes messages between them. **Numbers.** - N×: the tokens for parallel fan-out - 0: shared state unless a program provides it **In depth.** A few patterns are worth knowing. Fan-out for independent work. Pipeline for items flowing through stages without a barrier, which is usually the right default because a barrier makes everyone wait for the slowest. Judge panels, which generate several candidates and score them independently, catching errors a single confident run would not. And adversarial verification, where a separate run tries to refute a finding rather than confirm it, which is cheaper and more effective than asking one run to be more careful. Barriers are justified only when a stage genuinely needs every prior result together, such as deduplicating across all findings. Costs compound fast. Five verifiers on twenty findings is a hundred runs, and the tokens are real money. **What you can do with it here.** Same stages, different arrangement. Watch the clock change. ## Memory What persists between runs, and where it lives *Stage: Assemble.* **The problem.** The model is stateless and the window is temporary. Yet a system can appear to remember you across months and machines. Because something outside the model wrote it down. After a session, a program decides what is worth keeping and saves it, to a file or a database or a vector store. Before the next session, it retrieves the relevant pieces and pastes them into the window. That is all memory is: a write step, a store, and a retrieval step, every one of them outside the model. The interesting questions are what to save, when to update it, and what to do when two saved facts contradict each other. **Not this.** Nothing is stored in the model. Memory is a file a program chooses to re-read. **Numbers.** - 3: parts: write, store, retrieve - 0: of it inside the weights **In depth.** The design space splits by what is being stored. Facts about a person are small, high-value, and best kept explicit and editable. Anyone who cannot see or delete what is remembered about them will eventually be surprised unpleasantly. Summaries of past sessions are lossy by construction and go stale. Full transcripts are complete but too large to include, so they need retrieval, which brings back all of retrieval’s failure modes. Two problems recur. Staleness: an outdated fact gets recalled with exactly the same confidence as a current one. Contradiction: two saved items conflict and nothing arbitrates between them. The practical answers are timestamps, explicit supersession rather than silent overwrite, and keeping the store small enough that a person could actually read it. **What you can do with it here.** Watch it write something down, then answer from it six months stale. ## Evaluation and failure How you know it worked, and the ways it fails *Stage: Constrain.* **The problem.** The output reads as fluent whether or not it is correct, and it varies between runs. Eyeballing does not scale and conventional tests do not fit. So you measure. Build a fixed set of cases with known good outcomes and run all of them on every change. Check automatically whatever can be checked: did the code execute, is the number right, does the cited source exist. Use a second model to grade the parts that resist automation, and check that grader against human judgement. Sample real traffic and read it. The failure modes are specific and they repeat: confident fabrication, drifting off task over long runs, and quietly ignoring part of an instruction. **Not this.** A model stating that it is confident tells you nothing. Confidence is a writing style here. **Numbers.** - 50–200: cases in a useful starter set - every: change, not every release **In depth.** Fabrication is not a malfunction. The machine produces the most plausible continuation, and a plausible-sounding false citation is exactly what that objective rewards when the true one is absent from the weights. That reframing matters, because it means the fix is retrieval and verification outside the model rather than better instructions. Model-as-judge works well for relative comparisons and poorly for absolute scores. It carries known biases toward length, toward confident tone, and toward its own outputs. Public benchmarks are contaminated and only loosely predict performance on your task. A small set built from your own real failures is worth more than any leaderboard. Instrument for regression, because changes trade off rather than improve uniformly. The change that fixes one class of failure routinely breaks another. **What you can do with it here.** Change a setting. Watch cases flip in both directions. *Provenance: Pass rates captured from real runs across eighteen configurations.* ## Guardrails and permissions Limits, accountability, and where they belong *Stage: Constrain.* **The problem.** The system takes real actions in the world using a component whose output cannot be guaranteed in advance. So the limits go around it rather than inside it. Give every tool the narrowest permission that still works. Require confirmation for anything irreversible. Validate what the model produces before acting on it, exactly as you would validate input from a stranger, because text arriving from a web page or a document or a tool result can contain instructions and the model cannot reliably tell content from command. Log every action taken. Cap spend and iterations. None of this makes the model safe. It makes the blast radius small. **Not this.** Instructions in a prompt are not a security boundary. They are a request, and requests can be overridden. **Numbers.** - 1: destructive action is enough - 100%: of tool results are untrusted input **In depth.** The controls that actually hold are conventional software controls: scoped credentials, allowlists, read-only defaults, human confirmation on irreversible operations, spend caps, rate limits, sandboxed execution, and a complete audit log. Model-side measures such as refusal training, output classifiers and system-prompt rules reduce how often something goes wrong, but they cannot be relied on, because the attack surface is the same channel as the content. Prompt injection has no general solution. Treating it as an unsolved structural property rather than a bug leads to better architecture: assume any text the model reads may be adversarial, and constrain what it is able to do about it. Accountability follows the same line. The operator who granted the permission is responsible for the action, and "the AI did it" is not a category that exists. **What you can do with it here.** Change the wording: nothing. Change the permission: everything. ## One request, end to end Everything you have just met, working at once **The problem.** Every part has now been examined on its own. None of them is ever used on its own, and a list of parts is not an understanding of a machine. Follow one request all the way through. A sentence is cut into tokens, joined to a system prompt, a memory lookup and three retrieved passages, and assembled into one string. The file runs over that string and produces tokens until it asks for a tool. A program checks the permission, runs it, and pastes the result back as text. The loop turns four more times. An answer arrives, one token at a time. Nothing in that sequence was magic. **Not this.** There is no step in this trace that is not an ordinary program, a file of numbers, or arithmetic. **Numbers.** - 21: steps from your sentence to the answer - 1: file, read and never written - 0: steps that are not ordinary software **In depth.** The same trace is worth reading twice. The first time it is a sequence of components. The second time it is a sequence of decisions somebody made: what to retrieve and how much, what to keep in the window and what to drop, which tools to expose and what to allow them to do, when to stop looping, what to write down for next time. Every one of those decisions is a place the system can fail without anything appearing to go wrong. A stale memory, a retrieval that returned the wrong paragraph, a tool that succeeded and returned something false. In each case the answer still arrives fluent, confident and the right length. That is the whole argument of this site in one sentence. The parts are simple and the failures are not in the parts, they are in the joins, and the joins were written by people. **What you can do with it here.** One request, twenty-one steps, nothing hidden. *Provenance: A representative request, authored step by step. Not a recording of a live system.* # The connection graph What actually moves between the parts at runtime. 27 components, 35 connections, each labelled with what travels along it. - **The corpus to Tokens** carries raw text. The text that was gathered is handed to the tokenizer, which is the first thing to touch it. - **Tokens to Embeddings** carries token ids. Each token's ID number is looked up in a big table, which returns a list of numbers standing for that token. - **Embeddings to Parameters** carries vectors. Those lists of numbers are what the layers of the model actually do arithmetic on. - **Parameters to Training** carries values to adjust. Training exists to change these numbers, so it needs them to start from, however random they are at first. - **The corpus to Training** carries text to predict. The same text is used again, this time as the answer key. Hide the next word, guess it, check the guess. - **Scale to Training** carries how much of everything (governs). How much data, how many parameters and how much compute go into the run. It is the main thing anyone turns up, and the reason these systems changed. - **Training to Post-training** carries a trained file. The long run finishes and you have a model that can continue text but will not answer a question. - **Post-training to The weights** carries the file that ships. After the manners training, the numbers are frozen and written to a file. That file is what you talk to. - **The weights to The forward pass** carries loaded into memory. The file is read off disk once and held in memory, ready to be run. It is never changed again. - **Tokens to The context window** carries the same vocabulary, applied to your text. The vocabulary built during training gets applied to whatever you type. This is why your bill and your limits are both counted in tokens. - **Interfaces to The prompt** carries your request. Whatever you typed, and wherever you typed it, becomes text waiting to be assembled with everything else. - **Markdown files to The prompt** carries standing rules. Instructions you wrote once in a plain text file get pasted in on every single turn, so the model reads them next to your message. Nothing parses that file. It is just text. - **The stores to Retrieval** carries passages. The store is searched and the few most relevant paragraphs come back. - **The stores to Memory** carries saved facts. Things saved about you in an earlier session are read back out of storage. - **The prompt to The context window** carries one flat string. All the pieces are joined into one continuous block of text. The tidy chat bubbles on your screen are not what the model receives. - **Retrieval to The context window** carries passages. The fetched paragraphs are pasted in so the model can read them like any other text. It is not searching anything itself. - **Memory to The context window** carries facts. The saved facts are pasted in too. This is the whole of what people mean when they say it remembers them. - **Tools to The context window** carries tool results. Whatever your code actually ran comes back as plain text and joins everything else. - **The context window to The forward pass** carries the whole sequence. Everything assembled is handed over at once. The model sees this and nothing else. - **The forward pass to Sampling** carries a probability for every token. The model does not choose a word. It scores every possible word and passes the scores along. - **The forward pass to Tools** carries a request to call one. The model can ask for a tool by writing a request for it. It cannot run anything itself. - **Sampling to Reasoning** carries tokens before the answer. A model trained to work things out writes its working first. Those are ordinary tokens, produced by the ordinary loop, and most of them are not the reply. - **Reasoning to The context window** carries the working, appended (loop). Every thinking token goes back into the window like any other, and the next pass reads all of it. That is why it costs more and takes longer. - **Sampling to The context window** carries one token, appended (loop). The chosen word is stuck on the end, and the whole thing runs again from the top. That is one word of the answer. - **Sampling to Interfaces** carries the answer, streaming (loop). Each word is sent to your screen as it is picked, which is why the answer appears to type itself out. - **Memory to The stores** carries what to remember (loop). After the session, a program decides what was worth keeping and writes it down for next time. - **Attention to The forward pass** carries is the mechanism inside it (governs). Attention is not a separate step. It is the mechanism inside the pass that works out which earlier words each word should look at. - **Cost and latency to The context window** carries is what you pay for (governs). What you pay and how long you wait are both set by how much is sitting in the window. - **Context engineering to The context window** carries decides what goes in (governs). Deciding what goes into the window, and what is deliberately left out, is most of the work of building one of these systems. - **Context sharding to The context window** carries splits what will not fit (governs). When there is more information than the window can hold, the work gets split across several separate runs. - **Agents to The forward pass** carries runs it in a loop (governs). An agent is a loop somebody wrote that runs the model over and over, instead of once. - **Agents to Tools** carries chooses and runs them (governs). The same loop decides which tool to run and what to do with whatever comes back. - **Orchestration to Agents** carries arranges many of them (governs). Arranging several of those loops to run one after another, or side by side. - **Evaluation to Sampling** carries measures what comes out (governs). Measuring whether the output is actually right, because fluent and correct are two different things. - **Guardrails to Tools** carries decides what is allowed (governs). Permissions decide what a tool is allowed to do. That, rather than the wording of a prompt, is what reliably stops a mistake. # One request, end to end A single question walked through the whole machine in order. The question is: "I have a few days off in November. Where should I go?" Components repeat, because the machine loops. The context window is touched four times in one turn, and seeing that is most of the point. The token figures are illustrative of a representative request and were not measured from a live system. 1. **Interfaces.** You type the question and press enter. Nothing has happened yet. Adds your question, 18 tokens. Window now 18 tokens. 2. **Markdown files.** Standing rules are read out of a plain text file, to be pasted in as though you had typed them yourself. Adds standing rules from the file, 620 tokens. Window now 638 tokens. 3. **The prompt.** Your question, the rules and the earlier turns are flattened into one string. Adds the system prompt, 240 tokens. Window now 878 tokens. 4. **The stores.** A store of travel writing is searched for anything that looks relevant. This is an ordinary query, run by ordinary code. 5. **Retrieval.** Three passages come back, the ones nearest to what you asked. Adds three retrieved passages, 1450 tokens. Window now 2,328 tokens. 6. **Memory.** Two facts saved about you in an earlier session are pulled in: that you like somewhere warm, and that you went to Lisbon last year. Adds two saved facts, 90 tokens. Window now 2,418 tokens. 7. **The context window.** All of it is joined into one string, along with the list of tools the program is offering. This is everything the model will see. Adds the tool definitions, 310 tokens. Window now 2,728 tokens. 8. **Tokens.** The same vocabulary that built the model is applied to your text, which is why the bill is counted in tokens. 9. **The weights.** The file is already in memory. It does not change, and it will not remember this. 10. **The forward pass.** One pass through every layer. Out comes a probability for every token in the vocabulary. 11. **Attention.** Inside that pass, each token worked out which earlier ones mattered to it. 12. **Sampling.** One token is drawn from those odds. Not the top one, a weighted roll. 13. **The context window.** The token is appended. The window is now exactly one token longer than it was. Adds the word it just chose, 1 tokens. Window now 2,729 tokens. 14. **The forward pass.** It runs again, from the start, over everything. This is pass two of about four hundred. 15. **Tools.** This time the model asks for a tool: look up the November weather for three places. It cannot run it, and it could not know the answer. 16. **Guardrails.** Your code checks whether that is allowed before anything happens. 17. **The context window.** The tool result is pasted back in as more text, indistinguishable from anything else in there. Adds the tool result, as text, 480 tokens. Window now 3,209 tokens. 18. **Agents.** A loop somebody wrote decides whether to go round again or stop. 19. **Sampling.** Hundreds of passes later, a stop token is drawn and the answer is finished. Adds the rest of the answer, one token at a time, 260 tokens. Window now 3,469 tokens. 20. **Memory.** A summary is written down so the next session can start with it. 21. **Interfaces.** The answer streams back to you, one token at a time, which is why it appears to type itself. # Glossary 101 terms, each defined once, in the part of the machine that introduces it. - **Scaling laws**: The observed relationship between how much data, compute and parameters go into a training run and how well the result predicts text. Smooth, and predictive of loss. Not to be confused: They predict the loss, not what the model will be able to do. (introduced by the part: scale) - **Emergence**: A capability that is absent at one scale and present at a larger one, without appearing gradually in between. Not to be confused: Not magic, and not well explained. Partly an artifact of measuring with pass-or-fail tests. (introduced by the part: scale) - **Generality**: The fact that one model trained on one objective can do many unrelated tasks it was never specifically taught. Not to be confused: Not evidence of understanding. It is what predicting text well enough turns out to require. (introduced by the part: scale) - **Chain of thought**: Tokens a model produces working through a problem before giving its answer. Ordinary output, produced by the ordinary loop. Not to be confused: Not a window into the computation. It is text the model generated, and it can be wrong while the answer is right, or the reverse. (introduced by the part: reasoning) - **Test-time compute**: Spending more work at the moment of answering rather than during training, usually by generating more tokens before the reply. Not to be confused: Not a different mechanism. It is the same loop, run for longer. (introduced by the part: reasoning) - **Language model**: A file of numbers that, given a sequence of tokens, produces a probability for every token that could come next. Not to be confused: Not a program with rules in it, and not a search over stored documents. (introduced by the part: what-we-mean) - **Model**: In this site, always the file of weights. Not the chat product, not the company, not the API. Not to be confused: People say "the model" for the whole product. Almost every misconception starts there. (introduced by the part: what-we-mean) - **Inference**: Running the finished file over some text to produce more text. The second of the two halves. Not to be confused: Not learning. Nothing is stored and nothing changes during inference. (introduced by the part: what-we-mean) - **Training**: The one-off process that produced the file, by adjusting its numbers until it predicted text well. Not to be confused: Not something that happens while you talk to it. It finished before you arrived. (introduced by the part: what-we-mean) - **Token**: A chunk of characters with a fixed ID. It is the unit a model actually reads, and the unit you are billed in. Not to be confused: Not a word and not a syllable. (introduced by the part: tokens) - **Tokenizer**: The program that cuts text into tokens and back again, using a vocabulary fixed when the model was built. (introduced by the part: tokens) - **Vocabulary**: The complete fixed set of tokens a model knows, each with an ID. It never changes after training. (introduced by the part: tokens) - **Byte-pair encoding**: The method that builds the vocabulary: start from bytes, repeatedly merge the most frequent adjacent pair, stop at the target size. Not to be confused: Not a compression format, though it began as one. (introduced by the part: tokens) - **Corpus**: The collected text a model is trained on, after filtering and deduplication. Not to be confused: Not a database the model can consult later. It is gone by the time the model runs. (introduced by the part: data) - **Pretraining**: The long first training run, where the only objective is predicting the next token. (introduced by the part: data) - **Deduplication**: Removing repeated and near-repeated documents, typically discarding 20-50% of raw crawl. (introduced by the part: data) - **Knowledge cutoff**: The date the training data was collected. Nothing after it exists to the model. (introduced by the part: data) - **Embedding**: A list of numbers standing for a token or passage, positioned so similar things sit near each other. Not to be confused: A token’s input embedding is fixed; its hidden state at a later layer is not. Both get called “the embedding”. (introduced by the part: embeddings) - **Vector**: An ordered list of numbers treated as a coordinate in a space of many dimensions. (introduced by the part: embeddings) - **Dimension**: One of the thousands of numbers in a vector. Individually they mean nothing readable. (introduced by the part: embeddings) - **Cosine similarity**: How alike two vectors are, measured by the angle between them rather than the distance. (introduced by the part: embeddings) - **Parameter**: One adjustable number inside the model. Training changes these and nothing else. Not to be confused: Not a fact or a rule. No single parameter holds any one thing. (introduced by the part: parameters) - **Layer**: One stage of the stack: attention across positions, then a transform of each position. (introduced by the part: parameters) - **Transformer**: The architecture almost every current language model uses: stacked attention and feed-forward layers. (introduced by the part: parameters) - **Quantization**: Storing parameters at lower precision to shrink the file and speed it up, at some cost to quality. (introduced by the part: parameters) - **Loss**: One number measuring how wrong a prediction was. The entire training process minimises it. (introduced by the part: training) - **Gradient descent**: Nudging every parameter in the direction that would have reduced the loss, over and over. (introduced by the part: training) - **Backpropagation**: Working backwards through the layers to compute how much each parameter contributed to the error. (introduced by the part: training) - **Learning rate**: How large each nudge is. Too small and it crawls; too large and it diverges. (introduced by the part: training) - **Weights**: The frozen parameters written to disk. This file is the model. (introduced by the part: the-weights) - **Checkpoint**: A saved copy of the weights at some point during training. (introduced by the part: the-weights) - **Stateless**: Holding no memory between calls. The model is stateless; the program around it is not. (introduced by the part: the-weights) - **Fine-tuning**: Training an existing model further, producing a new file or a small companion adapter. Not to be confused: Does not edit the original weights, and is not how a chat appears to remember you. (introduced by the part: the-weights) - **Supervised fine-tuning**: Training on examples of requests and good responses, which teaches the assistant format. (introduced by the part: post-training) - **Preference optimization**: Adjusting the model toward responses humans ranked higher. RLHF is one method of doing it. (introduced by the part: post-training) - **Alignment**: The broad term for shaping a model to behave as intended. Mostly happens in post-training. (introduced by the part: post-training) - **Refusal**: Declining a request. A trained behaviour, not a hard rule the machine enforces. (introduced by the part: post-training) - **Forward pass**: One run of the token sequence through every layer, producing one probability distribution. (introduced by the part: forward-pass) - **Logits**: The raw scores over the whole vocabulary, before they are turned into probabilities. (introduced by the part: forward-pass) - **Softmax**: The step that turns raw scores into probabilities summing to one. (introduced by the part: forward-pass) - **Autoregressive**: Producing one token at a time, each conditioned on everything already written. (introduced by the part: forward-pass) - **Temperature**: How much the odds are flattened before a token is drawn. Low concentrates, high spreads. Not to be confused: Not a creativity dial. It reshapes fixed odds; it does not change what the model considered. (introduced by the part: sampling) - **Top-k**: Keeping only the k most likely candidates before drawing one. (introduced by the part: sampling) - **Top-p**: Keeping the smallest set of candidates whose probabilities sum to p. Also called nucleus sampling. (introduced by the part: sampling) - **Greedy decoding**: Always taking the single most likely token. Repetitive, and still not truly deterministic in production. (introduced by the part: sampling) - **Context window**: The single sequence of tokens the model is given each turn, and its maximum size. Not to be confused: Not memory. It is rebuilt from scratch by a program on every turn. (introduced by the part: context-window) - **Eviction**: Removing something from the context to make room. The model is never told what went. (introduced by the part: context-window) - **Lost in the middle**: The measured tendency to use information at the start and end of a long context more reliably than the middle. (introduced by the part: context-window) - **Attention**: The operation where each token weights every earlier token and pulls in a blend of them. Not to be confused: Not focus or intent. It is a similarity score, computed and applied. (introduced by the part: attention) - **Head**: One parallel attention computation. Different heads specialise, and the specialisation is learned. (introduced by the part: attention) - **Query, key, value**: The three projections of each token: what it is looking for, what it offers, and what it passes on. (introduced by the part: attention) - **Quadratic cost**: Attention work grows with the square of the input length, so doubling the input roughly quadruples it. (introduced by the part: attention) - **Prefill**: Reading the prompt. Happens in one parallel pass, and sets the time to the first word. (introduced by the part: cost-and-latency) - **Decode**: Writing the answer, one token at a time. Sequential, and the reason output costs more. (introduced by the part: cost-and-latency) - **KV cache**: Stored intermediate values for tokens already processed, so each new token avoids recomputing them. (introduced by the part: cost-and-latency) - **Prompt caching**: Reusing an unchanged prefix across requests at a discount. Why stable content belongs first. (introduced by the part: cost-and-latency) - **System prompt**: Standing instructions placed at the front of the context on every turn. Not to be confused: Not a setting the machine enforces. It is text the model was trained to weight heavily. (introduced by the part: the-prompt) - **Role**: A label marking who a piece of the context came from: system, user, assistant, or a tool. (introduced by the part: the-prompt) - **Chat template**: The special tokens a given model family uses to mark role boundaries. Using the wrong one degrades output quietly. (introduced by the part: the-prompt) - **Prompt injection**: Text arriving from a document, page or tool result that the model follows as if it were an instruction. Not to be confused: Not a bug waiting to be patched. It follows from everything being one string, and it is handled with permissions. (introduced by the part: the-prompt) - **Markdown**: Plain text with a few visible conventions for headings, lists and code, readable by both a person and a model. (introduced by the part: markdown-files) - **Frontmatter**: A small block of machine-readable metadata at the top of an otherwise human-readable file. (introduced by the part: markdown-files) - **Instructions file**: A plain text file of standing rules, pasted into the context on every turn. Not to be confused: Nothing parses it. Its contents arrive as text like anything else. (introduced by the part: markdown-files) - **Tool**: An ordinary function your program exposes to the model by describing it in the context. (introduced by the part: tools) - **Function calling**: The model writing a structured request to run a tool, which your code then decides whether to honour. Not to be confused: The model never runs anything itself. (introduced by the part: tools) - **JSON Schema**: The usual format for describing a tool. Its description field is the only documentation the model gets. (introduced by the part: tools) - **Tool result**: Whatever your code returned, pasted back into the context as plain text. Also where untrusted content enters. (introduced by the part: tools) - **RAG**: Retrieval-augmented generation: fetching relevant passages and pasting them in before the model answers. (introduced by the part: retrieval) - **Chunking**: Cutting documents into passages small enough to retrieve and large enough to still mean something. (introduced by the part: retrieval) - **Vector search**: Finding stored passages nearest to a question in embedding space. Not to be confused: Misses exact terms like names and error codes, which is why production systems add keyword search. (introduced by the part: retrieval) - **Re-ranking**: Reordering the top candidates with a slower, more accurate model before they go in the window. (introduced by the part: retrieval) - **Relational database**: Structured records, queried exactly. Answers how many and which, not what resembles this. (introduced by the part: databases) - **Vector database**: Stores embeddings and answers what is most similar to this. The only one of the four specific to AI. (introduced by the part: databases) - **Key-value store**: Returns a thing by its name, very fast. Suits sessions, caches and saved summaries. (introduced by the part: databases) - **Graph store**: Holds relationships and answers what connects to what. (introduced by the part: databases) - **API**: The HTTP endpoint that takes an assembled context and returns tokens. (introduced by the part: interfaces) - **SDK**: A library wrapping that endpoint in your language. (introduced by the part: interfaces) - **MCP**: A shared convention for exposing tools and data, so any client can connect to any provider without bespoke wiring. (introduced by the part: interfaces) - **Streaming**: Sending each token to the screen as it is chosen, which is why an answer appears to type itself out. (introduced by the part: interfaces) - **Agent**: A model run in a loop with tools and a goal, until it finishes or hits a limit. Not to be confused: Not a persistent being. The loop is a program somebody wrote, and it stops. (introduced by the part: agents) - **Agent loop**: Write a step, run the tool, put the result back, look again. The agency lives here, not in the model. (introduced by the part: agents) - **Stopping condition**: What ends the loop: a declaration of success, an iteration cap, a spend cap, or a failure. (introduced by the part: agents) - **Context budget**: The fixed token allowance for one turn, and the competing claims on it. (introduced by the part: context-engineering) - **Summarization**: Replacing completed work with a short account of it to free room. Lossy, and the loss is silent. (introduced by the part: context-engineering) - **Sharding**: Splitting work so no single context has to hold all of it. Not to be confused: Not parallel thinking. Each shard is a separate run that cannot see the others. (introduced by the part: context-sharding) - **Subagent**: A separate run with its own clean window and a narrow brief, returning a summary to a coordinator. (introduced by the part: context-sharding) - **Compaction**: Replacing a long history with a short summary mid-run so the window can keep going. (introduced by the part: context-sharding) - **Fan-out**: Running independent work side by side. Costs N times the tokens for roughly the time of the slowest. (introduced by the part: orchestration) - **Pipeline**: Items flowing through stages independently, so nothing waits for the slowest item at each step. (introduced by the part: orchestration) - **Barrier**: A point where everything waits for everything else. Justified only when a stage needs all prior results at once. (introduced by the part: orchestration) - **Judge panel**: Generating several candidate answers and scoring them independently, to catch errors one confident run would not. (introduced by the part: orchestration) - **Persistence**: Anything that survives between runs. All of it lives outside the model, in a file or a store. (introduced by the part: memory) - **Staleness**: A saved fact that is out of date being recalled with exactly the same confidence as a current one. (introduced by the part: memory) - **Supersession**: Marking a saved fact as replaced rather than overwriting it silently, so the change is visible. (introduced by the part: memory) - **Eval set**: A fixed set of cases with known good outcomes, run on every change rather than every release. (introduced by the part: evaluation) - **Fabrication**: A confident, plausible, false output. Often called hallucination. Not to be confused: Not a malfunction. Producing the most plausible continuation is exactly what the model was trained to do. (introduced by the part: evaluation) - **Model as judge**: Using a second model to grade output that resists automatic checking. Good at comparisons, poor at absolute scores. (introduced by the part: evaluation) - **Regression**: A change that fixes one class of failure and breaks another. The reason a single aggregate score hides things. (introduced by the part: evaluation) - **Least privilege**: Giving each tool the narrowest permission that still lets it work. (introduced by the part: guardrails) - **Audit log**: A complete record of every action taken, including the ones that were blocked. (introduced by the part: guardrails) - **Blast radius**: How much damage one wrong action can do. Guardrails shrink this; they do not make the model reliable. (introduced by the part: guardrails)