Stanford CME295 Transformers & LLMs｜ Lecture 7 - Agentic LLMs — Annotated Lecture Notes & Key Takeaways

Course Information

Institution: Stanford

Original Course: Stanford CME295 Transformers & LLMs | Autumn 2025 | Lecture 7 - Agentic LLMs

Instructor Bio: This lecture is co-delivered by **Afshine Amidi** and **Shervine Amidi**, adjunct faculty at Stanford University's Institute for Computational and Mathematical Engineering (ICME). Afshine Amidi earned his engineering degree from École Centrale Paris in 2016 and a Master of Science from the Massachusetts Institute of Technology in 2017. He currently leads LLM initiatives for promotional writing at Netflix, and previously held roles at Uber and at Google on the Gemini team. He co-authors widely used technical study guides on machine learning, transformers, and algorithms. Shervine Amidi holds B.S. and M.S. degrees in engineering from École Centrale Paris (2016), as well as an M.S. in Computational and Mathematical Engineering from Stanford University (2019). He is a Senior Machine Learning Engineer at Netflix, and previously worked at Google DeepMind on the Gemini team, Google Assistant, and Uber's data science division. He has served as a teaching assistant for multiple core Stanford CS courses and has been an adjunct lecturer at the university since 2021.

Course Description: This lecture examines the emerging paradigm of agentic LLMs — systems where language models act as autonomous agents capable of planning, executing, and iterating on complex tasks. It covers tool use and function calling, explaining how LLMs can invoke external APIs, execute code, query databases, and interact with software systems. The lecture explores agent architectures including ReAct (Reasoning + Acting), reflection and self-correction loops, multi-agent collaboration systems, and planning frameworks for long-horizon tasks. It also discusses the challenges of agentic systems, including error propagation, tool selection, reliability, and safety considerations for autonomous LLM-driven workflows.

Lecture 7 of Stanford's CME 295 is the one where the course finally lets the model out of the box. Everything before it treated the LLM as a sealed artifact: you train it, you prompt it, it answers from whatever got baked into the weights. This session — the agentic LLMs one — is about wiring that artifact to other systems, and it splits cleanly down the middle into two halves with two different lecturers. The first half (the captions render his name as both "Ashin" and "Afin," so treat that spelling as approximate) is a long, careful treatment of retrieval-augmented generation. The handoff happens around (59:27), and Shervin takes over for tool calling and agents. If you're working from the recording, that seam is the single most useful thing to know before you start.
These are my notes from the captions, not a transcript. Where I quote, it's short.
 

From Reasoning Models to Agentic LLMs: Two Different Weaknesses

The lecture opens with a recap of Lecture 6, which is worth two minutes of your attention because it sets up the framing. Last week was about reasoning models: instead of prompt-in, answer-out, the model produces a hidden reasoning chain first and then a response. The training algorithm behind that was GRPO — group relative policy optimization — which skips the value function and instead scores a batch of completions for the same prompt against each other, turning relative rank into an advantage. Two rewards did the work: one for emitting a reasoning chain, one for the quality of the final answer.

The interesting wrinkle, and the reason the recap isn't just housekeeping, is what happened to output length. On the AIME math benchmark the accuracy curve improved and then flattened, but the responses kept getting longer anyway. Digging into the loss term explained it: a token's contribution differs depending on whether it sits in a short or a long completion, so the objective quietly rewards verbosity. The lecturer called this length bias and pointed at two recent fixes — DAPO, which changed the normalization so it no longer depends on position within the sequence, and a paper called "GRPO done right," which just deleted the normalization term.

That recap exists to make a point about framing. Last lecture addressed one weakness of a vanilla LLM: weak reasoning. This lecture addresses two others. One, the model's knowledge is frozen at training time. Two, the model can't do anything. Those map onto the two halves of the session.
 

RAG Is Really a Retrieval Problem Wearing a Generation Costume

The motivating example is blunt. Suppose your pretraining data is a month old and you ask who won an election two weeks ago. The model either refuses or confabulates, because it has no channel to anything outside its own weights. This isn't a hypothetical quirk — it's why model cards publish a knowledge cutoff date. The example on screen was GPT-5, with a cutoff of September 30, 2024.

Then the lecturer does something I appreciated: he kills the two obvious workarounds before introducing the real one.

Why not just keep training on newer data? Two reasons. Editing what a model knows tends to break things it used to get right, which is a reliability problem practitioners generally refuse to take on. And it doesn't scale across use cases — if you've fine-tuned ten different variants off one base model, you'd now have to re-inject the new knowledge into all ten, which is a maintenance nightmare.

Why not just paste everything into the prompt? Three reasons, stacked. Context is finite — the room estimated a token at about four characters, which puts a few hundred thousand tokens in the neighborhood of a few hundred pages, a fat book. Not nothing, nowhere near enough. And even if context were infinite, there's the needle-in-a-haystack problem: stuff the prompt with irrelevance and performance degrades. The evidence shown was a heat map from GPT-4, plotting document depth against prompt length, and the failure mode was specific — on long prompts the model lost the planted fact most often when it sat in the first half of the document. Finally, cost. API calls are priced per token, on the order of a dollar per million for GPT-5, which is cheap in isolation and adds up fast if every query carries a book's worth of padding.

So: retrieval augmented generation. Fetch only what's relevant, paste that, generate. The name decomposes into the three steps — retrieve, augment, generate — and the lecturer says out loud what the structure implies: retrieval is where the effort goes, because if you fetch the wrong thing, the generation step is decorating a mistake. A student asked exactly this, and got a direct confirmation.
 

Building the knowledge base: chunks, embeddings, three knobs

You collect documents, split them into chunks, and embed each chunk. A chunk is a few hundred tokens of text, a subset of a document. Three hyperparameters dominate, and the lecturer presents each as a trade-off rather than a rule.

Embedding size: bigger captures more nuance, but costs space and inference compute. Typical values are in the thousands — he mentioned something around 1,500.

Chunk size: too small and the fragment has no context; too large and a single vector can't faithfully represent what's inside. Around 500 tokens is the common choice.

Overlap: adjacent chunks share some text, because the tail of one chunk is often needed to make sense of the head of the next. Low hundreds of tokens is typical.

A student asked whether you train your own embedding model. You can, but most people use a pretrained one.
 

Two-stage retrieval: cast a wide net, then look closely

This part is borrowed wholesale from search and recommendation systems, and the lecturer flags the lineage explicitly. Stage one is candidate retrieval — go from potentially millions of chunks down to maybe a hundred plausible ones, optimizing for recall, using a cheap operation. Stage two is ranking, or reranking since stage one already produced an order: take the hundred and put the genuinely relevant ones on top, using something more expensive.

Stage one runs on embedding similarity. Encode the query, compare against stored chunk vectors, usually by cosine similarity, keep the top hundred. Two details got called out. At scale you can't do a linear scan, so knowledge bases get partitioned for approximate nearest neighbor search — the lecturer mentioned the ANN family of techniques without going in. And the architecture has a name: bi-encoder, because query and chunk pass through the encoder independently and only meet at the comparison step. For grounding, he recommended the Sentence-BERT paper as an accessible read given the class already knew BERT.

But semantic similarity has a gap. Nothing in it enforces keyword overlap, so two things can match on meaning while sharing no words. Sometimes you need the opposite guarantee. Enter BM25, a heuristic score computed from term overlap between query and document. The illustration is the lecture's running joke: two teddy bears, one named Cuddly and one named Huggy. Ask where Cuddly is and pure semantic search may hand you Huggy, because they're near-synonymous. BM25 guarantees the returned text actually contains your term. Hence hybrids — combine embedding search with BM25 and tune the mix to the use case.
 

The awkward parts: short questions, long documents, orphaned chunks

Two problems sit in the middle of the RAG section, and both have imperfect fixes.

First, asymmetry. Your query is short and interrogative; your documents are long and declarative. Embedding both with the same encoder puts them in a space where they're not really comparable. The mitigation he offers is HyDE — generate a fake document from the query with an LLM call, then embed that instead. His own assessment is refreshingly unhyped: it may or may not work, not everyone uses it, worth trying.

Second, chunks torn out of context. A student raised this early, around (25:39), and the answer got deferred for something like fifteen minutes — one of the few places where the lecture's structure made the thread hard to follow if you were only half-listening. The eventual fix is contextual chunk headers: for each chunk, ask an LLM to write a short summary of what you'd need to know from the whole document to understand that fragment, and prepend it.

That's an LLM call per chunk, which is expensive, and the answer is prompt caching. Because these are decoder-only models running left to right, a shared prefix produces identical activations every time — so compute it once, store it, and look it up instead. Providers expose this directly: pricing pages list a separate rate for cached input tokens, roughly a tenth of the standard input price in the example shown. The practical takeaway he draws is about prompt hygiene: put the repeated material at the front so it can be cached.
 

How you know whether your retriever is any good

Stage two, reranking, uses a cross-encoder: query and chunk go into the encoder together, so attention can run between them and the model outputs a relevance score directly. The bi-encoder never let the two pieces interact; this one does. It's slower, which is fine, because you're only running it over a hundred candidates instead of a million.

Then metrics. The setup treats relevance as a binary label and asks how well your top-K matches ground truth. NDCG rewards putting relevant documents high — it sums over the top K positions, discounts by rank, and normalizes against the best achievable ordering for that query so a perfect ranking scores 1.0. MRR is cruder: take the rank of the first relevant document and invert it, ignoring everything after. Then precision@K and recall@K, the familiar classification ideas restated over the retrieved set. He pointed at the Massive Text Embedding Benchmark as the place people actually compare retrievers.
A follow-up on training the reranker with contrastive loss got waved through with a reading recommendation rather than an answer.
 

Tool Calling: Structured Data as Functions

Shervin's half starts from a distinction: RAG handles unstructured text, tool calling handles data with structure. If your data has defined inputs and outputs — think columns and rows — you can reframe lookup as a function call. Python dominates the examples purely because it's readable; nothing binds tool calling to Python.

He anchors on a definition from an IBM article, read aloud: tool calling lets autonomous systems complete complex tasks by dynamically accessing and acting on external resources. Two things matter in it — there's a task being completed, and it may lean on external resources. External isn't required.

The worked example is another teddy bear. "Find a teddy bear near me," asked on your phone — a bare model has no idea, and will tell you so. Tools are what let it answer. A student asked whether the functions are precomputed; yes, APIs are defined ahead of time and are not generated on the fly.

What the model sees is the function signature, its inputs and outputs, and the documentation. It does not see the implementation — that lives in your codebase. The loop has three stages. One: drop the API definition into the preamble; the model reads the query and predicts arguments, pulling on context like your device location if you've granted it. Two: execute the call, which has nothing to do with LLMs. Three: hand the structured result back so the model can render it in natural language instead of JSON.

Training that means two sets of SFT pairs. One maps API-plus-query to the right arguments. The other — and he stresses this — isn't just JSON-to-prose; its input is the entire conversation so far, so the model knows what was originally asked, that a tool was called, and that these results are the answer to that call. You want the examples varied enough to cover the real distribution: implicit location, explicit location, mid-conversation requests.

Then a genuine alternative. Modern models are steeped in code, so maybe you don't need SFT at all — maybe a good explanation suffices. Few-shot works but generalizes poorly, since fixed input-output samples fit some cases and not the breadth of what people actually type. Better: make the model reason.
Writing that reasoning prompt by hand is miserable, so the trick is to reuse your SFT pairs as an evaluation set, run your candidate explanation against them, collect the failures, and feed the wins and losses back to a strong reasoning model with instructions to revise. It's an offline loop that produces a fixed prompt reused at inference. He claims the results are surprisingly good and advises writing at most a first draft yourself.

Tool categories, briefly: informational (search, weather, stocks), computational (turn the query into code, run it, read the answer — sidestepping the model's arithmetic entirely), and action-taking, where the tool can send the email rather than draft it.
 

Too many tools, and MCP as the plumbing standard

Real systems expose many tools, and dumping them all into the preamble recreates the haystack problem — APIs get lost, definitions conflict, and the model ends up mediocre at everything. Context is finite, and if you're serving millions of users you can't fit every possible tool anyway. On top of that, tool definitions were bespoke per model, so you'd reimplement the same tool for every LLM.

Tool selection addresses the first. Citing a Google DeepMind technical report: show the model a query plus a list of tool names with a word or two of description each, have it pick the plausible ones, then load only those full API definitions into context. He notes the literature also calls this routing. A student asked whether this is just RAG — and the answer is that it could be, but doesn't have to be.

Standardization is MCP, the Model Context Protocol, from Anthropic. The vocabulary: an MCP server exposes tools; tools are the function implementations; prompts are templates showing how to use them; resources are external databases they draw on. An MCP client sits in the LLM host, one-to-one with a server. The example is a book provider running an MCP server with find-book and recommend-book tools, while Claude acts as the host.
 

Agents, ReAct Loops, and the Safety Bill

Agents are defined as systems that autonomously pursue a goal and complete tasks on a user's behalf — one layer above tools, because reasoning and iteration are built in. The structure isn't disjoint from what came before; tool calls and reasoning chains both live inside it.

The canonical pattern is ReAct: decompose a goal into steps and loop over them. The lecturer labels the stages observe, plan, act, and notes the paper uses think, observe, act — the labels drift between papers while the shape stays put. The example: your teddy bear is cold. Observe reframes that as a temperature problem with an unknown value. Plan decides the room temperature must be determined. Act calls get_current_room_temperature. Observe reads the result — 65°F, colder than expected. Plan decides to raise it. Act calls the thermostat with an increment. Observe confirms, the loop exits, and the model reports back that it raised the temperature by five degrees.

Multiple agents come next, which needs its own protocol: Google's Agent2Agent, released earlier in the year, where agents advertise skills, report execution status, and support cancellation. A student's point about token budgets gets a shrug — agents don't eat each other's budgets, just yours.

Safety arrives late and fast. Once models can act, a harmful actor can act through them. The example is data exfiltration: an email tool plus a prompt telling it to mail your password somewhere. Two classes of remedy — harmlessness data mixed into SFT and RL, and inference-time safeguards like a safety classifier scoring the conversation. He recommends a paper called ToolSword and the Agent Safety Bench, and cites Anthropic's disclosure, the day before, that it had been the victim of a large-scale cyber attack carried out through Claude, published with a detailed step-by-step report.
 

Where I Found the Argument Thinner

A few things I'd want pushed harder.

Tool selection is presented as the fix for tool overload, and the lecturer literally asks the room whether everyone's convinced — then treats the nodding as settled. But a selector that sees only a name and a one-line description is a recall problem with less information than the retriever had, and it's now a single point of failure: drop the right tool at that stage and nothing downstream recovers. The student who asked "is that basically RAG?" was onto something, and the answer deserved more than "you could."

The evaluation discussion also assumes ground-truth relevance labels exist. Nobody says where they come from, how many you need, or what it costs to get them — which is the part that actually bites when you build one of these.

And the safety close is oddly sunny given what precedes it. "It's not a lost battle" sits awkwardly next to the attack he just described in the same breath.
Two smaller notes. HyDE is hedged by the lecturer himself, so file it under "try it and measure." And the chunking question raised around (25:39) doesn't get answered until roughly (40:00) — if you were confused in the moment, you weren't missing anything.
 

The Closing Advice, and Why Coding Comes Up Last

The final minutes turn practical, and they're the most useful part if you're about to build something.

Agents fail by drifting — one bad argument prediction, one misread tool output, and the whole chain goes somewhere useless. That, per the lecturer, is why large-scale agents aren't running everything yet, and his preference is to close reasoning gaps with a better model rather than patching them with SFT. Evaluation gets deferred to next week.

Build advice: start small, on one simple case, and confirm the thing works before generalizing. Start smart too — begin with the most capable model available so you can see the headroom, then trade down for latency and cost once you know what's achievable. When it breaks, read the reasoning chains; that's where the failure is visible.

His favorite current use of agentic LLMs is coding assistants, for offloading the plumbing work around a project. The caveat is the line I'd actually write down: generating code is cheap now, and judging whether code is correct is the hard part, which means learning the foundations still matters. Your taste is the bottleneck.

Which, coming back to the through-line of the whole session, is the same lesson as RAG. Give the model better inputs — whether retrieved documents, tool outputs, or its own reasoning — and what's left for you is deciding whether the result is any good.