The Short Story

How a system like ChatGPT is built, what exists once training is finished, and what happens to your text when you type, in about twenty minutes

The question

If you type something into a system like ChatGPT, what exists on the other side, how was it created, and what actually happens to your text?

A language model is a large mathematical function controlled by a very large collection of learned parameters; modern large models contain billions of them. Creating one starts with assembling and preparing text, then using that text to train a neural network to predict tokens, the small units the text is cut into. [S-05] Post-training then changes those same parameters so that the model becomes far more useful for following instructions. [S-55] When you later type into a ChatGPT-like product, the parameters normally stay fixed. Your message becomes part of the model’s context, the model generates tokens one at a time, and software around the model can add retrieval, tools, external state, and repeated calls. [S-31] [S-56]

  1. raw data
  2. curated training corpus
  3. tokenizer
  4. pretraining
  5. base model
  6. post-training
  7. post-trained model
  8. inference-time context
  9. tools, external state, and the loop
  10. agentic system
The whole route in one line: raw data is curated into a training corpus and tokenized; pretraining produces a base model; post-training produces the post-trained model that products build on. At use time, the surrounding system supplies the model's inference-time context, and software outside the model adds tools, external state, and retrieval, which brings information into that context; software that calls the model in a loop with those pieces is an agentic system. Colors mark the five kinds of thing involved: data, training, the model, context, and the software around it.

Pretraining and post-training are both training, because both update the model’s parameters. Everything after the post-trained model leaves the parameters alone: it changes what the model is given and what is done with its output.

1. What the finished object is

Stripped of the surrounding product, a runnable open language model is two things: code that implements the neural-network computation, and a checkpoint file holding the learned parameters. Andrej Karpathy’s 2023 general-audience introduction opens with this picture, using an open model as the example: a large file of parameters, and a small program that runs the network with them. [S-75] His llama2.c repository shows the same division literally, as a single C inference file for the Llama 2 architecture that needs a model checkpoint before it can generate anything. [S-82] The file count varies by product and deployment; the division of labor does not. The code specifies how the computation works. Training discovers the parameter values. The information the model learned during training is distributed across those values.

What a runnable model is Two boxes side by side. The left box, labeled architecture and runner code, says how to compute. The right box, labeled learned parameters theta, holds learned values stored in a checkpoint. A plus sign joins them; an arrow leads down to a third box labeled model inference, which takes context in and gives a next-token distribution out, with theta unchanged. architecture / runner code how to compute: sums, nonlinearities, attention + learned parameters θ learned values stored in a checkpoint model inference context in → next-token distribution out parameters θ unchanged
Stripped of product infrastructure, a runnable open model is code that implements the network's computation plus a checkpoint holding the learned parameters. Inference runs the code with those parameters fixed. This framing follows Karpathy's 2023 general-audience talk; it is an intuition about what the object is, not a rule that every deployed product consists of exactly two files.

Using the model is called inference: the code runs with the parameter values fixed and computes a probability distribution over the next token. Ordinary inference does not change the parameters, so the rest of this page divides into how the parameters get their values, and what the surrounding software does with the finished object.

Go deeper: How Pretraining Works §8 on what does and does not change the parameters.

2. The smallest piece of a neural network

The smallest useful piece of a neural network is one learned transformation:

\[ h = \sigma(Wx + b) \]

\(x\) is a list of incoming numbers. \(W\) and \(b\) are learned parameters: \(W\) multiplies the inputs, forming a weighted sum, and \(b\) shifts the result. \(\sigma\) is a fixed nonlinear function applied to that sum. \(h\) is the newly computed representation, another list of numbers, ready to be the \(x\) of the next step. [S-12] This is not “the equation for ChatGPT”. It is the basic pattern from which much larger networks are built.

A basic neural-network building block Four boxes in a row joined by arrows: x, the inputs; W x plus b, a weighted sum with learned W and b; sigma, a nonlinearity; and h, the output. A note says that in this toy unit, training changes W and b. x inputs Wx + b learned W, b σ nonlinearity h output in this toy unit, training changes W and b
A basic neural-network building block: inputs x, a weighted sum Wx + b whose weights W and bias b are learned parameters, a fixed nonlinear function σ, and the output h. Larger networks combine many learned transformations and nonlinear operations; this is the smallest example to keep in mind.

Larger neural networks combine many such learned transformations and nonlinear operations, arranged in layers, with millions or billions of parameters chosen by training rather than by a person. This one-line example is the smallest case to keep in mind. A language model is a particular, enormous network of this kind, and the object it computes can be written as

\[ p_\theta(\text{next token} \mid \text{context}) \]

where \(\theta\) stands for the entire collection of learned parameters, the transformer architecture (§5) defines the huge function that uses them, and the output is a probability distribution over every possible next token given the text so far. Whenever “parameters”, “training”, or “the network” appears below, it refers to \(\theta\), to the process that sets \(\theta\), or to the function that uses \(\theta\).

Go deeper: Neurons, Layers, and Learning works one unit through by hand, including one full training step.

3. Assembling the text the model learns from

The first step in creating a language model is assembling the text it will learn from. That text does not arrive ready to use. Source material is gathered from web pages, code, books, and other permitted sources; the main text is extracted from its raw form, stripped of navigation menus and markup; documents are filtered by language and by quality rules; duplicates are removed, because the same page copied a thousand times would otherwise be learned a thousand times; and only the surviving text is handed to the tokenizer. What ends up in that corpus shapes what the model can learn, and every step involves choices.

  1. raw sources: web pages, code, books
  2. extract the main text
  3. filter by language and quality
  4. remove duplicates
  5. curated corpus
  6. tokenizer
  7. token sequences for training
Before any training, a corpus is built: source material is gathered from permitted sources, the main text is extracted from its raw form, documents are filtered by language and quality, duplicates are removed, and the surviving text is tokenized into the sequences the model will be trained on. The steps and their order vary between corpora; this is the general shape.

Hugging Face’s FineWeb dataset is one open example of such a pipeline. It is built from Common Crawl web snapshots by filtering URLs, extracting the main text of each page, keeping English text, applying quality filters, and removing duplicates, and the whole recipe is published. [S-78] It is one example, not a template. Complete training corpora for closed models are often not publicly disclosed, the level of disclosure varies across models and providers, corpora differ between models, and no model trains on “the whole internet”. This is why the shorthand “trained on the internet” hides a substantial data-engineering pipeline.

Go deeper: From Text to Numbers §1 on the corpus, then §3 onward for what happens to it. For the full engineering lifecycle, including data pipelines, see Stanford CS336 in resources.

4. From text to tokens to vectors

A neural network computes with numbers, so the corpus, and later your message, has to be converted. The tokenizer cuts text into tokens drawn from a fixed vocabulary decided before training. A token may be a whole word, a fragment of one, punctuation, or another piece the tokenizer defines; in many commonly used subword tokenizers a preceding space affects the token. [S-28] Each token is then replaced by its index in the vocabulary, its token ID. With made-up numbers, “cat” might become 812 and “dog” 913.

Those two integers are arbitrary addresses. They do not mean that dog is larger than cat, or 101 units away from it, or that tokens with nearby IDs have related meanings; a different tokenizer would assign entirely different numbers to the same pieces. So the network should not treat the ID itself as a meaningful quantity, and it does not. The ID selects one row of a learned matrix, the embedding table \(E\), and that row, \(E[812]\) for “cat”, is a vector of learned numbers. The entries of \(E\) are parameters. Training changes them because changing them can improve next-token prediction, and by the end of training tokens that occur in similar contexts tend to have similar rows. [S-29] [S-30] That is what the lookup buys: instead of an address, the network receives numbers it can transform and combine.

From token ID to vector to contextual representation Top row: the token bank becomes token ID 3912; the ID selects row 3912 of the embedding table E; that row is the vector E of 3912, shown with illustrative values 0.18, minus 0.42, 0.07 and so on. Bottom row: the same starting embedding for the token bank enters transformer blocks in two different sentences, the river bank and the central bank, and comes out as two different contextual vectors, A and B. “bank” token ID 3912 embedding table E row 3912 E[3912] = (0.18, −0.42, 0.07, …) the ID is an address; the row it selects is a vector of learned numbers (illustrative values) same starting embedding for the token ␣bank in “the river bank” in “the central bank” transformer blocks transformer blocks contextual vector A contextual vector B same ID and same initial embedding; different contextual representations
Top: a token becomes an ID, the ID selects one row of the learned embedding table, and that row is the vector the network actually computes with. The ID is only an address; the values shown are illustrative. Bottom: the same starting embedding for the token ␣bank (the leading space is part of the token) enters the transformer blocks in two different sentences and comes out as two different context-dependent vectors, because the blocks update each position using the positions around it.

The row is only the starting point. The embedding for ␣bank (the leading space is part of the token) is the same wherever the token occurs, but the transformer’s layers then update each position using the positions around it, so that in “the river bank” and “the central bank” the same starting vector ends as two different contextual representations. Section 5 explains the mechanism that does this. Mathematically, an embedding lookup is the same as multiplying a vector that is all zeros except for a single one at the token’s position by the matrix \(E\); in practice, the implementation simply retrieves the row. [S-86] The tokenizer is not the model and is not trained by the same process: its splitting rules are fixed before training, while \(E\) is part of \(\theta\) and is learned.

Go deeper: From Text to Numbers traces one sentence through these steps; Tokens, Embeddings, and the Context Window explains why the vocabulary is made of fragments.

5. From recurrent networks to the transformer

Neural networks were already being used to predict language before transformers. An influential 2003 model learned a vector for each word together with a network that predicted the next word, trained by the same kind of objective the transformer uses today. [S-29] [S-41] For sequences, recurrent networks, including LSTMs, became established and highly influential approaches. [S-21] A recurrent network passes a running state from one position to the next. To relate two distant positions, information has to travel through every intervening step, and each step’s computation depends on the previous one having finished. During training that dependency limits how much can be computed in parallel, and it makes the path between distant positions long. [S-16]

Recurrent sequence processing versus attention Top row, labeled recurrent network: five token boxes joined by single arrows from each to the next, so information from token 1 reaches token 5 only by passing through tokens 2, 3, and 4. Bottom row, labeled transformer with causal attention: five position boxes, with arcs drawn beneath them from each later position back to every earlier position, showing that position 5 can read positions 1 to 4 directly in one layer. A note states that during training on a known sequence, positions within a layer are computed in parallel. Recurrent network: state passed one step at a time token 1 token 2 token 3 token 4 token 5 information from token 1 reaches token 5 only through 4 sequential steps Transformer: direct attention to earlier positions pos. 1 pos. 2 pos. 3 pos. 4 pos. 5 each position reads its permitted earlier positions in one layer during training on a known sequence, positions within a layer are computed in parallel
Top: a recurrent network carries a running state from each token to the next, so relating distant positions takes many sequential steps, and step by step is the only order available. Bottom: in a transformer, self-attention lets each position read directly from the positions it is permitted to use (in a causal language model, itself and earlier ones), and during training on a known sequence the positions within a layer are computed in parallel; generation still proceeds one token at a time. Direct connection is a property of the architecture; whether training learns to use it well for a given task is a separate question.

Attention gives a position a direct way to combine information from the other positions it is permitted to use. It works in short steps. The model transforms the destination’s representation into a query vector. It transforms each permitted source’s representation into a key vector. Comparing the query with each key produces a score. Softmax converts those scores into nonnegative weights that sum to one. Each source also provides a value vector, a transformed representation carrying the information to be combined. The weighted combination of those values supplies the information used to update the destination’s representation. [S-36] In “The animal crossed the street because it was tired”, the representation at “it” can draw heavily on “animal” and lightly on the rest, in a single step, without relaying anything through the positions in between.

What one attention head computes Seven token boxes in a row: The, animal, crossed, the, street, because, it. The last token, it, is the destination. Under each token is an illustrative attention weight: The 0.02, animal 0.55, crossed 0.05, the 0.02, street 0.11, because 0.20, it 0.05, summing to one. Lines from every token converge on a box labeled weighted combination of value vectors, whose thickness reflects the weight, and an arrow leads to a box labeled updated representation of it. A note says this is one head in one layer; real models run many heads and many layers. destination The animal crossed the street because it 0.02 0.55 0.05 0.02 0.11 0.20 0.05 weighted combination of value vectors updated representation of “it” illustrative attention weights for the destination “it” (they sum to 1.00) one head in one layer; real models run many heads and many layers
One attention head, for one destination position. The model computes a weight for each permitted source position (here every position up to and including "it"), the weights are nonnegative and sum to one, and the destination receives the weighted combination of the sources' value vectors (each source's representation passed through a learned transformation), which becomes its updated representation. The weights are illustrative. They are local mixing weights inside one head at one layer, not a complete or causal explanation of the model's output; real models run many heads in parallel and stack many layers.

The three transformations, into queries, keys, and values, are learned matrices: parameters set by training. The attention weights are not parameters; they are computed afresh for each input from those transformed vectors. [S-36] An attention weight is a local mixing weight inside one head at one layer, not a causal explanation of the model’s output, and real models run many heads in parallel and stack many layers, so no single weight tells you why the model said what it said. [S-37] [S-45]

Attention came before the transformer. Bahdanau, Cho, and Bengio used a learned weighted selection over source positions in a neural translation system, in work posted in 2014 and presented at ICLR 2015. [S-68] Vaswani and colleagues’ 2017 paper, Attention Is All You Need, then built a sequence architecture around attention and per-position feed-forward computation, without recurrence, at a time when recurrent networks were the established state of the art. [S-21] [S-23] In one layer any position can read any permitted earlier position directly, and during training on a known sequence the positions within a layer can be computed in parallel; generation itself still proceeds one token at a time. [S-17]

A transformer is not attention alone, and it is not the beginning of neural networks. Each repeating block contains two kinds of computation: self-attention, which moves information between positions, and a feed-forward layer, which computes on each position separately using the pattern from §2. A model stacks many such blocks. [S-19] In the causal decoder models this course is about, a position may attend to itself and earlier positions, never later ones. [S-22]

Removing much of the recurrent sequential dependency made training substantially more parallelizable, and the paper notes that its attention can be implemented with highly optimized matrix-multiplication code, the kind of computation that GPUs and later accelerators perform well. [S-23] That fit was one reason among several that transformers became dominant, alongside scale, training data, and the surrounding software ecosystem; this course does not attempt a hardware history. [S-20] Dense attention also has its own cost, growing with the square of the sequence length. [S-17]

Go deeper: Why Transformers for the argument and the paper’s own figures; How Self-Attention Moves Information for the arithmetic on a three-token example; Milestones for the history.

6. Pretraining makes the base model

Pretraining is the first and largest parameter-learning phase. The corpus is tokenized, and at every position the model is asked to predict the next token; the text itself supplies the answer, so no one has to label anything. A loss measures how little probability the model gave to the token that actually came next. Backpropagation computes the gradient of the loss with respect to the trainable parameters, that is, how the loss would change with a small change in them. An optimizer uses those gradients to nudge \(\theta\). Then the next batch of text, and the next, on a scale hard to picture. [S-05] [S-14] [S-40]

token sequences → next-token predictions → loss
      → backpropagation computes gradients → optimizer updates θ → repeat

The architecture and the optimization procedure are specified in code; training is the process that discovers the parameter values. The result is the base model. Because predicting text well requires capturing its regularities, the base model has broad statistical knowledge of grammar, meaning, recurring facts, and conventions of argument, and language models trained only to predict text have been observed to perform tasks such as answering questions and translating without being trained for them. [S-44] [S-26] A base model is not a database that reliably retrieves records from its training corpus. It can nevertheless memorize and sometimes reproduce passages from that data: researchers have extracted verbatim training text from a public model, including sequences that appeared in only one training document. [S-87] Generation is not reliable lookup, and nothing in the objective checks truth. [S-08] The base model is also not specifically optimized to behave as a conversational assistant. Given an instruction, it may answer it, continue it, or produce more instructions like it, because all of those follow such text somewhere in the corpus.

Go deeper: How Pretraining Works sets out the objective, the loss, the loop, and what they do and do not teach.

7. Post-training shapes assistant behavior

Post-training changes the same parameter collection \(\theta\), with the same machinery of loss, gradients, and optimizer. No new kind of network appears. What changes is the data and the objective. [S-55]

The simplest form, supervised fine-tuning, trains on curated conversations: a prompt, and the response the builders want. The loss is the same next-token loss as pretraining, applied to the response tokens, so that after training a request is far more likely to be treated as a request. Preference-based stages go further: candidate responses are compared, and the parameters are updated toward the preferred behavior, either through a learned reward model and reinforcement learning (the route usually called RLHF) or directly from the comparison pairs. [S-46] [S-47] The influential 2022 recipe used human-written demonstrations and human comparisons; published modern recipes can also use synthetic or model-generated data and feedback produced by models, rules, or automatic checks, as Constitutional AI and the DeepSeek-R1 report each illustrate, so “post-training data” does not simply mean “text written by human labelers”. [S-48] [S-49] The methods vary between providers and change over time, and they share one thing: they update parameters.

Pretraining

Data
a very large curated corpus of text
Objective
predict the next token at every position
Changes
the model's trainable parameters θ
Produces
the base model

Supervised fine-tuning

Data
curated conversations: prompt → desired response
Objective
the same next-token loss, on the response tokens
Changes
the same parameters θ, starting from the base model
Produces
an instruction-tuned, post-trained model

Preference- or reward-based

Data
comparisons between responses, or outcomes that can be scored
Objective
use preference or reward signals to further shape behavior
Changes
the same parameters θ again
Produces
a further post-trained model
Every stage is training in the same mechanical sense: a loss or reward is computed on the model's output, gradients are computed, and an optimizer updates the same parameter collection θ. What differs is the data and the objective. Providers combine and vary these stages; the third column is a family of methods with different constraints, and not every deployed model passes through exactly these steps.

Useful analogy, not the mechanism

Karpathy’s 2025 deep dive organizes the training stages with a classroom picture: pretraining is like reading expository text to acquire background knowledge; supervised fine-tuning is like studying worked examples; reinforcement learning on checkable tasks is like solving practice problems against an answer key. [S-76] The analogy is useful for two reasons. It explains why later stages use more targeted data and feedback than pretraining, and it separates imitating demonstrations from trial and error against a checkable outcome. Human learning and neural-network optimization are biologically and mechanistically different; the analogy organizes the stages, and it is not a theory that language models learn the way people do.

The instructions a product places in front of your conversation, its system prompt, are not post-training. They are text in the context, and they change nothing in the model. [S-31]

Go deeper: Post-training describes the family of methods and keeps its members straight.

8. Fluency, abstention, and evidence

A fluent assistant can state something false, and the reason is in the training objective rather than in a defect that post-training added. Pretraining rewards assigning probability to whatever came next in the text and contains no independent check of truth, so false or unsupported continuations are already possible before any post-training. [S-08] Post-training then makes instruction-following and question-answering behavior much more likely. A model can therefore produce a well-formed answer even when the information encoded in its parameters is insufficient, because nothing in the mechanism asks whether it is. Depending on the recipe, post-training can also explicitly encourage abstention, calibrated uncertainty, truthfulness, or tool use. Post-training did not create the possibility of unsupported answers; it changed the default form of the response.

Post-training can include examples in which the right response is to say “I don’t know” or to ask for more information, so that abstention becomes a likely response when the model’s own knowledge is thin. Retrieval and tools can ground an answer in external, inspectable evidence, a document or a search result placed in the context at inference time, rather than relying only on information encoded imperfectly in \(\theta\). [S-33] That evidence still has to be evaluated: retrieval can return irrelevant or incorrect material, and a tool result verifies only what it was asked. Karpathy’s introductions make the first point in plain language, as a pedagogical intuition: fine-tuning does not remove a model’s tendency to produce confident inventions, it “directs” that tendency toward helpful assistant behavior, and retrieved material in the context window changes what the answer can rest on. [S-75] [S-77] Fluency is not evidence, and evidence beats confidence.

Go deeper: How Pretraining Works §7 on prediction versus verification; Using Models Well §4–§6 on sources of truth and verification.

9. What happens when you type

When you send a request, the trained model generates its response one token at a time. With the post-trained model built and its parameters fixed, here is one request followed all the way through.

  1. You type text. The surrounding product assembles and manages the context window for this call: its system prompt, the conversation so far, any documents or tool results it has decided to include, and your new message. [S-31]
  2. The tokenizer converts that text into token IDs. [S-28]
  3. Each ID selects its embedding vector from the table \(E\).
  4. The vectors pass through the transformer blocks; at each block, attention lets every position use the permitted earlier positions, and the feed-forward layer computes on each position. [S-19]
  5. After the last block, the vector at the final position is turned into one raw score per vocabulary entry (machine-learning literature calls these scores logits). [S-05]
  6. Softmax turns the scores into a probability distribution; a setting called temperature controls how concentrated it is.
  7. A decoding rule selects the next token, deterministically or stochastically. [S-07]
  8. That token is appended to the context, and the next step runs on the extended sequence.
  9. Repeat until the model produces a stop token or a limit is reached. A paragraph of output is this loop, one token at a time.
What happens when you type: the token-generation loop Top row, left to right: context (the text so far), tokenizer, token IDs, embeddings, transformer blocks. An arrow leads down to the bottom row, which runs right to left: logits, softmax giving probabilities, decoding, next token. A return arrow carries the next token back up to the context box, labeled: the new token is appended to the context and the loop runs again. A note says the parameters are unchanged and that keys and values for earlier positions are cached and reused. context the text so far tokenizer token IDs embeddings transformer blocks logits softmax probabilities decoding next token the new token is appended to the context and the loop runs again parameters θ unchanged; keys and values for earlier positions are cached and reused
One generation step, and the loop it belongs to. The surrounding product supplies the context; the tokenizer turns it into token IDs; each ID selects an embedding; the transformer blocks update every position; the final position's vector becomes one score per vocabulary entry (the logits); softmax turns the scores into probabilities; a decoding rule selects a token; and the token is appended to the context for the next step. Nothing in the parameters changes, and implementations typically cache the keys and values already computed for earlier positions rather than recomputing them.

At every step the parameters do not change: ordinary inference never updates \(\theta\). The system prompt and any supplied documents are context, not retraining. Implementations typically reuse cached intermediate results for the earlier positions, the keys and values that attention computed, rather than recomputing them at every step. [S-43] When stochastic decoding (sampling) is used, it is one reason repeated runs from the same context can produce different continuations without anything in the model having changed.

Go deeper: Softmax, Sampling, and Temperature for the equation and an interactive; How Pretraining Works §9 on why training and generation are different computations.

10. Reasoning-oriented models: training, and thinking longer at inference

A reasoning-oriented model can use additional generation steps before producing its final answer. Some such models receive additional reinforcement learning on problems whose outcomes can be checked automatically, such as mathematics problems with known answers or code with tests. An automatically checkable or rule-based outcome can supply a reward without requiring a learned reward model for that reward component, and reinforcement learning against such rewards can encourage useful intermediate reasoning before the final answer. In the published DeepSeek-R1 case, this was associated with better performance on reasoning tasks and with steadily longer intermediate reasoning traces; R1-Zero, which applied reinforcement learning directly to the pretrained base model with no supervised fine-tuning step first, suffered from poor readability and language mixing, and the released R1 model used a multi-stage recipe that also included supervised stages. [S-49] This is one post-training route used in some reasoning-oriented models, not a stage every model goes through, and recipes differ between providers.

Training is only half of what “a model that thinks longer” means. Once training is finished, the parameters remain fixed. A reasoning-oriented model can nevertheless spend more computation on a difficult request by generating additional intermediate reasoning tokens before producing the final answer. The next-token mechanism did not disappear: the intermediate reasoning is generated sequentially by the same model, and each intermediate token becomes part of the context that the following computation conditions on. That gives the model more sequential inference-time computation before it commits to an answer. It is not another training round, and the parameters do not change. [S-83]

immediate response
  1. prompt
  2. answer
more inference-time reasoning
  1. prompt
  2. intermediate reasoning tokens
  3. more intermediate reasoning
  4. answer
reasoning with tools
  1. prompt
  2. reasoning
  3. tool request
  4. software runs the tool
  5. observation enters context
  6. reasoning
  7. answer
Three ways one trained model can be used at inference time. In every row the parameters stay fixed. In the second row the model generates intermediate reasoning tokens before its answer, which is additional inference-time computation by the same next-token mechanism, not a change to the model and not human thought. In the third row the model's reasoning produces a tool request; the software outside the model executes it, and the observation returns to the context for further reasoning.

Many modern reasoning-oriented models can spend additional inference-time computation in this way before producing a final response, and providers expose the choice in different ways, such as a reasoning-effort setting or a thinking level. The documentation of Anthropic, Google, and OpenAI, read on 2026-09-15, each describes its own models generating reasoning before the answer, a control for how much, and reasoning tokens that are counted and billed like output. [S-83] [S-84] [S-85] On some difficult tasks, generating intermediate reasoning tokens provides additional inference-time computation and can improve performance. The tokens are output, produced by the same next-token mechanism as any other output. They are not a transcript of the model’s internal computation. What a product exposes of intermediate reasoning varies by model and interface, and a displayed explanation should not be treated as a guaranteed faithful record of the underlying computation; Anthropic’s announcement of its feature states that what appears in the thought process is not guaranteed to represent what is going on inside the model. [S-49] [S-83] [S-84] [S-85] And the tokens are not thought in the human sense.

Reasoning also connects to tools. A model can reason, generate a request for a tool, have the surrounding software execute it, receive the observation into its context, and continue reasoning with the new evidence before answering or requesting another tool; Anthropic’s and OpenAI’s current documentation both describe reasoning interleaved with tool calls in this way. [S-83] [S-85] The reasoning never executes anything itself; §12 walks through one such round trip.

Go deeper: Post-training §7.

11. Parameters, context, and external state

The model can also use information supplied in the current context or returned by tools. A model can carry useful information in three very different places. Training encodes statistical information in the parameters, which are inside the model and change only when it is trained. A request puts information directly into the current context: for each model step, the surrounding system supplies or manages a finite inference-time context, the sequence of tokens the model conditions on for that step. And software can keep information outside the model, as external state such as files, a database, saved notes, or a stored summary of an earlier session, and supply it again later. Information persisted across sessions is maintained outside the model and may be retrieved or supplied again on later steps; persistence alone does not update model parameters. [S-31]

Parameters, context, and external state Three boxes in a row. Left, in the model color: parameters theta, inside the model, fixed during use, changed only by training. Middle, in the context color: context, the tokens supplied for this model step, such as instructions, conversation, retrieved text, and tool results. Right, in the system color: external state, files, databases, and notes persisted outside the model. Arrows show training entering the parameters from above, and retrieval carrying external state into the context. training (pretraining, post-training) parameters θ inside the model fixed during use changed only by training context tokens supplied for this step: instructions, conversation, retrieved text, tool results external state files, databases, notes persisted by software outside the model retrieval brings external state into a later context the model conditions on the context using its parameters
Three things that are easy to run together under the word "memory". The parameters are inside the model and change only when it is trained. The context is the finite inference-time context supplied or managed for a model step. External state is whatever is persisted outside the model; it can be retrieved into a later context, which changes that step's inputs and not the parameters.

All three are sometimes described informally as “memory”, which is why the word can be confusing; a product that “remembers” your project has stored something outside the model and supplied it again, and no parameter was updated. Retrieval is the general name for bringing external information into the context, from a document collection, a search, a file, or a store. It changes this call’s inputs, never the parameters. [S-33]

Useful analogy, not the mechanism

Karpathy’s introductions describe the context window as the model’s “working memory”. [S-75] [S-77] Building on that framing, a useful course analogy is to think of parametric knowledge as imperfect long-term recall and explicit context as material currently in working memory, directly in front of the system for this call. It is an intuition about why supplying a document works better than hoping the model “knows” its contents. Analogy, not mechanism: it is not a claim that the network has memory systems like a person’s.

Go deeper: Tokens, Embeddings, and the Context Window §8–§10; From Assistant to Agent §7.

12. Tools, and the loop that makes an agentic system

Suppose you ask an assistant, “What is the weather in Bogotá today?” The model’s parameters cannot contain today’s weather, and a model call by itself does not read a file, run a program, search the web, or send anything. What makes an answer possible is that the software around the model has described an available weather tool in the context, with its name, what it does, and the inputs it takes. Instead of inventing a value, the model generates structured output that means, roughly, call weather(location="Bogotá"). The surrounding software recognizes that request, checks it against its permission rules, and runs the weather tool. The tool returns a result; suppose, for this example only, that it returns 18 °C, light rain. The software places that result into the context of a later model call, and the model reads it and writes the answer. [S-51]

The model requested the action. Software executed it. The result became new context. At the model boundary, a tool call is generated output in a structured format, and everything that happens between the request and the result is performed outside the model.

One tool call, from request to answer Three vertical lanes labeled model, surrounding software, and tool and result. Six numbered boxes run from top to bottom, alternating lanes: 1, the user request is placed in the context (software lane); 2, the model generates a structured tool request (model lane); 3, permission check, then the software runs the tool (software lane); 4, the tool returns a result, evidence or an error (tool lane); 5, the result is placed into the next context (software lane); 6, the model generates the answer (model lane). Thin lines connect each box to the next. model surrounding software tool and result 1. the user request is placed in the context 2. the model generates a structured tool request 3. permission check, then the software runs the tool 4. the tool returns evidence, or an error 5. the result is placed into the next context 6. the model generates the answer
One tool call from request to answer. Purple boxes are generated output from the model; gray boxes are actions taken by the surrounding software and the tool; green boxes are context supplied to a model call. The model never runs anything itself: it generates the request in step 2 and the answer in step 6, and everything between is performed outside the model and returned as evidence.

Repeat that round trip under a controlling loop and you have the minimal mechanism behind what this course calls an agentic system. An objective and the current context go to the model; the model produces a tool request or a response; a request is checked and executed; the observation updates the context; the model is called again; and the loop continues, asks you, or stops.

objective + current context and state
            │
            ▼
   model call: choose the next action
            │
            ▼
   structured tool request  ──or──  final response
            │
            ▼
   permission check / validation by surrounding software
            │
            ▼
   external execution (file read, command, search, ...)
            │
            ▼
   observation / evidence returned
            │
            ▼
   context and state updated
            │
            ▼
   next model call  ──►  continue, ask the user, or stop
The agent loop. The surrounding software assembles a context from the objective and the current state and calls the model; the model returns a tool request or a response; a request is checked against permission rules and executed; the observation is added to the context and the state is updated; and the model is called again until it, or the software, or the user, stops the loop. The model does not run between calls, and its parameters do not change.

Nothing new appears inside the model at this stage. The same network, the same fixed parameters, and the same next-token prediction are invoked repeatedly by software that carries the state between calls. [S-56] The word agent has no universally fixed boundary; a system whose steps are mostly written in advance is better called a workflow, and the simplest system that reliably solves the task is usually the right one. [S-50]

Go deeper: From Assistant to Agent walks through one tool call and one whole task, with state, skills, verification, and permissions.

13. The mental model

A language model is a learned next-token predictor: code plus a large collection of parameters. A curated corpus was tokenized and used in pretraining to set those parameters so that they capture the structure of text; post-training changed them further, with the same machinery on different data, so that the model behaves as an assistant. Once trained, the parameters are fixed; the request-specific information the model conditions on is supplied through inference-time context, and decoding settings and surrounding product logic can also affect the output without changing a parameter. Software around the model can give it retrieval, tools, and persistent state, and can call it repeatedly, and that loop of model step, action, and evidence is what turns a predictor into a system that carries out work.

Four consequences follow for anyone who uses such a system. Fluency is not evidence: the output is a plausible continuation, whether or not anything was checked. Tool use is not automatically verification: a tool was used only if a request was executed, and it verified only what it was asked to verify. A passing check proves only what that check tested. And models and tools can assist judgment, by organizing evidence, testing alternatives, and checking mechanical claims, but on judgment-heavy questions the system’s output does not itself establish that the conclusion is warranted; evidence, review, and human accountability remain necessary.

Go deeper: Using Models Well turns these into working habits; the glossary defines every term used above.