The Anatomy Every Agent Shares
Prerequisite: Lesson 01, "The Question Nobody Asks Before Building." If you've also taken Tools, Memory, and Multi-Agent Systems, its lesson 04 already covered the agent loop and tool-calling mechanism in full. This lesson revisits that ground briefly, on the way to the two-axes framing lesson 03 builds next. After this lesson, you can: name the five parts every agent architecture shares, explain why a tool call is text your code parses rather than an action the model performs, and read a context-window budget or a token-snowball table well enough to know when an agent's economics are about to break.
Tool calling is just text
Here's the picture people carry around, usually without examining it: the model reaches out and does something, clicks a button, hits an API, takes an action in the world. It's a clean mental image, and it's wrong in a way that matters for everything downstream of this lesson.
Here's what happens instead. The model outputs a raw string, something like {"tool": "classify_ticket", "input": {"ticket_id": "T-4829"}}. Your code parses that string with json.loads. Your code then executes the real function, classify_ticket, with the parsed argument. The model never touched your system. It wrote a wishlist in text. Your code is the only thing that ever acted.
That single fact is what every architectural difference in this course is built on top of. Security boundaries, cost trade-offs, reliability guarantees: all of it lives in the layer between "the model wrote a string" and "your code decided what to do with it." A model that can only write text cannot, by itself, exceed the permissions your parsing-and-execution layer grants it. That's not a limitation to work around; it's the entire basis for building anything safe.
The five parts, named once
That single fact, the model writes text, your code acts, is built out of five parts, and every agent you'll meet in this course, the always-on background loop and the bounded conversational one alike, is built from the same five, wired together the same core way. Naming them once here means lesson 03 can spend its words on how they diverge instead of re-explaining what they share:
Receives context and generates text, and never executes anything on its own.
Breaks a goal into sub-steps and decides when the goal is met.
APIs, shell access, file writes, web search: the model requests them, your code runs them.
Split into in-context (this call only) and persistent (files, databases, stored state).
Plans, acts, observes the result, and repeats until done or stopped.
If you've taken Tools, Memory, and Multi-Agent Systems, this will sound familiar on purpose. Its lesson 04 named this same anatomy and the same Think-Act-Observe loop, down to the line "the LLM does not do things, it suggests what to do." That's not a coincidence; it's the same underlying mechanism, and we're not re-deriving it here so much as picking it back up as a foundation. What's new starts in lesson 03, once this anatomy is in place: the two axes that determine how these five parts get implemented differently across architectures.
The loop runs because your code keeps calling the model with new context, not because the model has anywhere it wants to go. That distinction is the thesis this whole course sits on: agency is a property of the architecture wrapped around the model, not a property of its weights.
What actually fills the context window
Once you take tool calling seriously as "text in, text out," the context window stops looking like a chat transcript and starts looking like a budget. A typical agent turn is not mostly the user's message:
| What fills the window | Share of a typical turn |
|---|---|
| Prior conversation history | ~28% |
| System prompt (identity, instructions) | ~22% |
| Retrieved documents (RAG, knowledge lookups) | ~20% |
| Tool definitions (every schema the model might call) | ~18% |
| The actual user message | ~12% |
Figures per this course's own source measurement, not a universal constant. Your own budget will shift with how many tools you register and how much history you carry. The user's question is still the smallest thing in the room in every version of this breakdown.
Tool schemas count against that budget even on turns where no tool gets called: the model has to read the full menu before it can decide not to order. This course's own measurement found three typical MCP servers consuming 70% or more of a 200K-token window in schema alone, before the agent has done anything. "Just add more context" stops sounding like a strategy once you see what's already sitting in there.
The token snowball
The budget problem compounds turn over turn, because every turn re-sends the full history. In this course's own measured example, a five-turn task starts at 164 tokens on turn one and grows to 306 on turn two, 430 on turn three, 560 on turn four, and 619 on turn five: 3.8 times the cost of turn one, for the same underlying task. A verbose response on turn one is paid for again on every turn after it. A bloated tool definition is paid for on every call, forever.
That compounding is why this course's own comparison puts a single agent loop at roughly 4x the token cost of a standard chat exchange, and a multi-agent system at roughly 15x. Treat both multipliers as this course's own working estimate for planning a budget, not a benchmark you can cite independently.
Context caching — stop re-paying for a stable system prompt on every turn. Chain-of-draft — terse intermediate reasoning instead of verbose scratch-work the model pays to regenerate. Tool routing — inject only the three to five schemas relevant to the current step, not all fifty your agent knows about. Lesson 07 comes back to this when we price out a specific quadrant's economics.
Context rot: the thing window-size marketing doesn't mention
A bigger context window looks like it should solve the budget problem. It doesn't, and the reason is worth carrying into every lesson that follows. Attention is finite. A 1M-token window means the model can accept a million tokens as input. It does not mean the model attends to all of them equally. This course's own testing across GPT-5.2, Claude 4.6, and Gemini 2.5 found the same pattern in every frontier model tested: retrieval accuracy on needle-in-haystack tests starts dropping around 50,000 tokens of noisy content, well short of any of their advertised limits. That finding is scoped to the models and tests this course ran, not a claim about every model in the field.
For an always-on agent, this isn't an abstract benchmark result. An agent running for hours accumulates context turn by turn, and by turn forty it can behave as though it's forgotten the goal you gave it in turn one. Not because those tokens were deleted, but because attention has diffused across everything that arrived after them. The fix isn't a bigger window; it's compaction, periodically summarizing older turns into structured notes and resetting the working context. OpenClaw, IronClaw, and Claude Code all ship compaction for exactly this reason: without it, a long-running agent degrades on a clock, regardless of how large its window is.
Three definitions, one thing in common
Three people who've thought hard about this in public define "agent" differently, and the differences are instructive. Andrej Karpathy: "An LLM given tools and memory that can loop until a task is complete." Harrison Chase of LangChain: "A system that uses an LLM as a reasoning engine to determine which actions to take." Anthropic: "AI models that operate with greater autonomy, execute multi-step tasks, and work within larger systems."
Line them up and notice what none of them says: none says the model wants anything. Karpathy says the system "can loop." Chase says it's used "to determine which actions to take." Anthropic says it "operates" with autonomy. Agency, in all three definitions, is implicit in the architecture surrounding the model, not in the model itself. That's the same claim this lesson opened with, stated three independent ways by three people with no reason to coordinate their phrasing.
Put the five parts together and you get this course's working shorthand: Agent = LLM Brain + Planning + Tools + Memory + Loop. Every architecture from here forward is a different set of implementation choices layered onto that same equation, which is exactly where lesson 03 picks up.
The two axes that turn this shared anatomy into different architectures, and the 2x2 quadrant framework the rest of this course is built on.
Reply here and it goes straight to Rod. Same as replying to one of his emails.
