Study Guide: Agent Architecture, Patterns, and Frameworks

Pre-Reading Check — Workflows vs. Agents

1. In Anthropic's vocabulary, what defines a workflow as distinct from an agent?

The LLM dynamically directs its own tool usage at runtime. LLMs and tools are orchestrated through predefined code paths written by the developer. It always uses more than one model working in parallel. It never uses tools, only retrieval.

2. A team must translate incoming support tickets, classify their category, and route each to a fixed handler — the exact steps are the same every run. Which architecture is the best fit and why?

An agent, because any multi-step task requires model-driven autonomy. A workflow, because the steps are predictable and you gain consistency and lower cost. An agent, because routing is inherently open-ended. A multi-agent hierarchy, because ticket handling always exceeds one context window.

3. According to "Building Effective Agents," what should a developer try first for a new task?

A manager/subagent hierarchy for maximum capability. An autonomous agent, then simplify if it is too expensive. A single LLM call, optionally with retrieval and few-shot examples. A framework such as LangGraph to avoid boilerplate.

4. Why is the choice between a workflow and an agent a genuine tradeoff rather than "agents are just better"?

Agents cannot use tools, so they are less capable. Autonomy raises cost and latency and risks compounding errors across the loop. Workflows cannot call an LLM more than once. Agents are always cheaper because they finish in fewer steps.

1. Workflows vs. Agents

Key Points

An agentic system is any system that uses an LLM with tools; it splits into workflows and agents.
Workflow: LLMs and tools orchestrated through predefined code paths — steps known before the program runs.
Agent: the LLM dynamically directs its own process and tool usage at runtime.
The exam heuristic is the "can you predict the steps?" test: if you can draw the flowchart in advance, build a workflow; if not, build an agent.
Start simple: escalate single LLM call → workflow → agent only as needed — autonomy trades cost, latency, and error risk for capability.

Anthropic's "Building Effective Agents" introduces the umbrella term agentic system and splits it in two. A workflow is a system "where LLMs and tools are orchestrated through predefined code paths" — the developer writes the control flow and the LLM fills in slots inside a designed structure. An agent is a system "where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks" — the model decides the path at runtime.

A useful analogy: a workflow is a railway and an agent is a self-driving car. The railway's track is laid in advance and predictably visits known stations; the self-driving car chooses its own route in response to live conditions, reaching destinations the railway never anticipated but at higher cost and lower predictability. Neither is "better" — you pick based on the trip.

Decision criteria: workflow vs. agent

Choose a workflow when the task decomposes into fixed, predictable subtasks and you value predictability, consistency, lower cost, and lower latency. Choose an agent for open-ended problems "where it's difficult or impossible to predict the required number of steps, and where you can't hardcode a fixed path" — the canonical examples are complex coding and computer use.

Dimension	Workflow	Agent
Control flow	Predefined by developer (code paths)	Directed dynamically by the model at runtime
Predictability	High — same shape every run	Lower — path varies with the problem
Best for	Well-defined tasks, fixed subtasks	Open-ended tasks, unknown number of steps
Cost & latency	Lower, more consistent	Higher; autonomy trades cost/latency for capability
Failure mode	Rigid — breaks on unanticipated cases	Compounding errors across an autonomous loop
Canonical examples	Document translation pipeline, ticket routing	Complex coding, computer use, open-ended research

The "start simple" escalation ladder

The article's central thesis outranks the workflow-vs-agent choice: start simple. For many applications no agentic system is required — "optimizing single LLM calls with retrieval and in-context examples is usually enough." The escalation ladder: (1) single LLM call, (2) workflow, (3) agent — only when the path cannot be predicted. Every pattern above the single-call baseline is built on the Augmented LLM: a model enhanced with retrieval, tools, and memory. Because agents plan and operate independently, Anthropic recommends testing in sandboxed environments with guardrails before granting autonomy.

flowchart TD Start["New task"] --> Q1{"Does a single well-crafted
prompt (with retrieval /
few-shot) solve it?"} Q1 -->|Yes| Single["Single LLM call
(simplest — try first)"] Q1 -->|No| Q2{"Can you predict the
steps and draw the
flowchart in advance?"} Q2 -->|Yes| Workflow["Workflow
predefined code paths
predictable, lower cost"] Q2 -->|No| Agent["Agent
model directs its own path
flexible, higher cost"] Agent --> Guard["Requires sandboxing
+ guardrails before autonomy"]

Animation slot: the "start simple" ladder lighting up single call → workflow → agent, with cost/latency rising at each rung.

Post-Reading Check — Workflows vs. Agents

1. In Anthropic's vocabulary, what defines a workflow as distinct from an agent?

2. A team must translate incoming support tickets, classify their category, and route each to a fixed handler — the exact steps are the same every run. Which architecture is the best fit and why?

3. According to "Building Effective Agents," what should a developer try first for a new task?

4. Why is the choice between a workflow and an agent a genuine tradeoff rather than "agents are just better"?

Pre-Reading Check — Agent Hierarchies

1. In a manager/supervisor hierarchy, what is the defining property of a subagent?

It shares the lead agent's single context window. It operates in its own separate context window and returns condensed findings. It writes the final synthesized answer for the user. It always runs the same model as the lead agent.

2. Anthropic recommends decomposing multi-agent work by shared context, not by problem type. Why is splitting into "planning," "implementation," and "testing" agents a poor design?

Those roles all need the same evolving context, forcing constant coordination and information loss. Three agents always exceed the token budget. Testing can never be done by an LLM. Planning agents cannot use tools.

3. Which four things must a lead agent include in every subagent task delegation?

Objective, output format, tool/source guidance, and explicit task boundaries. Model name, temperature, max tokens, and a stop sequence. Budget, deadline, priority, and owner. Retrieval index, embeddings, cache key, and schema.

4. What is the memorable cost/performance relationship Anthropic reports for its multi-agent research system?

Multi-agent halved token usage while matching single-agent quality. A ~90.2% performance gain over a single-agent baseline, but multi-agent uses roughly 15x the tokens of a chat. Performance and token spend were entirely uncorrelated. Multi-agent was cheaper because subagents share one context.

5. Why does the lead agent save its plan to external memory before delegating?

To let subagents overwrite it with their own plans. So the plan survives even if the growing context window is truncated. Because Claude cannot plan without external storage. To reduce the number of tools each subagent needs.

2. Agent Hierarchies

Key Points

A manager/supervisor hierarchy has a lead agent that plans, delegates, and synthesizes; it owns strategy and integration, not the detailed digging.
Each subagent works in its own isolated context window and returns condensed findings — giving context protection, parallelization, and specialization.
Delegate with a clear objective, output format, tool/source guidance, and explicit boundaries; vague delegation causes duplication and gaps.
Decompose by shared context, not problem type; only split off a subagent whose context can be truly isolated (e.g., a low-context verification subagent).
Big payoff, big cost: ~90.2% improvement over a single-agent baseline, but multi-agent uses roughly 15x the tokens of a chat.

When one agent is not enough, coordinate several in a hierarchy. Anthropic's reference implementation is its internal multi-agent research system. A lead agent (Claude Opus 4) analyzes the query, develops a strategy, saves its plan to memory, and spawns subordinate agents in parallel. After subordinates report back, the lead synthesizes their findings and decides whether to finish or spawn more — an iterative loop, not a single fan-out. Saving the plan matters because the context window can exceed 200,000 tokens and get truncated; persisting the plan means it survives.

graph TD Query["Incoming query"] --> Lead["Lead agent (Claude Opus 4)
analyze, plan, delegate, synthesize"] Lead -->|"saves plan to memory"| Mem[("External memory")] Lead -->|"delegate in parallel"| S1["Subagent 1 (Sonnet 4)
own context window + tools"] Lead -->|"delegate in parallel"| S2["Subagent 2 (Sonnet 4)
own context window + tools"] Lead -->|"delegate in parallel"| S3["Subagent 3 (Sonnet 4)
own context window + tools"] S1 -->|"condensed findings"| Lead S2 -->|"condensed findings"| Lead S3 -->|"condensed findings"| Lead Lead --> Decide{"Research complete?"} Decide -->|"No — spawn more,
refine strategy"| Lead Decide -->|"Yes"| Answer["Final synthesized answer"]

The role of subagents

The defining property is that each subagent operates in its own separate context window. This delivers three benefits: context protection (the manager's context stays clean of raw data), parallelization (independent inquiries run at once across a larger information space than one context could hold), and specialization (each subagent carries a focused toolset and prompt — important because agents given 20+ tools struggle to choose among them).

Delegating and decomposing well

Vague delegation is the primary failure mode. Every subagent task must include a clear objective, an output format, tool/source guidance, and explicit task boundaries. The lead should also embed effort-scaling heuristics:

Task complexity	Suggested delegation
Simple fact-finding	1 subagent, 3–10 tool calls
Comparisons	2–4 subagents, 10–15 tool calls each
Complex open-ended research	10+ subagents with clearly divided responsibilities

The most important principle is context-centric decomposition: split by shared context requirements, not by problem type. Splitting into "planning," "implementation," and "testing" agents is poor because those roles share the same evolving context, forcing "telephone game" coordination loss. A clean split is the verification subagent — checking correctness is inherently low-context. Caveat: verification agents "often declare success prematurely," so instruct them explicitly (e.g., "Run the complete test suite before marking as passed").

Animation slot: lead agent fanning out to isolated subagent contexts, each returning a condensed summary that the lead merges into one answer.

Post-Reading Check — Agent Hierarchies

1. In a manager/supervisor hierarchy, what is the defining property of a subagent?

2. Anthropic recommends decomposing multi-agent work by shared context, not by problem type. Why is splitting into "planning," "implementation," and "testing" agents a poor design?

3. Which four things must a lead agent include in every subagent task delegation?

4. What is the memorable cost/performance relationship Anthropic reports for its multi-agent research system?

5. Why does the lead agent save its plan to external memory before delegating?

Pre-Reading Check — Common Agent Patterns

1. Which workflow pattern "classifies an input and directs it to a specialized followup task"?

Prompt chaining Routing Evaluator-optimizer Parallelization

2. Both parallelization and orchestrator-workers can run several LLM calls at once. What is the discriminating question that separates them?

Whether the calls use the same model. Who decides the subtasks — the developer ahead of time, or the model at runtime? Whether the results are aggregated. Whether external memory is used.

3. A translation must be iteratively critiqued and improved over several rounds by a second LLM that gives feedback. Which pattern is this?

Routing Sectioning Evaluator-optimizer Prompt chaining

4. In the two variations of parallelization, what distinguishes voting from sectioning?

Voting runs the same task multiple times for diverse outputs; sectioning splits into independent subtasks. Voting is always sequential; sectioning is always parallel. Voting decides subtasks at runtime; sectioning predefines them. Voting uses one model; sectioning uses many models.

5. Why is an agent's step count unpredictable, and what design principle does Anthropic stress to make the loop reliable?

Because the API caps steps at ten; you must raise the limit. The tool-use loop runs until the model decides it is done; invest in the Agent-Computer Interface (ACI). Because subagents run in parallel; you must serialize them. Because retrieval is nondeterministic; you must disable it.

6. How does Anthropic's research system keep a long-running agent from overflowing its context window?

By deleting all tool results after each step. By using external memory: summarizing completed phases and passing lightweight references instead of bulky outputs. By switching to a smaller model mid-task. By forbidding the agent from using more than one tool.

3. Common Agent Patterns

Key Points

Anthropic names five workflow patterns: prompt chaining, routing, parallelization (sectioning & voting), orchestrator-workers, and evaluator-optimizer.
Only orchestrator-workers decides its subtasks at runtime — that is what makes it agentic; parallelization's subtasks are predefined.
The tool-use loop (reason → select tool → execute → result → repeat) runs until the model decides it is done, making step count unpredictable.
Invest in the Agent-Computer Interface (ACI): simple tools, room to think, natural formats, examples/edge cases, and poka-yoke (e.g., absolute file paths).
Manage growing context with external memory — summaries of completed phases plus lightweight references, not bulky copies.

1. Prompt chaining. Decomposes a task into a fixed sequence "where each LLM call processes the output of the previous one," optionally with programmatic gates to validate an intermediate result. Best when a task splits cleanly into fixed subtasks; trades latency for accuracy. Example: write copy, then translate it.

2. Routing. "Classifies an input and directs it to a specialized followup task." Ideal for distinct input categories — e.g., sending each customer-service query type to a specialized handler, or easy questions to a cheaper model.

3. Parallelization. Runs work simultaneously and aggregates programmatically. Sectioning splits into independent subtasks; voting runs the same task multiple times for diverse outputs (e.g., several reviewers voting on whether code is safe).

4. Orchestrator-workers. "A central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results." The subtasks are not pre-defined — decided at runtime. This is the pattern the manager/subagent hierarchy implements.

5. Evaluator-optimizer. "One LLM call generates a response while another provides evaluation and feedback in a loop." Best with clear criteria where iteration measurably helps.

flowchart TD subgraph Chain["1 - Prompt chaining (fixed sequence)"] direction LR C1["Step 1"] --> G1{"Gate"} --> C2["Step 2"] --> C3["Step 3"] end subgraph Route["2 - Routing (classify then dispatch)"] direction LR R0["Classify input"] --> RA["Handler A"] R0 --> RB["Handler B"] R0 --> RC["Handler C"] end subgraph Parallel["3 - Parallelization (predefined subtasks)"] direction LR P0["Split / same task"] --> PA["Call A"] P0 --> PB["Call B"] PA --> PAgg["Aggregate / vote"] PB --> PAgg end subgraph Orch["4 - Orchestrator-workers (subtasks decided at runtime)"] direction LR O0["Orchestrator LLM
decides subtasks dynamically"] --> OW1["Worker 1"] O0 --> OW2["Worker 2"] OW1 --> OSyn["Synthesize"] OW2 --> OSyn end subgraph Eval["5 - Evaluator-optimizer (refine in a loop)"] direction LR E0["Generator"] --> E1["Evaluator"] E1 -->|"feedback: refine"| E0 E1 -->|"accepted"| EOut["Output"] end

Pattern	What it does	Subtasks known in advance?	When to use
Prompt chaining	Fixed sequence; each step feeds the next	Yes	Task splits cleanly into fixed steps
Routing	Classify input, dispatch to a specialist	Yes (fixed categories)	Distinct input types handled separately
Parallelization	Run work simultaneously, aggregate	Yes	Independent subtasks (sectioning) or consensus (voting)
Orchestrator-workers	Central LLM decides + delegates subtasks	No — decided at runtime	Complex tasks with unpredictable decomposition
Evaluator-optimizer	Generate, critique, refine in a loop	N/A (iterative)	Clear criteria; iteration measurably helps

The tool-use loop and the ACI

The tool-use loop is the engine beneath every agent: reason, select a tool, execute, return the result, repeat — until the model itself decides it is finished. That is why an agent's step count is unpredictable. Anthropic stresses investing in the Agent-Computer Interface (ACI): keep the agent simple, show planning steps, give room to "think," keep tool formats natural, include example usage and edge cases, and apply poka-yoke (e.g., require absolute file paths).

flowchart TD Task["Task"] --> Reason["Model reasons
about next step"] Reason --> Decide{"More work
needed?"} Decide -->|"Yes"| Select["Select a tool"] Select --> Exec["Tool executes"] Exec --> Result["Result returns to model
(context grows each iteration)"] Result --> Reason Decide -->|"No — model decides
it is finished"| Done["Final answer"]

Memory and when sub-agents fit

Because the loop accumulates context, long-running agents use external memory: the lead summarizes completed phases before continuing, and subagents store detail externally and pass only lightweight references. Sub-agent orchestration excels at heavy parallelization, information exceeding one context window, and breadth-first queries — but is a poor fit when agents must share context or have many dependencies (much coding work), or need tight real-time coordination. The reminder: start with a single agent.

Animation slot: side-by-side of parallelization (developer-defined boxes) vs. orchestrator-workers (an LLM drawing new boxes at runtime).

Post-Reading Check — Common Agent Patterns

1. Which workflow pattern "classifies an input and directs it to a specialized followup task"?

Prompt chaining Routing Evaluator-optimizer Parallelization

2. Both parallelization and orchestrator-workers can run several LLM calls at once. What is the discriminating question that separates them?

Whether the calls use the same model. Who decides the subtasks — the developer ahead of time, or the model at runtime? Whether the results are aggregated. Whether external memory is used.

3. A translation must be iteratively critiqued and improved over several rounds by a second LLM that gives feedback. Which pattern is this?

Routing Sectioning Evaluator-optimizer Prompt chaining

4. In the two variations of parallelization, what distinguishes voting from sectioning?

5. Why is an agent's step count unpredictable, and what design principle does Anthropic stress to make the loop reliable?

6. How does Anthropic's research system keep a long-running agent from overflowing its context window?

Pre-Reading Check — Agentic Frameworks

1. What is Anthropic's stated stance on adopting agentic frameworks?

Always use a framework; raw API calls are discouraged. Start with LLM APIs directly; if you adopt a framework, understand what it does under the hood. Only LangGraph is approved for production. Frameworks should never be used because they hide prompts.

2. Which framework's defining feature is type-safe structured output via a Pydantic BaseModel result type with automatic retry?

Strands LangGraph PydanticAI Claude Agent SDK

3. A team needs a complex, stateful, long-running agent that persists through failures and resumes where it left off, with human-in-the-loop approval gates. Which framework fits best?

PydanticAI, for its validated outputs. Strands, for its minimal-code model-driven loop. LangGraph, for its stateful graph with checkpointing and durable execution. A single LLM call, since frameworks add no value here.

4. What is the "model-driven approach" that defines AWS Strands?

You script every control-flow step by hand in a graph. You give a model, tools, and a prompt, and the framework runs an agentic loop where the model directs its own steps and tool use. It only works with a single fixed Claude model. It guarantees outputs match a schema by retrying.

4. Agentic Frameworks

Key Points

Anthropic advises: start with direct LLM API calls; adopt a framework only once you understand what it does — hidden abstractions are "a common source of customer error."
Strands (AWS, May 2025): a model-driven, minimal-code, MCP-native SDK; model-agnostic; strongest fit for AWS/Bedrock, fastest to start.
LangGraph (LangChain Inc.): a low-level stateful-graph runtime (nodes/edges/state with cycles) with checkpointing, durable execution, and human-in-the-loop; best for complex, long-running production workflows.
PydanticAI (Pydantic, Nov 2024): type-safe validated outputs via a BaseModel result type with auto-retry, plus dependency injection; best for lightweight tasks needing structured output.
The Claude Agent SDK is Anthropic's own scaffolding for the deepest Claude integration.

Anthropic names the Claude Agent SDK, AWS Strands, Rivet, and Vellum and acknowledges they "make it easy to get started," but recommends developers "start by using LLM APIs directly," because "many patterns can be implemented in a few lines of code." If you do adopt a framework, "ensure you understand the underlying code," since "incorrect assumptions about what's under the hood are a common source of customer error." The exam-safe answer: don't reach for a framework until you understand what it does and only if a raw-API build would be materially harder.

Strands (AWS)

An open-source agents SDK from AWS (launched May 16, 2025). Its model-driven approach: give it a model, tools, and a prompt, and it runs an agentic loop where "the agent uses the model to dynamically direct its own steps and to use tools." It is model-agnostic (Bedrock, Anthropic API, Llama, Ollama, OpenAI via LiteLLM), has first-class MCP support and OpenTelemetry tracing, and pairs with Bedrock AgentCore for deployment. Easiest to start; strongest on AWS — but the newest entrant with the smallest track record.

LangGraph (LangChain Inc.)

A low-level orchestration framework and runtime for long-running, stateful agents. It deliberately does not abstract away prompts. Programs are stateful graphs: nodes connected by edges (including conditional edges) over a shared state. Crucially the graph supports cycles (unlike a plain DAG), enabling agentic looping. Standout capabilities: persistence and checkpointing (durable execution, resume after failures), strong human-in-the-loop, and short- and long-term memory. Most production mileage (Klarna, Uber, J.P. Morgan, LinkedIn) at the cost of a steeper learning curve.

PydanticAI (Pydantic)

A Python agent framework (Nov 2024) bringing Pydantic's validation and type safety to agents. Defining feature: type-safe structured output — define a BaseModel result type and the framework guarantees the response conforms to that schema, automatically retrying until it does. Model-agnostic across 15+ providers, type-safe dependency injection (via deps_type), function tools, a Pydantic Graph, MCP/A2A support, and observability via Pydantic Logfire. Best when type safety and validated outputs matter and the task is lightweight.

Framework	Origin / released	Core idea	Standout strength	Best fit
Strands	AWS, May 2025	Model-driven agent loop	Minimal code; MCP-native; AWS/Bedrock deployment	Provider flexibility, AWS-native, fastest to start
LangGraph	LangChain Inc.	Stateful graph (nodes/edges/state) with cycles	Checkpointing, durable execution, human-in-the-loop	Complex, stateful, durable, long-running production workflows
PydanticAI	Pydantic, Nov 2024	Type-safe agents with validated outputs	`BaseModel` result type with auto-retry; dependency injection	Lightweight tasks needing validated/structured output
Claude Agent SDK	Anthropic	Anthropic's own agent scaffolding	Deep Claude/Anthropic integration	Building directly and closely on Claude

Animation slot: a decision map routing use cases to PydanticAI (validated output), LangGraph (durable long-running), Strands (AWS-native), and Claude Agent SDK (deep Claude).

Post-Reading Check — Agentic Frameworks

1. What is Anthropic's stated stance on adopting agentic frameworks?

2. Which framework's defining feature is type-safe structured output via a Pydantic BaseModel result type with automatic retry?

Strands LangGraph PydanticAI Claude Agent SDK

3. A team needs a complex, stateful, long-running agent that persists through failures and resumes where it left off, with human-in-the-loop approval gates. Which framework fits best?

4. What is the "model-driven approach" that defines AWS Strands?

Agent Architecture, Patterns, and Frameworks

Learning Objectives

1. Workflows vs. Agents

Key Points

Decision criteria: workflow vs. agent

The "start simple" escalation ladder

2. Agent Hierarchies

Key Points

The role of subagents

Delegating and decomposing well

3. Common Agent Patterns

Key Points

The tool-use loop and the ACI

Memory and when sub-agents fit

4. Agentic Frameworks

Key Points

Strands (AWS)

LangGraph (LangChain Inc.)

PydanticAI (Pydantic)

Your Progress

Answer Explanations