AI
Record the agent, don't script it
The textbook ReAct diagram is a tidy little fiction. When I ran a real model on the same task, it didn't reason out loud or stumble and recover — so I stopped scripting my AI lessons and started recording them. The lesson changed because the recording refused to match my plan.
Every explanation of an AI agent starts with the same diagram: a loop labeled Thought → Action → Observation, arrows curling back on themselves. The model thinks out loud, decides on a tool, calls it, reads the result, thinks again. It's a beautiful diagram. I sat down to animate it, beat by beat, and ran straight into a problem: on the current model and task I tested, the diagram was no longer what the run looked like.
The classic traces — the ones in the papers, the ones every tutorial reuses — come from early instruction-tuned models that genuinely narrated a clumsy, visible chain of reasoning, took a wrong turn, noticed, and backtracked. That stumble-and-recover arc is the whole drama of the canonical ReAct example. It is also, on a current model running a toy task, frequently gone. Ask a modern model to look up two facts and combine them and it will often just... do it. No agonizing. No visible backtrack. The tidy loop collapses into one confident step.
So I had a choice, and it was the same choice the project kept forcing on me in different forms: animate the diagram, or animate the truth.
Scripting teaches a model that isn't running
If I'd hand-authored the trace — typed out a plausible Thought, a plausible wrong Action, a plausible recovery — the animation would have looked great and taught a lie. A learner would walk away with a mental model of agent behavior calibrated to 2022, then open a real API, send the same prompt, and watch none of it happen. That's worse than teaching nothing. A confident wrong model is expensive to unlearn.
This is the same standard I hold every algorithm lesson to: the thing on screen has to be the thing that actually happens. For a sorting trace that's easy — the algorithm is deterministic, you just run it. For an agent it's harder, because "what actually happens" is a property of a specific model on a specific day, not a textbook. The honest move is to go get that data instead of inventing it.
So I record real runs
The lessons for the ReAct loop and tool-calling are now built from recorded executions of a real model, not from a screenplay. The practice is mundane, and that's the point: run the model on the task, capture exactly what it did — every tool call, its arguments, and the result it actually got back — and keep each run isolated and reproducible, so a recording is a fact you can re-derive rather than a one-off anecdote. That captured sequence becomes the lesson, replayed with the same scrub-anywhere trace model everything else in VizLearn uses.
The payoff: a recorded trace cannot silently invent the run. It can still be unrepresentative — a recording is one run, not a distribution — which is why I label the model, the date, and how the run was picked. The runs behind these two lessons are claude-opus-4-8, recorded 2026-06-17, one curated sample per case. If the model called the wrong tool, the lesson shows the wrong tool. If it one-shot the task with no drama, the lesson shows that too.
Pilot the phenomenon before you promise it
Recording solved honesty. It also broke my lesson plan, which turned out to be the more useful result.
I'd storyboarded the ReAct lesson around "watch the agent reason, slip, and correct itself" — because that's the famous beat. Before committing to that storyboard, I ran a pilot: just execute the real task a bunch of times and see whether the interesting phenomenon actually shows up. It mostly didn't. The act-only runs came back correct, and boring — the model did the right thing without the visible struggle the script depended on.
That's a failed hypothesis, and failed hypotheses are cheap if you check them early and ruinous if you find out after the animation is built. The habit I kept from this for agent lessons: pilot the phenomenon first, promise it second. If the model won't reliably produce the thing you wanted to teach, you don't get to teach it — you get to teach what it does instead.
What the recording actually teaches
When the drama you planned for doesn't materialize, the data is telling you the lesson is somewhere else. For the agent loop, the real lesson stopped being "look at the reasoning" and became auditability.
The thing worth understanding about agents in production is exactly what a recorded trace makes visible: the value of the loop isn't that the model thinks pretty thoughts. It's that every step is a concrete, inspectable event — this tool, these arguments, this result — that you can read after the fact and check. An agent run is a log you can audit, not a mind you have to trust. The modern model that quietly does the right thing is still emitting that log, and being able to read it is the difference between an agent you can ship and a party trick.
So the lesson now lights up each tool call as it happens, pins the arguments next to the result, and lets you step through the run like a transcript — because that auditable transcript is the skill. I set out to animate a model reasoning and ended up teaching people to read what an agent did. The recording made me a better teacher by refusing to cooperate with my plan.
Don't animate the diagram
The pattern I took from this is the agent-shaped version of the debugger argument: the diagram is the map, and the map is out of date the moment models change. The run is the territory. Animate the run.
See it: open the ReAct loop or tool-calling and step through a recorded execution — every tool call and its real result, in the order they actually happened.