AI Agent Visualizations
AI agent visualizations show the part that demos hide: an agent is not a smarter model, it is the same model run inside a loop that lets it act, observe, and try again. This collection animates that machinery step by step, so you can follow a proposed tool call through the harness to its result.
A language model on its own can only produce text. Turn that text into an action — a search, a calculation, a database query — feed the result back in, and let it react, and the same model starts to look like something that can get things done. That is the whole trick: an agent is a loop wrapped around a model, plus the tools it can call, plus the memory it carries between turns. These lessons take that loop apart so each piece is clear before you watch them run together.
What Makes a Model an Agent
Four capabilities turn a text predictor into an agent, and each lesson here is one of them:
- Tools. The model emits a structured call — a function name and arguments — instead of a final answer. Something runs it and hands the result back. This is the single primitive everything else builds on.
- A loop. Reason, act, observe, repeat. The model thinks about what to do, takes one action, reads what happened, and uses that to decide the next step — rather than committing to a whole plan blindly.
- Memory. The agent carries state between turns, and the context window is the bottleneck: what fits, what gets summarized, what gets dropped.
- Grounding. Retrieval pulls the relevant facts into context so the model answers from real documents instead of its frozen training data.
The Lessons, Around the Loop
| Lesson | What you watch |
|---|---|
| The agent loop | a while loop calling the model, running tools, and looping until the model returns text — the budget the only thing the harness decides |
| Tool calling | a model emitting a structured function call and consuming the result |
| MCP Plugin | external tool descriptions joining the host pool, a call routed through an MCP client, and the difference between a missing route and a failed lookup |
| Permission | allow, deny, and ask rules deciding which requested tools execute |
| Hooks | event and tool matching dispatching a callback before or after tool execution |
| ReAct loop | reason → act → observe repeating until the task is done |
| Context and memory | what the agent carries between turns, and the window filling up |
| System Prompt Assembly | runtime sources becoming system sections, tool definitions, and selected context; a listed skill or unread file does not supply its body |
| Error Recovery | a failed model call classified before any retry — wait, compact the context, raise the output budget, switch to a backup model, or stop and surface the error |
| Subagents | a Task call forking the same loop onto a fresh messages[] — the noise stays in the child, one result card comes back |
| Plan Before Acting | a checklist with completion conditions, a failed check, and a repair followed by fresh verification |
| Task System | a goal decomposed into a dependency graph, persisted to tasks.json — a crash costs one task, not the run |
| Background Tasks | a slow command detached to its own shell, the agent working through its own list while it runs, and the completion notification landing at a turn boundary |
| Agent Teams | a contract update crossing from one private context through a recipient mailbox, then an integration check of the API and UI artifacts |
| RAG | retrieving relevant documents and feeding them into the prompt |
A Recommended Learning Order
Start with the agent loop — the structure underneath everything else. An agent is a while loop that calls the model, runs whatever tool it asks for, and loops again until the model replies with text instead of a request; the loop never decides when the task is done, the model's stop_reason does. Once that shape is concrete, tool calling zooms into a single iteration of it: watching a model produce a structured call, pause for the result, and continue makes vivid that the model never runs the tool itself; it only asks. Permission then places a rule check before execution: the harness can allow, deny, or ask for approval, and an unanswered prompt leaves the request waiting. Hooks attaches a callback to a lifecycle event: change its event and tool matcher to distinguish prevention, a report after execution, and a missed call. Then the ReAct loop reads the same cycle as the model's reasoning — it reasons about what to do, acts, observes the outcome, and reasons again, so a hard task becomes a sequence of small, correctable steps instead of one fragile plan.
With the loop in hand, context and memory is the constraint that shapes every real agent: the model is stateless between calls, so everything it "remembers" has to be re-sent in the context window, and that window is finite. Watching it fill — and watching what has to be summarized or dropped — explains most of why agents behave the way they do. Subagents is the loop's answer to that constraint: hand a noisy exploration to a child loop with a fresh context and only the conclusion comes back — at the price that the child knows nothing you didn't write into its prompt. Plan Before Acting makes the intended work and its completion conditions explicit: compare a plan that follows evidence with one that checks off attempts despite a failed result. Where subagents split work across contexts, the task system splits it across time: the goal becomes a graph of small dependent tasks written to disk, so execution order falls out of the edges and a killed process resumes at the exact task it lost — instead of starting the run over. Background tasks put the same loop on a wall clock: detach a slow command and the agent can spend its runtime on work that does not need the output — but only that work, and it only hears that the process finished at its next turn boundary. Agent Teams then connects independent contexts: a peer message carries an API-field update that a completed task status alone does not supply. Compare the same tasks with and without that update, and check whether the UI can read the response. Error Recovery returns to one model call that comes back wrong: the harness classifies the failure first and repairs what caused it — or stops — because a retry without a repair is the same call again. Finish with RAG, the most common way to feed an agent the right facts: retrieve the documents that match the question, paste them into the prompt, and let the model answer from them — grounding its output in real sources instead of memory.
All AI Agent Visualizations
After Tool Calling, open MCP Plugin to follow the external execution route. Toggle the Notes integration while keeping the requested call fixed, then request a missing note: the first change removes a host route, while the second reaches a tool that returns an error.
Follow Context and Memory with System Prompt Assembly to inspect how a request acquires its contents in the first place. Compare a listed skill with loaded instructions, then turn memory loading on and check whether the private fact reaches the assembled request.
Pick any lesson below to open its interactive player, change the input, and step through the result.