Anatomy of an Agent

Start with the trap almost everyone falls into: believing the model is the agent. It isn't. The model is one part — the reasoning core — and on its own it can only produce text. What turns a model into an agent is the machinery wrapped around it that lets it act, remember, and keep going until a goal is met.

The cleanest way to picture this is a body. The model is the brain: it decides. But a brain in a jar can't do anything. It needs instructions (its values and goals), tools (hands to act on the world), memory (to carry context from one moment to the next), and an orchestration loop (the nervous system that connects perception to action and back). Take any part away and the agent stops being an agent — no tools and it can only talk; no loop and it acts once and halts.

This framing isn't academic. As of 2026 it maps cleanly onto every major framework and even onto the formal research literature, where an agent is written as a tuple of policy, memory, tools, verifiers, and environment. The practical payoff is large: when you see an agent as five separable parts rather than one inscrutable blob, you can reason about it, test each piece, and find bugs fast.

In plain terms: each component answers one question. Who is doing the thinking? The model. What is it trying to do and how should it behave? The instructions. What can it actually touch in the world? The tools. What does it remember? The memory. What keeps it running and stops it? The orchestration. Hold those five questions in your head and you have the whole anatomy.

Here it is in one table. Internalize it — the rest of the course is detail on each row.

Three subtleties to notice. Instructions are broader than "the system prompt" — in production they include tool descriptions, injected examples, and any retrieved context, because all of it shapes the model's behavior. Memory is layered, not a single thing: the immediate context window, a conversation store, and long-term knowledge are three different mechanisms. And orchestration is far more than a while loop — it owns stopping conditions, token and cost budgets, retries, and loop detection. Each row is a place where an agent can succeed or fail independently of the others.

So far the five parts look like a static diagram. They aren't — they're a pipeline a single request runs through, often many times in a single turn. Picture passing a baton: each component does its job, then hands the growing message history to the next. Here is the exact path:

1. Instructions are injected into the context window: the system prompt, the available tool schemas, and any relevant memory.
2. The model reasons over that context and emits one of two things: a final text answer, or a tool call (a structured request like search(query="...")).
3. If it's a tool call, the orchestrator executes the tool and captures the result.
4. The result is appended to memory (the message history) so the model can see what happened.
5. The loop repeats from step 2, now with the new observation in context.

It stops when the model produces a text-only answer (it's done) or when a budget guard fires — max iterations, max tokens, max cost, or a timeout. That stopping logic lives in orchestration, not in the model, which is exactly why it's reliable: you never trust a non-deterministic model to decide when to quit.

Notice how each component touches the request in turn, hands off cleanly, and reads from a shared, growing message history. That history is the working memory, and keeping it clean is half the battle in real agents.

Why bother keeping these five parts distinct? Because when something breaks, you want to know which thing broke — not stare at a wall of logs guessing. That's the whole architectural payoff: clean separation makes failures isolatable. A tool failure is not a model failure is not a memory failure. When each component has defined inputs and outputs, you can point at the broken one.

The practical test is mockability: if your parts are cleanly separated, you can swap any one for a fake and test the rest. A "mock" here just means a stand-in that returns a fixed, predictable result instead of doing the real work.

# Test the orchestration loop without spending tokens or hitting APIs
def fake_model(messages):
    # Always asks for the calculator once, then answers
    if not any(m["role"] == "tool" for m in messages):
        return ToolCall("calculator", {"expr": "2+2"})
    return FinalAnswer("The result is 4.")

def fake_calculator(expr):
    return "4"

# Now exercise the loop, budget guards, and history handling in isolation
run_agent(model=fake_model, tools={"calculator": fake_calculator}, goal="2+2?")

Because run_agent only depends on interfaces (a callable model, a dict of tools), you can verify stopping conditions and history management with zero network calls. The same logic lets you mock a flaky tool to test error handling, or replay a fixed message history to test the model's behavior deterministically. Agents are non-deterministic; clean seams are how you make them testable anyway.

Here's the news that makes every framework suddenly easy: they are all the same five parts in different clothes. Each framework is just an opinionated way of assembling model, instructions, tools, memory, and orchestration. The vocabulary changes; the anatomy doesn't.

The lesson is liberating: learn the anatomy once and every framework becomes legible. Open the OpenAI Agents SDK and see Agents, Handoffs, Guardrails, Sessions, Tracing, and you can immediately place each one — Guardrails and Sessions are instructions and memory; Handoffs are an orchestration pattern. Frameworks earn their keep by providing the hard parts — state management, checkpointing, tracing, human-in-the-loop — that are tedious to build correctly. Anthropic's caution isn't "avoid frameworks"; it's "don't use them as black boxes you can't reason about."

Now the real reason to learn the anatomy: debugging. When an agent misbehaves, the symptom usually points straight at one component — because each part fails in its own characteristic way. Learn the signatures and you stop guessing.

• Model — hallucination, goal drift, and compounding errors that grow over many turns. Research on long-horizon tasks shows context reliability degrades significantly as the number of steps increases, with earlier instructions and observations becoming progressively less influential by the final turn.
• Instructions — ambiguous or conflicting goals that cause wrong actions or, worse, infinite loops where the agent can never decide it's done.
• Tools — malformed arguments, schema mismatches, API timeouts, and dangerous side effects. Anthropic's “Building Effective Agents” guide found that teams spent more time on tool schemas than on prompts; typed (Pydantic/JSON Schema) arguments sharply cut malformed calls.
• Memory — context overflow, stale embeddings, low-quality retrieval, and prompt injection hidden inside retrieved content.
• Orchestration — missing budget guards causing runaway loops, routing errors in multi-agent setups, and race conditions.

So when an agent misbehaves, resist debugging "the agent." Ask: which component? A wrong-but-confident answer points at the model or instructions; a crash on a tool result points at tools or schemas; an agent that forgets what it did points at memory; an agent that never stops points at orchestration. The symptom is the map.