Speaking Guide

One section per slide of the 30-minute presentation: what to say, how long, and where the deeper lesson is

This guide accompanies the presentation. Each section names the slide by its title and stable ID, states what the slide is for, gives an estimated speaking time and a running total, and then says, in ordinary spoken paragraphs, what to explain and how to use the visual. The prepared route is 28 minutes of material plus a 2-minute reserve for pauses, transitions, and small overruns, inside a 30-minute slot. The reserve is not extra content and not a promised question period. All timings are planning estimates, not observed rehearsal results. Paragraphs marked “optional” are elaboration outside the prepared route. The slides’ speaker notes carry only short cues; this page is the script.

Running late

Protect the ending. The tools and agents block (the last five minutes of the route) is the part the audience cannot reconstruct from general reading, so shorten earlier material first. In order: on the tokens slide, say only that IDs are addresses and skip the cat-and-dog aside; on the base-model slide, read the three statements without expanding them; on the post-training slide, name the three routes without describing the second and third; on the transformer slide, skip the hardware sentence. If twelve minutes have gone before the pretraining slide, take the generation-loop slide in one minute by walking the figure once without the closing sentences. Never skip the tool-call slide, the agent-loop slide, or the coding-agent slide, and do not spend the reserve on the earlier blocks.

From LLMs to Agents

Objective: open the room and set the register. Time: about 0.5 min (running total 0.5).

Say who you are in one sentence and what the next half hour is: a mechanical account of what a system like ChatGPT is, how it was built, and what happens when you type into it, with no mathematics required to follow and a website that carries the mathematics for anyone who wants it.

Transition: “Start with the question the whole talk answers.”

One question: what is on the other side of the text box?

Objective: state the governing question and show the whole route once, in colour, before any term is defined. Time: about 1.0 min (running total 1.5).

Read the question aloud. Then trace the coloured route on the slide from left to right without explaining any stage yet: blue is data, orange is training, purple is the model itself, green is the context the model is given when it is used, and grey is the software around the model. Say that every slide from here on is one stop on this route.

One point now, because it organises everything: the orange stages, pretraining and post-training, are both training. Both change the numbers inside the model. Everything after the purple “post-trained model” leaves those numbers alone; it changes what the model is given and what is done with its output.

Transition: “Here is the route in ordinary words.”

Deeper: The Short Story.

The route, in three parts

Objective: give the audience three questions to hold. Time: about 0.5 min (running total 2.0).

Read the three columns as three questions: how a model is built, what happens when we use it, and how software makes an agentic system. Promise that the third question gets real time at the end.

Transition: “Before any of that, what is the finished object? Start at the end.”

A runnable model is code plus learned parameters

Objective: make the finished object concrete, and separate it from the application around it. Time: about 1.5 min (running total 3.5).

Point at the two top boxes. Stripped of the product around it, a runnable open language model is two things. On the left, code: a program that says how to compute, which sums to form, which nonlinear functions to apply, which attention steps to take. On the right, a checkpoint: a large file of learned numbers, the parameters. Andrej Karpathy’s 2023 introduction opens with exactly this picture, and his llama2.c repository shows it literally: one C file that runs the Llama 2 architecture, which cannot generate anything until you give it a model checkpoint.

Then the bottom box. Running the code with the parameters fixed, on some context, produces a probability distribution over the next token. That is inference, and it does not change the parameters. Then the sentence on the slide: the application adds instructions, conversation management, tools, and other software around the trained model. Two products can share one model and behave differently.

Do not say the file count is always two, and do not say the parameters are “everything the model knows”. Say that the information the model learned during training is distributed across those numbers.

Transition: “Now the first half: how the model is built. It starts with text.”

Deeper: How Pretraining Works §8; Post-training §9 on model versus assistant; Karpathy, Intro to Large Language Models (2023); the llama2.c README. The backup slide at the end of the deck shows the product-versus-model picture if a question calls for it.

Before training, someone builds the corpus

Objective: replace “trained on the internet” with a pipeline. Time: about 1.0 min (running total 4.5).

Walk the chips left to right. Text is gathered from web pages, code, books, and other permitted sources. The main text is extracted from raw pages. Documents are filtered by language and by quality rules. Duplicates are removed, because a page copied a thousand times would otherwise be learned a thousand times. Only then is the surviving text tokenized. What goes in shapes what can be learned.

One open example: Hugging Face’s FineWeb is built from Common Crawl snapshots by this kind of pipeline, and its recipe is published. Complete corpora for closed models are often not disclosed. Do not imply that proprietary models use FineWeb.

Transition: “The corpus is text. A network computes with numbers. So the text has to be converted.”

Deeper: From Text to Numbers §1; Penedo et al., The FineWeb Datasets (2024).

Text becomes tokens; a token ID is an address

Objective: define token and token ID, and kill the idea that an ID is a quantity. Time: about 1.0 min (running total 5.5).

Point at the chips. The tokenizer cuts text into entries of a fixed vocabulary decided before training. A token is often a whole word, but it can be a fragment, a punctuation mark, or a word with its leading space attached; the split shown is illustrative. Each vocabulary entry has an index, the token ID; the numbers on the slide are made up.

Then the point that matters: 5109 is not larger, later, or more than 88. It only says which entry of the vocabulary this is. Optional aside: with made-up IDs, “cat” might be 812 and “dog” 913, and nothing about dog is 101 units away from cat. If the network did arithmetic on the ID itself, the result would be meaningless. So it does not.

Transition: “If the ID is only an address, what does the network actually compute with?”

Deeper: From Text to Numbers §3–§4; Radford et al. (2019) for the tokenizer facts.

The ID selects a learned vector

Objective: explain why an ID becomes a vector, and what “learned” means here. Time: about 1.0 min (running total 6.5).

Trace the figure. The token “bank” becomes ID 3912. The ID selects one row of a table, the embedding table. That row is a list of numbers, and those numbers are parameters: they started arbitrary, and training changed them because changing them improved next-token prediction. That is what the lookup buys the network: instead of an address, it receives numbers it can transform and combine. The values on the slide are illustrative; a row is not a definition.

One sentence that prepares the transformer: the row is only the starting point. Later layers update each position using the positions around it, so the token for ” bank” starts the same in “river bank” and “central bank” and ends different.

Transition: “Numbers going into a network. What does the network do with them?”

Deeper: Tokens, Embeddings, and the Context Window §6–§7; Bengio et al. (2003).

A neural network: learned transformations and nonlinear steps

Objective: make “neural network” mean something mechanical. Time: about 1.0 min (running total 7.5).

Walk the four boxes. Incoming numbers, x. Multiply them by learned weights and add a learned bias: that is the box Wx + b, and W and b are parameters. Apply a fixed nonlinear function, sigma. Out comes h, a new list of numbers, ready to be the input of the next piece. If you read the formula aloud, read it as those four steps and say plainly that this is not “the equation for ChatGPT”; it is the smallest piece from which large networks are built. Large networks stack millions of these pieces in layers, and training sets the weights.

Transition: “Networks like this were predicting language before transformers. The question is how they handled a sequence.”

Deeper: Neurons, Layers, and Learning, which works one unit through by hand.

Neural language models came first; recurrence paid a price

Objective: state the recurrent constraint mechanically. Time: about 1.0 min (running total 8.5).

Point at the figure. For sequences, recurrent networks, including LSTMs, became the established approach. They read one position at a time and pass a running state forward. So information from token 1 reaches token 5 only through four sequential steps, and each step’s computation depends on the previous one having finished. Two costs: a long path between distant positions, and, during training, no way to compute the positions in parallel. Do not say “recurrent networks could not remember”; say the path was long and the computation was sequential.

Optional: neural language models predate transformers by many years; the website’s milestones page has the history and the citations.

Transition: “Attention is the mechanism that gave positions a direct path.”

Deeper: Why Transformers §1–§2; Vaswani et al. (2017) §1; Milestones for the history.

Attention: each position combines what it is allowed to see

Objective: explain what attention computes before the Transformer paper is named. Time: about 1.75 min (running total 10.25).

Point at “it”, the destination. The sentence on the slide is “The bridge closed because it”, shortened so that every token fits at projection size. Three steps. First, the model compares the destination with each source position it is permitted to use, and each comparison gives a score. Second, softmax turns those scores into weights that are nonnegative and sum to one; the weights on the slide are illustrative, and here “bridge” gets most of the weight and “because” the next largest share. Third, the model combines the sources’ vectors using those weights, and the combination updates the representation of “it”. That is the whole mechanism: a learned, weighted mixing of other positions, in one step, with no relay through the positions in between.

Two guard rails. The transformations that produce the comparison and the combined vectors are learned matrices, set by training; the weights themselves are computed for each input. And a weight is a local mixing number inside one head at one layer; real models run many heads in parallel and stack many layers, so no single weight tells you why the model said what it said.

Optional elaboration, if someone asks for the names: the destination is transformed into a query vector, each source into a key vector, and query-key comparisons give the scores; each source also provides a value vector, and it is the values that are combined. Attention came before the Transformer: Bahdanau, Cho, and Bengio used a learned weighted selection of this kind for translation in work presented at ICLR 2015.

Transition: “In 2017 one paper built the whole architecture around this mechanism.”

Deeper: How Self-Attention Moves Information; Vaswani et al. (2017) §3.2; Bahdanau et al. (2015).

Do not imply: that an attention weight is a probability that one token caused another, or that one head has a fixed human-readable job.

The Transformer: attention plus feed-forward, without recurrence

Objective: name the paper, state what it changed, and keep training parallelism distinct from generation. Time: about 1.25 min (running total 11.5).

Name it: Attention Is All You Need, Vaswani and colleagues, 2017. It built a sequence architecture around two computations per block: attention, which moves information between positions, and a feed-forward step, which is the network piece from the earlier slide applied to each position on its own. No recurrence. Point at the arcs: in one layer, any position can read any permitted earlier position directly.

Then the precision that matters. During training on a known sequence, the positions within a layer can be computed in parallel, because nothing waits for a previous position to finish. Generation is different: at use time the model still produces one token at a time. And the model is causal: a position never sees later tokens. One sentence on hardware: that parallel computation over matrices is exactly what GPUs do well, which is part of why the architecture spread.

Transition: “Now the numbers get their values. Pretraining.”

Deeper: Why Transformers §3–§6, including the cost of dense attention, which is not in the prepared route.

Do not imply: that attention alone is the Transformer, or that GPU compatibility is the whole explanation.

Pretraining: the text supplies its own answers

Objective: state the training loop with the three jobs kept apart. Time: about 1.5 min (running total 13.0).

Walk the chips. Token sequences from the corpus go in. At every position the model predicts the next token, and the text itself supplies the answer, because the next token is right there; no one labels anything. A loss measures how little probability the model gave to the token that actually came next. Backpropagation computes, for the trainable parameters, how the loss would change with a small change in them: the gradients. The optimizer uses those gradients to change the parameters by a small step. Then the next batch, and the next, on a scale that is hard to picture.

Say the three jobs explicitly: the loss measures, backpropagation computes gradients, the optimizer updates. 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.

Transition: “What is a base model, and what is it not?”

Deeper: How Pretraining Works §1–§5.

The base model is not a database and not yet an assistant

Objective: prevent two misreadings of the base model. Time: about 1.0 min (running total 14.0).

Three statements, one each. Because predicting text well requires capturing its regularities, the base model has broad statistical knowledge of grammar, meaning, recurring facts, and conventions of argument; models trained only to predict text have been observed to answer questions and translate without being trained for those tasks. Second, it is not a database that reliably retrieves records from its corpus, yet it can 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. Nothing in the objective checks truth. Third, it is not specifically optimized to behave as an assistant: given an instruction, it may answer it, continue it, or produce more instructions like it.

Transition: “Turning that into an assistant is more training, on the same numbers.”

Deeper: How Pretraining Works §6–§7; Carlini et al. (2021).

Do not imply: that the model cannot memorize or reproduce training text, or that it is a database you can query.

Post-training changes the same parameters with different data

Objective: establish post-training as training, and name the three routes. Time: about 1.5 min (running total 15.5).

Point at the three cards and say the invariant first: every card is the same loss-gradient-optimizer machinery changing the same parameter collection. What differs is the data and the objective. No new kind of network appears.

Card one is pretraining, already covered. Card two is supervised fine-tuning: curated conversations, a prompt and the response the builders want, trained with the same next-token loss on the response tokens, so that after training a request is treated as a request. Card three is a family: preference-based methods compare candidate responses and update the parameters toward the preferred one, through a learned reward model and reinforcement learning (the route usually called RLHF) or directly from the comparison pairs; reward-based methods use outcomes that can be scored. Providers combine and vary all of this, and published recipes also use model-generated data and feedback. A product’s system prompt is not post-training: it is text in the context.

Optional: the website’s post-training section carries a classroom analogy for the three stages (exposition, worked examples, practice problems), labelled as an analogy.

Transition: “So why can a fluent assistant still be wrong?”

Deeper: Post-training §2–§6; Ouyang et al. (2022); Rafailov et al. (2023).

Do not imply: that RLHF is a synonym for post-training, or that all post-training data is written by human labelers.

Why a fluent answer can still be wrong

Objective: give the correct causal story for unsupported answers. Time: about 1.0 min (running total 16.5).

Three statements. Pretraining rewards assigning probability to whatever came next in the text; nothing in it checks truth, so unsupported continuations are possible before any post-training. Post-training makes instruction-following and question-answering the default, so a well-formed answer can outrun what the parameters contain; post-training did not create the possibility of unsupported answers, it changed the default form of the response. The remedies: recipes can teach abstention, and retrieval and tools can ground an answer in inspectable evidence placed in the context. That evidence still has to be evaluated.

The sentence to leave in the room: fluency is not evidence.

Transition: “When you send a request, the trained model generates its response one token at a time. Here is that loop.”

Deeper: How Pretraining Works §7; Using Models Well §4–§6.

Do not imply: that post-training caused hallucination, or that a retrieved document makes an answer automatically true.

What happens when you type

Objective: follow one request through the generation loop. Time: about 2.0 min (running total 18.5).

Trace the figure. The product assembles and manages the context: its system prompt, the conversation so far, any documents or tool results it includes, and your message. The tokenizer turns that text into token IDs. Each ID selects its 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 one token, deterministically or at random from the distribution. That token is appended to the context, and the loop runs again. A paragraph of output is this loop, one token at a time.

Two sentences to close. Nothing in the parameters changes; the system prompt and supplied documents are context, not retraining. And, briefly, implementations cache the keys and values already computed for earlier positions rather than recomputing them each step.

Transition: “A reasoning-oriented model can use additional generation steps before producing its final answer. First, how such models are trained.”

Deeper: Softmax, Sampling, and Temperature; How Pretraining Works §9.

Some models are trained to reason longer on checkable problems

Objective: describe reasoning-oriented training as one route. Time: about 1.0 min (running total 19.5).

Some problems have outcomes that can be checked automatically: a mathematics problem with a known answer, code with tests. A checkable outcome can supply a reward without a learned reward model, and reinforcement learning against such rewards can encourage useful intermediate reasoning before the final answer. DeepSeek-R1 is one published example. Keep its two models apart in one sentence each: R1-Zero applied reinforcement learning directly to the pretrained base model, with no supervised fine-tuning step first, and its reasoning traces grew longer during training; the released R1 used a multi-stage recipe that also included supervised stages. This is one route used by some reasoning-oriented models, not a stage every model passes through.

Transition: “That is training. ‘Thinking longer’ also means something at use time.”

Deeper: Post-training §7; DeepSeek-AI (2025).

“Thinking longer” at inference spends computation, not training

Objective: explain inference-time reasoning mechanically and with its limits. Time: about 1.5 min (running total 21.0).

Point at the three rows. Row one: prompt in, answer out. Row two: the same model, with the same fixed parameters, generates intermediate reasoning tokens before its answer. Each intermediate token becomes part of the context that the next step conditions on, so the model gets more sequential computation before it commits. Nothing was retrained. Row three: the reasoning can produce a tool request, software runs the tool, the observation comes back into the context, and reasoning continues. Hold that row; it returns in three slides.

Then the limits. Providers expose this differently, as effort levels or thinking levels. What a product shows of the intermediate reasoning varies by model and interface, and a displayed explanation should not be treated as a guaranteed faithful record of the underlying computation. More reasoning is not a guarantee of a correct answer, and generated reasoning is output from the same mechanism as any other output, not thought in the human sense.

Transition: “The model can also use information supplied in the current context or returned by tools. Three different places can hold information for it.”

Deeper: Post-training §7; Anthropic, Google, and OpenAI reasoning documentation, accessed 2026-09-15.

Do not imply: that a displayed reasoning summary is a faithful account of every internal computation, or that all providers implement this the same way.

Parameters, context, and external state are different places

Objective: separate the three stores. Time: about 1.0 min (running total 22.0).

Left box: parameters, inside the model, changed only by training. Middle box: the context, the tokens supplied for this step, assembled or managed by the product. Right box: external state, files, databases, saved notes, kept by software outside the model and retrievable into a later context. Only the first is the model changing. A product that “remembers” your project across sessions stored something outside the model and supplied it again; no parameter was updated. All three get called “memory”.

Optional: the website adds a working-memory analogy here, labelled as an analogy.

Transition: “Now the grey box from the start: tools. One concrete example.”

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

One tool call: the model asks, software acts

Objective: teach tool use with one round trip. Time: about 2.0 min (running total 24.0).

Set the scene: someone asks, “What is the weather in Bogotá today?” The parameters cannot contain today’s weather, and a model call by itself does not read files, run programs, or search anything. Then walk the six cards. One, the context holds the request and a description of a weather tool: its name, what it does, the inputs it takes. Two, instead of inventing a value, the model generates structured output that means “call weather with location Bogotá”; that is generated text in a structured format, nothing more. Three, the surrounding software recognises the request, checks its permission rules, and runs the tool. Four, the tool returns a result; the value on the slide is invented for the example. Five, the software places the result into the model’s next context. Six, the model generates the answer, now resting on the result.

The boundary, said plainly: the model requested the action; software executed it; the result became new context. Purple cards are model output; grey cards are execution outside the model.

Transition: “Repeat that round trip under control, and you have an agentic system.”

Deeper: From Assistant to Agent §2–§3; Anthropic, Tool use with Claude documentation.

Do not imply: that the model itself ran the tool, or that the example weather is real.

Repeat the round trip under control: an agentic system

Objective: define the loop and the workflow-versus-agent distinction. Time: about 1.5 min (running total 25.5).

Walk the chips as a loop. An objective, the current context, and the current state go to the model. The model returns a tool request or a response. A request is checked against permission rules and executed. The observation goes into the context. The model is called again, and the loop continues, asks the user, or stops. The model does not run between calls; software carries the state.

Then the vocabulary, briefly. In a workflow, the sequence of steps is written in advance and the model fills in each step. In an agent, the model chooses which steps and tools to use, within limits set by the software. Neither is better in general, the simplest system that reliably solves the task is usually the right one, and the terminology is not standardised. Either way, an agent is a control pattern around the same fixed model, not a new architecture.

Transition: “One agent you may meet this year: a coding agent.”

Deeper: From Assistant to Agent §4–§6; Anthropic, Building effective agents (2024).

Do not imply: that “agent” means fully autonomous, or that a new neural network appears at this stage.

A coding agent: inspect, edit, run checks, revise, stop

Objective: make the loop concrete and end with verification and permissions. Time: about 1.5 min (running total 27.0).

Walk the chips with a story. A user says, “find why this script fails and fix it.” The agent requests a listing of the files and the failing script’s output; the software runs those and returns the traceback. The model reads it, requests one file, and proposes an edit; the software asks for approval, then applies it. The model requests the tests; the software runs them and returns the output. If a test still fails, the loop continues from the evidence; if the specified checks pass, it reports and stops.

Three closing points. Project instructions and skills are context loaded for the task, not retraining. Permissions live in the software: what runs automatically, what waits for approval, what is refused. And a passing test establishes only what that test checked; whether the right thing was built remains a human judgment. Claude Code is one current example of such a system; the mechanism is general.

Transition: “That is the whole route. One picture to keep.”

Deeper: From Assistant to Agent §8–§11; Claude Code documentation, accessed 2026-09-15.

Do not imply: that “done” in an agent’s output is evidence, or that giving an agent a skill retrains it.

The mental model

Objective: compress the talk into one statement and four consequences. Time: about 0.75 min (running total 27.75).

Say it slowly. A language model is a learned next-token predictor: code plus parameters, set by pretraining and post-training. Once trained, the parameters are fixed; what is specific to a request arrives through the context. Software adds tools, state, and a loop, and that loop of model step, action, and evidence is what turns a predictor into a system that carries out work.

Then the four consequences, one breath each. Fluency is not evidence. Tool use is not automatically verification. A passing check proves only what it tested. On judgment-heavy questions, evidence, review, and accountability stay with people.

Transition: “Everything here is on the website, with the mathematics and the sources.”

Deeper: Using Models Well.

Where to learn more

Objective: send people to the right next page. Time: about 0.25 min (running total 28.0).

Point to the Short Story first, then the lessons, the glossary, and the resources page’s video-first route. Read the address aloud once, since it is the one thing the audience will want to write down: leonelborjaplaza.github.io/llm-to-agents. Leave the slide up. The remaining two minutes of the slot are the reserve for pauses and small overruns, not a promised question period.

Deeper: the site’s home page.

A ChatGPT-like product is more than the model

Objective: backup slide, shown only if a question asks how the product differs from the model. Time: backup, not in the prepared route.

Point at the purple box in the middle: that is the model, the code plus parameters. Everything else in the grey product box is either green, meaning context that will be supplied to the model when it is called (a system prompt, the conversation, files), or grey, meaning software that acts around the model (retrieval, tools, safety checks, the interface). Two products can share the same model and behave differently, and a product can change tomorrow with no training run in between.

Deeper: Post-training §9.