Chapter 1 — How LLMs Work, and Prompting: LLM, RAG or Agent?

Course: GenAI and Agents Fast Track Prerequisites: basic Python (variables, functions, loops and lists); no earlier AI knowledge is needed.

What the reader can do after this unit:

• Run a short Python program that counts tokens and turns raw scores into next-token probabilities at different temperatures, and read the result
• Write a prompt that carries a clear instruction, a role and a few worked examples, and decide when to ask a model for its steps
• Classify a job as a plain LLM call, RAG, a fixed workflow or an agent, and say which job role builds it

Core question this unit answers: What is the difference between an LLM, RAG and an agent, and which one does a given job need?

Connections:

• Builds on: basic Python and everyday use of a chatbot
• Leads into: calling a hosted model through an API and getting output a program can trust (Chapter 2)

Student Notes — Chapter 1: How LLMs Work, and Prompting: LLM, RAG or Agent?

GenAI and Agents Fast Track · Chapter 1

Before you start

You need Python 3 and a text editor. The code in these notes uses only Python’s standard library, so there is nothing to install, no account to open and no key to paste. Run each snippet as you reach it; seeing the numbers change is part of the lesson.

Summary

This chapter gives you the working picture of a large language model (LLM) that every later chapter builds on. You learn what a model actually reads (tokens inside a limited context window), how it picks each next token from a set of probabilities that a setting called temperature reshapes, and how to write prompts that steer it with clear instructions, a role and a few examples. You then learn the three words beginners mix up most: an LLM answers from what it learned, RAG answers using your documents, and an agent plans steps and uses tools, and a fixed chain of prompts is a workflow rather than an agent. The chapter ends by placing you in a job role, the AI engineer, and by saying plainly how much maths you need to start. By the end you can look at a request such as “build a bot that answers staff questions” and say which of these designs it needs.

Key concepts

Term	Definition
Token	A small piece of text that a model reads and writes: a whole word, part of a word, a punctuation mark or a space. Models work in tokens, not in letters or sentences.
Context window	All the text a model can refer to when it writes a reply, including its own reply as it is written. It works like a desk of fixed size: only what fits on the desk can be used.
Next-token probability	The model gives every possible next token a share of 100%. The shares add up to 1 (100%), and the next token is chosen using them.
Temperature	A setting that reshapes those probabilities. A low value makes the most likely token dominate; a high value gives less likely tokens a better chance.
Prompt	The text you send to a model: your instruction, any context, any examples and the question itself.
System prompt and role	The standing instructions given before the user’s question, such as “You are a polite support assistant for an online shop”. A role narrows the tone and behaviour of the replies.
Few-shot examples	A small number of worked input-and-output pairs placed in the prompt so the model copies the format and style.
LLM	A large language model: a program trained on a very large amount of text that writes text one token at a time, each chosen from the tokens it rates likely to come next: usually by weighted chance, or always the most likely one when temperature is 0. On its own it answers from what it learned in training.
RAG	Retrieval-augmented generation: the program first finds passages in your own documents, puts them in the prompt, and the model answers from those passages.
Workflow	A fixed chain of steps, with or without model calls, where the programmer decides the order in advance.
Agent	A system where the model itself chooses the next step and which tool to use, repeating until the task is done or a limit is reached.
Vector	A list of numbers. A list of scores for four candidate words, such as [4.0, 2.0, 1.0, -1.0], is a vector.

Explanations

1. Tokens and the context window

Here is a reply from a support assistant after a customer pasted a long email thread into the chat. The very first message in the thread said the parcel was addressed to the wrong flat. The assistant answered:

“Sorry your parcel was late! Delivery delays happen during busy weeks. Please allow two more days.”

Nothing in the reply mentions the wrong address. The customer’s real problem was never read. Why? The thread was longer than the model could take in, and the first message was cut off. To see how that happens, you need two ideas: tokens and the context window.

Tokens. A model does not read letters or whole sentences. It reads tokens. Think of the way a child sounds out a long word in syllables, or of LEGO bricks: a short common word is usually one brick, while a long or rare word is built from several. In a made-up split for illustration, unhappy becomes un + happy (2 tokens) and where is my order? becomes where, , is, , my, , order, ? (8 tokens, because the spaces and the question mark count here). Real tokenizers split text differently from this toy example, but the idea holds. Providers describe a token as a word, part of a word, a character or even a byte, and one vendor’s documentation gives a rough rule for its own models of about four characters per token, or 100 tokens for roughly 60 to 80 words. Treat that as a rule of thumb for English, not as a fixed value for every model.

Why does this matter to you? Models read and write tokens, and the amount a model can handle at once is measured in tokens as well.

The context window. Paste a long manual into a chat and ask about its first page: if the first page did not fit, the model answers without it. The context window is the limit behind that: all the text it can look at while it writes a reply, and that includes the reply it is writing. Two ways to picture it:

• A desk of fixed size. You can only work with the papers that fit on the desk. A thick file arrives; the top pages fit, the rest slide off.
• A doctor reading the latest pages of a thick patient file. The allergy noted at the first visit is on page one. If only the last twenty pages fit on the desk, the doctor may never see it, and writes a confident prescription anyway.

The support reply above is exactly that: the first message did not fit, or got too little attention. A bigger window helps, but a bigger window is not automatically better. One provider’s documentation notes that as the number of tokens grows, accuracy and recall can degrade, so choosing what to put in the window matters as much as how much room there is.

A small calculation shows how to plan. Suppose a model has a window of 8,000 tokens (an invented figure for this example), you want to leave room for a 1,000-token reply, and your instructions use 500 tokens. That leaves 8,000 - 1,000 - 500 = 6,500 tokens for the customer’s thread. A thread of 7,000 tokens does not fit, and something has to be trimmed or summarised first.

2. Picking the next token: probabilities and temperature

Ask a chat model to finish “The capital of France is” ten times. Most runs give “Paris”. Ask it to finish “A good name for a bakery is” ten times and you get different names. The model is not rolling a die at random in the first case; it is giving “Paris” a very large share of the probability. To see how, we need probabilities and temperature.

Next-token probability. At each step the model scores every token it could write next and turns the scores into probabilities: shares that add up to 100%. Picture a spinner on a game board where each wedge has a different size. A large wedge is hit often, a thin wedge rarely, and one spin chooses the next token. For the France example, an illustrative set of shares might be: Paris 84%, Lyon 11%, Rome 4%, banana 1%. (These numbers are invented to teach the idea; they are not measured from any real model.)

Temperature. Ask the same question twice and you can get two different words back. Temperature is the setting behind that: it reshapes the wedges. Two pictures:

• A cautious diner and an adventurous diner. Both read the same menu. The cautious diner nearly always orders the house favourite (low temperature). The adventurous diner is willing to try the unusual dish (high temperature).
• A volume dial for surprise. Turn it down and the likeliest token dominates; turn it up and the thin wedges grow.

Provider documentation describes it the same way: higher temperatures give more varied and creative output, and lower temperatures give more conservative output that sticks to the most probable choices.

Here is the calculation, as a worked example. Each candidate has a raw score (a list of numbers, called a vector). Divide every score by the temperature, then turn the results into shares that add up to 1. Run this:

import math


def next_token_probabilities(scores, temperature):
    scaled = [s / temperature for s in scores]
    biggest = max(scaled)
    exps = [math.exp(s - biggest) for s in scaled]
    total = sum(exps)
    return [e / total for e in exps]


words = ["Paris", "Lyon", "Rome", "banana"]
scores = [4.0, 2.0, 1.0, -1.0]
for t in (0.5, 1.0, 2.0):
    probs = next_token_probabilities(scores, t)
    print(t, [f"{w}:{p:.3f}" for w, p in zip(words, probs)])

You should see “Paris” hold about 0.98 at temperature 0.5, about 0.84 at 1.0 and about 0.60 at 2.0, while “banana” climbs from almost nothing to about 0.05. Multiply a share by 100 to read it as a percentage: 0.839 is 83.9%.

Choosing a setting is then a question of the task: low for extracting an invoice number or classifying a ticket, where you want the same answer every time; higher for naming a bakery or brainstorming, where variety is the point. Two cautions. First, a low temperature does not guarantee identical output on a hosted service: one provider’s documentation says that even at temperature 0, identical inputs may produce different outputs across calls. Second, the setting is not available everywhere: at least one vendor’s documentation says that some of its newest models ignore custom temperature values. Check the documentation of the model you use.

3. Prompting that works: instruction, role, examples

First, a failure. A shop owner types:

“Write something about our refund policy.”

The model replies with four generic paragraphs about the importance of customer trust, with no policy in them. It did what was asked: it wrote something. The model could not see the shop’s policy, did not know who the text was for, and had no length or format to aim at.

A prompt is the whole text you send. Think of it as a brief to a brilliant new colleague who knows nothing about your shop. Official prompting guidance gives a simple test: show the prompt to a colleague with little context and ask them to follow it; if they would be confused, the model will be too. Three habits fix most weak prompts:

1. A clear instruction with the output stated. Say what to do, for whom, in what format and within what limit. Guidance says to be specific about the desired output format and constraints.
2. A role. A line such as “You are a support assistant for an online shop. Reply politely in two sentences.” focuses tone and behaviour. Guidance says a role in the system prompt focuses the model’s behavior and tone.
3. A few examples (few-shot). Show the model two or three input-and-output pairs. Guidance describes a few well-chosen examples as improving accuracy and consistency, and suggests 3 to 5.

A stronger version of the refund prompt:

You are a support assistant for an online shop.
Task: write a reply to the customer message below in at most two sentences.
Use only the policy text provided. If the policy does not cover the question, say so.

Policy: Items can be returned within 30 days if unused.

Example 1
Customer: Can I return shoes after 10 days if I wore them once?
Reply: Sorry, returns are only accepted for unused items, so worn shoes cannot be returned.

Example 2
Customer: Can I return an unopened jacket after 20 days?
Reply: Yes, unused items can be returned within 30 days, so you are still in time.

Customer: Can I return a lamp I have not unpacked, bought 45 days ago?
Reply:

The role sets the voice, the task line sets length and scope, the policy supplies the facts, and the two examples show the format. Read the two examples again: one says no and one says yes, so the model does not learn that every reply is a yes. Examples that all look alike teach the model a pattern you did not intend.

4. Asking for steps: when step-by-step helps and when it does not

A customer writes: “I bought 3 mugs at 12 each and a 9 shipping fee, then used a 10% discount on the mugs only. What do I pay?” A model that answers in one line sometimes writes a wrong total, because it jumps straight to a number. Asking it to work step by step lets it write the intermediate results first: mugs 3 x 12 = 36; discount 10% of 36 = 3.6; mugs after discount 32.4; plus 9 shipping = 41.4.

Two ways to see why asking for steps can help:

• Long division on paper. You do not do a long sum in your head in one go; you write the partial results down and use them.
• A chef reading the recipe aloud before cooking. Saying the steps out loud catches a missing ingredient.

Written steps are also something you can check. One provider’s guidance warns that extra reasoning slows the reply, so it is worth the delay mainly on problems with several linked steps; for anything else, it advises answering directly.

So it does not always help. For “Translate this sentence”, “Is this review positive or negative?” or “Give the capital of France”, there is nothing to work through, so step-by-step text only adds length, delay and cost. A simple rule: ask for steps when the answer depends on several dependent pieces (sums, rules applied in order, a plan); skip it for single-fact lookups, labels and rewrites. Some current models also offer a built-in thinking mode for multistep problems, so check what the model you use already does before you add the instruction.

5. LLM, RAG or agent

A shop owner asks an assistant: “How many days do customers have to return a lamp?” The assistant answers: “You have 60 days, as in most shops.” The shop’s real policy is 30 days. The answer is fluent, confident and wrong, because the model answered from what it learned during training and had never seen this shop’s policy. This failure is called a hallucination: text that sounds right and is not grounded in the facts. Three designs fix different parts of the problem.

An LLM answers from what it learned. Think of a closed-book exam: the student answers from memory alone. That is good for rewriting, summarising a text you paste in, translating, and drafting. It is weak for facts about your own business, because those facts are usually not in its training.

RAG answers using your documents. Think of an open-book exam: the student may look things up first. In RAG the program first retrieves the relevant passages from your documents, places them in the prompt, and the model writes its answer from them, often naming the page. One cloud provider describes it as making the model refer to an authoritative knowledge base outside its training data before it responds. Chapters 3 and 4 build this.

An agent plans steps and uses tools. Think of a contractor given the brief “the kitchen tap leaks”. The contractor decides to check the pipe, fetch a washer, fit it and test it, choosing each next step from what they find. An agent is a model that chooses the next step and which tool to call (a search, a database lookup, a function that sends an email), reads the result, and repeats until done or until a limit such as a maximum number of steps. Chapters 5 and 6 build this.

Workflow versus agent. Now the point beginners miss. Suppose your program always does three things in the same order: summarise the ticket, classify it, draft a reply. Each step may call a model, but you wrote the order. That is a workflow. One widely read engineering article defines workflows as systems where models and tools are orchestrated through predefined code paths, and agents as systems where the model dynamically directs its own process and tool use. So the test is: who chooses the next step? If your code chooses, it is a workflow. If the model chooses, it is an agent. A fixed chain of prompts is a workflow, however many prompts it has.

Two ways to hold the difference:

• A recipe card and a cook. A recipe card lists the steps in fixed order (workflow). A cook given only “make dinner for four with what is in the fridge” decides what to do next (agent).
• A bus route and a taxi. The bus follows the route its operator set. The taxi goes where the driver judges best to reach your destination.

Design	What answers or acts	Who chooses the next step	Use it when
LLM only	The model, from its training	Not applicable: one call	The task is on text you supply: rewrite, summarise, classify, translate
RAG	The model, from retrieved passages of your documents	Your code: always retrieve, then answer	The answer lives in your documents and you want it grounded and cited
Workflow	A fixed chain of calls and code	Your code	The steps are known in advance and always the same
Agent	The model, using tools	The model	The steps cannot be known in advance and the task needs tools

The same article adds a caution: for many applications, a single model call with retrieval and examples is usually enough, so start with the simplest design that does the job and add an agent only when the steps genuinely cannot be fixed in advance. Agents also need limits, such as a maximum number of steps.

Three real situations. Try classifying each before you read the answer after the dash.

1. A manager wants staff to ask questions about a 120-page leave policy and get an answer that names the page. Staff questions are about your documents, so this is RAG.
2. A developer wants every new support ticket to be summarised, then labelled, then answered with a draft, always in that order. The code fixes the order, so this is a workflow.
3. An analyst says “find out why last night’s report failed and tell me” and the system must decide whether to read a log, run a query or open a ticket, depending on what it finds. The model chooses the steps and tools, so this is an agent.

What this means for the design you pick:

If the request says	Start with	Why
“Rewrite”, “summarise this”, “translate”	An LLM call	The text is supplied; nothing to look up
“Answer from our documents” or “with sources”	RAG	The facts are in documents the model never saw
“Always do A, then B, then C”	A workflow	You can write the order down
“Figure out what to do and do it”	An agent, with a step limit	Steps depend on what is found along the way

6. Which job uses this course, and how much maths

Three roles that get confused. Picture one online shop. One person studies last year’s sales to explain why returns rose: a data scientist. Another trains a model that predicts which orders will be returned and keeps it running: a machine learning engineer. A third builds the shop’s support assistant on top of an existing model, with the returns policy as its documents and an order-lookup tool: an AI engineer. Job titles vary by employer, so treat the descriptions below as a map, not a rule.

• Data scientist. Helps an organisation make decisions from data: collecting and cleaning it, building statistical and machine learning models to analyse it, and explaining what it shows.
• Machine learning engineer. Builds and tests machine learning models and the software around them: training them and making them work reliably.
• AI engineer. Builds applications on top of models that already exist, reached through APIs or open models. One widely cited essay describes this as software engineers productionising AI APIs and open-source models, and quotes the remark that one can be quite successful in the role without ever training a model.

This course serves the AI engineer role: you will call models, give them your documents (RAG), give them tools (agents) and test the result. You will not train a model from scratch. Roles overlap in real teams, and this course states no hiring figures.

How much maths? In our view, as teaching guidance rather than a rule about every job, three small ideas are enough to start building LLM applications:

1. A vector is a list of numbers. You met one in the temperature code. In Chapter 3 text becomes a vector so that similar meanings sit close together.
2. Basic probability. Shares that add up to 100%, and “more likely” versus “less likely”. You used it in the temperature section.
3. Reading a percentage. 0.839 is 83.9%; “faithful on 18 of 20 answers” is 90%.

Deeper topics such as calculus or linear algebra matter if you move towards training models; they are not a gate for the projects in this course.

Flashcards

Say the answer aloud before revealing it. Speaking is a different skill from reading; practise both.

1. What is a token?

   • A small piece of text that a model reads and writes: a whole word, part of a word, a punctuation mark or a space. Models count and limit their work in tokens, not in letters or sentences.

2. What is the context window, and what happens to text that does not fit?

   • It is all the text the model can look at while writing a reply, including the reply itself. Text that does not fit has to be shortened or left out, and whatever is left out the model does not see, so the reply can be confidently wrong.

3. Why can a huge context window still give worse answers?

   • More text is not automatically better: as the number of tokens grows, accuracy and recall can degrade. Putting in the right passages beats putting in everything.

4. What does temperature do to next-token probabilities?

   • It reshapes them. A low temperature makes the most likely token dominate, so output is steady; a higher temperature gives less likely tokens a better chance, so output varies more.

5. Does temperature 0 guarantee the same answer every time on a hosted service?

   • No. One provider’s documentation says identical inputs may still produce different outputs at temperature 0, so write tests that tolerate small variation.

6. Name the three habits that fix most weak prompts.

   • A clear instruction that states the output (format, length, audience), a role such as “you are a support assistant for an online shop”, and two or three worked examples that show the format you want.

7. When does asking for step-by-step reasoning help, and when does it not?

   • It helps when the answer depends on several dependent pieces such as sums or rules applied in order. It does not help for single-fact lookups, labels and rewrites, where it only adds length and delay.

8. What is the difference between an LLM, RAG and an agent?

   • An LLM answers from what it learned in training; RAG first retrieves passages from your documents and answers from them; an agent plans steps and uses tools, with the model choosing the next step.

9. Is a fixed chain of three prompts an agent?

   • No, it is a workflow. It becomes an agent only when the model, not your code, chooses the next step and which tool to use.

10. Which job role does this course serve, and what does that person build?

    • The AI engineer, who builds applications on top of existing models using prompts, RAG, tools and agents, rather than training models from scratch.

11. How much maths do you need to start building LLM applications?

    • In our teaching view, three ideas are enough to start: a vector is a list of numbers, basic probability (shares adding to 100%), and reading a percentage. More advanced maths matters if you move towards training models.

Model answer

The core question this unit answers: “What is the difference between an LLM, RAG and an agent, and which one does a given job need?”

Five beats a good answer covers; hit all five, in this order:

1. LLM — answers from what it learned in training
2. RAG — retrieves from your documents, then answers from them
3. Workflow — a fixed chain of steps chosen by the programmer
4. Agent — the model chooses the next step and the tool
5. Choice — start with the simplest design that does the job

The full answer, said aloud:

(LLM) “A plain LLM answers from what it learned during training, so it is good at rewriting, summarising and drafting text I give it, but it can invent facts about my own business.

(RAG) RAG fixes that by first retrieving the relevant passages from my documents and putting them in the prompt, so the model answers from those passages and can name the page.

(Workflow) If my code runs the steps in a fixed order, such as summarise, then classify, then draft, that is a workflow, even if every step calls a model.

(Agent) It is an agent only when the model chooses the next step and which tool to call, and repeats until the task is done or a step limit is reached.

(Choice) So I ask who chooses the next step and where the facts live, and I start with the simplest design that does the job.“

Skip any of these five and the answer is incomplete. An interviewer or examiner who hears only “RAG uses documents and agents use tools” will ask next where a fixed chain of prompts fits. Practise until all five beats come out in order without notes.

Why this matters

On the job: a colleague who asks for “an AI agent” often needs a workflow or plain RAG. Naming the right design early saves rework and makes the system easier to test. A request that mixes the words is usually a request to ask a question back: “who decides the next step, and where do the facts live?”

In interviews and reviews: “what is the difference between an LLM, RAG and an agent?” is one of the most common opening questions for an AI engineering role. The five-beat answer above is built for it.

As a builder: token counts decide whether a prompt fits, and Chapter 2 shows how they show up on every API call, and temperature decides whether a pipeline gives steady or varied output. Both come back in every later chapter.

After this unit

Hands-on project. Three tasks: (1) write a small Python program that splits text into tokens using an invented vocabulary and checks each prompt against an invented context window; (2) compute next-token probabilities at three temperatures and say which temperature suits which job; (3) optionally, classify six jobs as LLM, RAG, workflow or agent. The full brief is in the project file.

What’s next. Chapter 2 sends a real request to a hosted model through an API, adds settings such as temperature to the request, and gets output a program can trust. Keep your token program and your temperature script: that chapter starts from the same ideas.

Hands-on Project — Chapter 1: Tokens, Temperature and Telling LLM, RAG and Agent Apart

Objective

Build two small Python programs that make a model’s inner workings visible (counting tokens against a context window, and turning scores into probabilities at different temperatures), then use what you learned to classify six jobs as an LLM call, RAG, a workflow or an agent.

What you need: Python 3 and a text editor. Tasks 1, 2 and 3 use only Python’s standard library and your own notes: no account, no API key, no paid service and no cost. Every vocabulary, window size and score in this brief is invented for the exercise; none comes from a real model.

You write every line yourself. This brief gives the facts and the checks; the finished programs and the right labels are not in it. Work through the tasks in order and check each output against its checks before moving on.

---

Task 1 — Count tokens and check they fit

Create tokens.py. It splits text into tokens using this invented vocabulary and rule.

Vocabulary (each entry is one token, and a single space is an entry):

the, a, (one space), order, ship, ped, ping, refund, s, un, happy, ly, was, is, late, your, ., ?, delay, ed, not, where, my, has

Rule: at each position in the text, take the longest vocabulary entry that matches there. If no entry matches, take that single character as one token.

The invented context window is 20 tokens, and 6 tokens must be kept free for the reply. Run your program on these three prompts:

1. where is my order?
2. the order was shipped late.
3. your refunds were unhappily delayed.

For each prompt print the list of tokens, the number of tokens, the tokens left after the prompt and the reply reserve are taken from the window, and the words fits or does not fit.

Scope: three prompts, not thirty. Stop once the table is printed and the checks below hold.

Checks:

• The table has exactly 3 rows.
• For each row, joining the tokens gives back the original text exactly, and the count equals the length of the token list.
• “Tokens left” is the window minus the reply reserve minus the prompt count, and a negative value is marked does not fit.

Output: the printed table (copy it into a file named tokens-output.txt) and your tokens.py.

---

Task 2 — Turn scores into probabilities at three temperatures

Create temperature.py. A model has scored four candidate words for the next token of the sentence “Your order has …”:

Word	Raw score
shipped	3.0
packed	2.0
delayed	0.0
purple	-2.0

To turn scores into probabilities at a temperature T: divide each score by T, raise e to the power of each result (math.exp), then divide each by the sum of all four so that the four shares add to 1.

Compute the probabilities for T = 0.5, T = 1.0 and T = 2.0. Print one row per temperature with the four probabilities to three decimal places, written as percentages in a second line.

Then write two sentences in temperature-notes.txt: one saying which of the three temperatures you would pick for a status message that must be steady and why, and one saying which you would pick for brainstorming ten subject lines for a sale email and why. Each sentence must quote one number from your table.

Scope: three temperatures and four words only. Stop once the checks below hold.

Checks:

• The table has 3 rows and 4 columns of probabilities.
• Each row adds up to 1 within 0.001, and every value lies between 0 and 1.
• As the temperature rises, the probability of the top-scoring word goes down; your table must show that for all three rows.
• Both sentences quote a number that appears in your table.

Output: the printed table, temperature.py and temperature-notes.txt.

---

Task 3 — Classify six jobs (optional)

For each job below, write one label from this list: LLM call, RAG, workflow or agent, and one reason. The reason must answer one of two questions: “who chooses the next step, my code or the model?” or “do the facts live in my own documents?”.

1. Rewrite a rough email so that it sounds polite.
2. Answer staff questions from a 120-page leave policy and name the page the answer came from.
3. For each new support ticket, summarise it, then label it, then draft a reply, always in the same order for every ticket.
4. Given a task and a set of tools (search orders, issue a refund, send an email), decide which tool to call, read the result, and continue until the task is finished or 8 steps have been used.
5. Translate a product description from English to Hindi.
6. Answer questions about a returns policy stored in a folder of PDFs, quoting the matching passage.

Then add two lines: the job role (data scientist, machine learning engineer or AI engineer) that builds these six jobs on top of existing models, and one maths idea from this chapter that you used in Task 2.

Scope: six rows and two lines. Stop there.

Checks:

• The table has exactly 6 rows, each with a label from the list of four.
• Each reason answers one of the two questions above in one sentence.
• Each of your two closing lines names a role and a maths idea.

Output: a 6-row table in a file named six-jobs.md and the two closing lines.

Keep six-jobs.md: Chapter 2 starts by sending a real request to a hosted model through an API, and its first request is one of the jobs you labelled as a plain LLM call. Keep tokens.py and temperature.py too, so you can reuse them as you build later chapters.