1.4 Agent Patterns and Abstraction Frameworks
1.4.1 The Tool-Use Loop, Revisited
Lesson 1.3 walked through the tool-use loop as an implementation detail -- how you actually build it, by hand or with the SDK. This lesson steps back and treats it as what it really is: the single recurring pattern underneath every agent you'll ever build, regardless of framework. The model emits a tool_use block, the harness executes it, a tool_result comes back, and the model continues from there. Every step in that cycle is grounded in real environment feedback, not just the model continuing to talk to itself.
tool_use -> execute -> tool_result -> continue. Whether it's the Agent SDK, a hand-rolled harness, or a third-party framework underneath, this is the cycle being implemented.
The one idea to hold onto
Every framework you'll meet in this lesson -- LangGraph, PydanticAI, Strands, the Claude Agent SDK itself -- is a different wrapper around this same tool-use loop. Recognizing the loop inside the wrapper is what keeps a framework from feeling like a black box.
1.4.2 Memory: State That Survives the Session
Memory is persisted state that survives across turns or, more importantly, across sessions -- a scratchpad file the agent writes progress notes to, an external store it reads from and writes back to. The point of memory is that the agent isn't limited to whatever fits inside one context window; it can pick up work in a brand-new session and still have access to what it learned or decided last time.
1.4.2 -- Key Concept
Memory is distinct from in-session context management. Memory survives across sessions -- outside any single context window entirely. Context-window management (next note) operates within one session's window. They solve related but genuinely different problems, and the exam expects you to keep them separate.
1.4.3 Skills as a Complementary Memory-Adjacent Pattern
Memory (the previous note) persists state -- what happened, what was decided -- across sessions. A Skill solves an adjacent but distinct problem: it persists know-how, and it does so with a cost profile unlike either memory or an always-loaded instruction file. A Skill is reusable markdown -- a SKILL.md file with YAML frontmatter (at minimum a name and a description) plus an instructions body underneath. On every turn Claude scans the name and description of each available Skill against what the current task needs, and only pulls the full instruction body into context on a match. If nothing matches, the instructions never enter the context window at all.
---
name: quarterly-report-formatter
description: Use when drafting or reformatting a quarterly business report to follow the company's standard structure and section ordering.
---
# Quarterly Report Formatting
1. Open with a one-paragraph executive summary...
2. Follow with sections in this fixed order: Revenue, Costs, ...
3. Every table must include a prior-quarter comparison column.
That load-on-demand behavior is what separates a Skill from something like a CLAUDE.md-style always-loaded file. An always-loaded file is resident in every conversation turn regardless of task, paying a fixed context tax on every session whether or not it's relevant. A Skill pays almost nothing -- just the name and description -- until the moment it's actually needed, then pays the full cost only for that turn. This makes Skills a lever for packaging reusable procedural knowledge without inflating the context budget of every session that doesn't need it.
Skills are usable directly on the Messages API too, not just through Claude Code or the Agent SDK, but the beta integration requires two beta headers set together: code-execution-2025-08-25 and skills-2025-10-02. A Skill invoked this way runs inside the code-execution container rather than in your own application's runtime -- which matters for what tools and filesystem access the Skill can assume it has.
1.4.3 -- Key Concept
Sharp, testable asymmetry: subagents do NOT automatically inherit Skills from a parent session -- each subagent starts with a clean context, and a Skill it needs must be explicitly listed in the subagent's own configuration. But subagents DO inherit the parent session's permission and tool-access context -- permission scope is not reset at delegation. Skills reset to a clean slate; permissions carry forward. That asymmetry, not a blanket 'subagents inherit everything' or 'subagents inherit nothing' rule, is exactly what gets tested.
1.4.4 Context-Window Management as a Continuous Practice
Context-window management is the recurring discipline of keeping a single session's context usable as it grows: pruning stale tool output that's no longer relevant, compacting history into a denser summary, and isolating heavy subtasks into subagents (Lesson 1.2's pattern, showing up again here as a context-management technique rather than only an architecture pattern). None of these is a one-time fix you apply once and forget -- they're applied continuously, throughout a long-running session, as the context keeps accumulating.
- •Pruning -- drop tool output that's no longer relevant to the remaining steps.
- •Compacting -- summarize accumulated history into a denser form that preserves what matters.
- •Isolating -- delegate a heavy, noisy subtask to a subagent so its raw exploration never enters the main context at all.
1.4.3 -- Exam Trap
Exam trap: confusing memory (state persisted across turns/sessions, outside any single window) with context-window management (pruning/compacting/isolating within one window). A scenario about an agent picking up where it left off in a new session is testing memory; a scenario about a single long-running session staying usable as it grows is testing context management.
1.4.5 Abstraction Frameworks: Four Flavors
Frameworks package the tool-use loop, subagent delegation, memory, and context management so you don't hand-roll each one every time. The four you should recognize by flavor, not just by name, each optimize for a different concern.
| Framework | Flavor |
|---|---|
| Claude Agent SDK | Anthropic's own loop, built-in tools, hooks, and subagents |
| LangGraph | Graph/state-machine orchestration of nodes and edges |
| PydanticAI | Type-safe agents with Pydantic-validated structured input and output |
| Strands | Model-driven agent framework |
Match the framework to its actual flavor -- graph orchestration, type-safe I/O, or model-driven design -- not to name recognition.
# Illustrative shape of PydanticAI's flavor: structured, type-validated I/O
from pydantic import BaseModel
class TicketTriage(BaseModel):
category: str # e.g. "billing" | "technical" | "account"
confidence: float
# The framework validates the model's output against this schema before
# your code ever sees it -- a malformed response is caught structurally,
# not discovered downstream when it breaks a consumer.
result: TicketTriage = agent.run_sync(ticket_text)1.4.6 Choosing a Framework Without Losing the Loop
Frameworks speed up development, but they add a layer of abstraction between you and the underlying API calls. Anthropic's advice is to understand those underlying calls -- the tool-use loop, the context management -- before adopting a framework, precisely because a hidden abstraction layer makes debugging harder when something goes wrong three layers down from where you're looking.
- 1.Identify the actual requirement first: graph-based orchestration, type-safe structured I/O, or a model-driven design -- not just "we need a framework."
- 2.Match the framework to that flavor, not to which one is most talked about.
- 3.Keep the underlying tool-use loop and context-management behavior visible and debuggable, even while using the framework's abstractions.
- 4.Remember a framework implements these patterns -- it doesn't remove the need to understand them when something breaks.
1.4.5 -- Exam Trap
Exam trap: assuming a framework removes the need to understand the tool-use loop and context management -- it only implements them under the hood. Items may reward the answer that keeps the design transparent and debuggable over the one that hides the most complexity behind the flashiest framework name.
Key Takeaways
- ✓The tool-use loop -- emit tool_use, execute, return tool_result, continue -- is the core agent cycle underneath every framework, grounded in real environment feedback at every step.
- ✓Memory persists state across turns or sessions, outside any single context window -- distinct from in-session context-window management.
- ✓Context-window management (pruning, compacting, isolating via subagents) is a continuously applied practice throughout a long-running session, not a one-time fix.
- ✓Claude Agent SDK, LangGraph, PydanticAI, and Strands each package the same underlying patterns with a different flavor -- own loop/hooks, graph orchestration, type-safe I/O, and model-driven design respectively.
- ✓Frameworks speed up development but add abstraction -- understand the underlying API calls and loop before adopting one, since hidden layers make debugging harder.
- ✓Choosing a framework by name recognition rather than by matching its actual flavor to the stated requirement is a recurring exam trap.
- ✓A Skill (SKILL.md, with YAML frontmatter carrying at minimum name and description) is reusable markdown that Claude loads into context only when its description matches the current task -- a different cost profile than always-loaded context like CLAUDE.md.
- ✓Skills are usable directly on the Messages API (beta) with two beta headers set together, code-execution-2025-08-25 and skills-2025-10-02, and run inside a code-execution container when invoked this way.
- ✓Subagents do NOT automatically inherit Skills from a parent session (clean context each time), but DO inherit the parent's permission/tool-access scope -- permission scope is not reset at delegation. This asymmetry is worth memorizing explicitly.
Check Your Understanding
Test what you learned in this lesson.
Q1.A team wants type-validated inputs and outputs for their agent in Python. Which framework is the natural fit?
Q2.An agent needs to pick up exactly where it left off when a user returns in a brand-new session days later. Which pattern is this describing?
Q3.Why does Anthropic advise understanding the underlying API calls before adopting an abstraction framework?
Q4.A long-running agent session is accumulating large volumes of tool output. Which set of techniques directly addresses this, and how does it differ from adding memory?
Q5.A manager agent delegates a subtask to a subagent. The parent session has a Skill loaded and a restricted permission scope. What does the subagent inherit?
Practice This Lesson