What You Need to Know
A workflow pattern is a standard way to arrange model calls and code. Sub-skill 1.1 decided the tier. This sub-skill names the shapes inside that tier. Memory is state that an agent keeps and reads again later. A framework is a library that supplies pre-built code for the loop, state and orchestration.
This lesson uses one made-up example throughout: a software company that sells appointment-scheduling software. Its team wants to automate release notes and replies to support emails.
The Five Workflow Patterns
Prompt chaining splits a task into a fixed sequence of calls. Each call works on the output of the previous call. There are optional programmatic gates (fixed pass/fail checkpoints) between the steps. The company's release notes fit this pattern: draft, check, shorten. Routing classifies an input and sends it to a specialised follow-up. Each category gets a different prompt, tool set or model. Billing, sign-in and calendar-sync emails each get their own prompt.
Parallelization runs model work simultaneously in two forms. In sectioning, independent subtasks run at the same time, such as the link check and the version-number check for a release note. In voting, the same task runs several times to get diverse or confident answers.
Orchestrator-workers has a central model that splits the task at runtime and delegates the parts to workers. It is the pattern behind subagent architectures. Its identifying feature is that the subtasks are not known in advance. A bug report about double bookings could involve the calendar sync, the time-zone code or the database. The model decides which parts to investigate only when it reads the report. Evaluator-optimizer pairs a generator with an evaluator that scores output against explicit criteria. The evaluator returns its critique to the generator until the result passes. An example is a release note that the evaluator grades against the company's checklist.
Telling the Patterns Apart
The mechanism separates four pairs of patterns that are easy to confuse.
- Chaining versus routing: a fixed sequence versus a classification decision. If every input takes the same steps, chain. If categories deserve different treatment, route. Every release note takes the same steps. The emails do not.
- Sectioning versus orchestrator-workers: subtasks that are known in advance versus subtasks that the model decides at runtime. Independent parts that you can list in advance need no orchestrator. You can list the release-note checks in advance. You cannot list the steps of the bug investigation.
- Voting versus evaluator-optimizer: independent repeated attempts that code aggregates, versus a feedback loop where the evaluator's critique guides the generator's next attempt. Voting never refines an answer from one attempt to the next. It only aggregates, because no information passes between attempts.
- A gate versus evaluator-optimizer: a gate is a fixed pass/fail checkpoint in a one-way sequence. The evaluator-optimizer returns to the generator with a critique.
The rule from 1.1 to find the simplest solution possible applies to all of these choices. The requirement profile (what the task needs) justifies a pattern. That a pattern is more sophisticated never justifies it.
Memory Is a Design Decision
An agent remembers nothing between sessions unless the design adds a mechanism. In-context memory is the conversation itself. It is free until the context window (the text that the model can read in one call) fills, and it is lost when the session ends. External memory keeps working state outside the window.
Anthropic's memory tool is now generally available on the Messages API as tool type memory_20250818. It gives Claude create, read, update and delete operations over files in a /memories directory. Claude requests each operation and your application executes it client-side. The agent collects state across sessions. It refers to earlier work without holding all of that work in context. The context-engineering post calls this structured note-taking. The agent persists notes outside the window and reads them again when it needs them. Session resume is related but different. It restores one specific conversation. Memory files carry selected state into any future session. A memory file could carry a customer's chosen time zone into any later support chat.
Because your application executes every memory command, the safeguards belong in your handler. The /memories path is a prefix that your handler maps onto real storage, such as a per-user directory. The docs say that the handler must reject paths outside that prefix. To do this, resolve each path to its canonical form (the full path with every .. resolved). Reject ../ sequences and check for URL-encoded ones (written as % codes), such as %2e%2e%2f. As of September 2026, the docs also suggest that you track file sizes and cap how many characters a view returns. This lets Claude read the rest in pages with view_range.
For long-running work across sessions, the docs describe a multisession pattern. Each new session starts by reading a progress log from memory, instead of exploring the codebase again. One rule keeps that log accurate. Mark a feature complete only after end-to-end verification confirms that it works. Do not mark it complete when the code is written.
Context as a Constraint
Context is a finite resource. Recall degrades as token counts grow. Anthropic's engineering guidance calls this effect context rot. Long-running agents need a design answer. The documented design answers are compaction, structured note-taking and sub-agent architectures. Compaction summarises the conversation and starts a new window with the summary. The Agent SDK does this automatically. A focused subagent explores in a clean (fresh) context window, for example a month of the company's support emails. It returns only a condensed summary.
On the Messages API, as of September 2026, compaction comes in two beta forms. In the on-demand form, your code requests the summary and puts it in place of the conversation. In the token-threshold form, the API compacts when input tokens reach a trigger that you set. The docs say to use on-demand compaction where available.
The Domain 1 / Domain 6 boundary
Treating a subagent or memory file as the design answer to a context problem is Domain 1 material. The window-management techniques themselves are Domain 6 material. These techniques cover what to prune and how to summarise. Questions here test the design choice, not the detail of the technique.
Framework Identities
LangGraph is a low-level orchestration framework and runtime for building long-running, stateful agents. It comes from LangChain Inc but works without LangChain. LangGraph lets you model agent control flow explicitly as a graph and mix deterministic steps with model-driven steps. It also lets you resume durable executions (runs that save their state) and inspect state with a human in the loop (a person who checks a run). Pydantic AI is the typed Python agent SDK from the Pydantic team. Give the agent an output type, and every run returns a result that is validated against that type. Strands Agents is an open-source agent SDK for Python and TypeScript. It was built from production systems inside Amazon. Its approach is model-driven: the model controls the loop, and the orchestration code stays minimal.
A framework gives you that pre-built code. The cost is a dependency and an abstraction between you and the model. The rule to find the simplest solution possible applies to tooling too. For a fixed pipeline, plain code is better than a framework. A framework must justify the cost of its abstraction. The company's release-note chain needs no framework.
In the exam
Selection questions give a requirement profile. They reward the pattern whose mechanism matches, and the adjacent pattern is the tempting wrong answer. Brute force (run everything, run it bigger) is a recurring wrong option. Memory questions reward explicit persistence, not the hope that the context window keeps the information. A closing tooling question asks which framework, if any, matches a stated need. The guide names three agentic abstraction frameworks as examples. Questions ask you to match a need to the framework that puts that need first. They never test API trivia.
The exam takes its pattern names verbatim from Anthropic's "Building effective agents", American spellings included.
Exam Traps
Choosing sectioning when the model must discover the subtasks at runtime, or orchestrator-workers for parts you can list in advance
What separates the two patterns is who decides the subtasks, and when. Independent parts that you can list in advance suit sectioning. Subtasks the model must discover at runtime suit orchestrator-workers.
Assuming an agent you build keeps yesterday's decisions between sessions by default
Nothing carries over between sessions by default. An agent remembers only what the design persists. Write the state to external memory the agent reads back, such as memory-tool files.
Recommending LangGraph for typed output validation, or Pydantic AI for graph-shaped control flow
Each framework puts one need first. LangGraph puts explicit, stateful graphs first. Pydantic AI puts validated typed output in Python first. Strands puts a model-driven loop first, and it was built from production systems inside Amazon.
Choosing voting when the requirement is a critique fed back into the next draft against explicit criteria
Voting aggregates independent attempts in code, with no information flowing between them. Evaluator-optimizer feeds a model's critique back into regeneration, which suits explicit criteria and iterative feedback.
Practice Scenario
A team at an e-learning platform automates course descriptions. Every description must meet a published style guide covering length, reading level and terminology. They want one model call to draft the description and a second call to grade it against the style guide, feeding the critique back until the draft passes or three rounds elapse. Which workflow pattern is this?
Build Exercise
Profile Three Tasks, Pick Three Patterns
What you'll learn
- How to write a requirement profile that determines a pattern choice
- How to implement a pattern as plain code before choosing a framework
- How to build the evaluator-optimizer loop with a hard round cap
- How to decide what working state must be persisted outside the window
- List three genuine automation candidates from your own work and write the requirement profile of each: are the steps known in advance, are parts independent, is there an explicit quality criterion, must subtasks be decided at runtime?
Why: Each pattern matches a requirement profile; writing the profile first makes the choice a matter of rules instead of taste.
You should see: Three short profiles, each answering the four questions.
- Assign each task a pattern from the five standard patterns with a one-line justification tied to the profile, and name the adjacent pattern you rejected and why
Why: Naming the similar pattern that you rejected is exactly what the wrong options on the exam test: the adjacent pattern that fits a slightly different profile.
You should see: Three pattern assignments, each with a justification and a rejected alternative.
- Implement the smallest task as plain code: two or three Messages API calls with your own control flow, no framework
Why: Owning the control flow once makes it obvious what a framework would and would not add.
You should see: A short script that runs end to end with sequencing that you wrote yourself.
- For the task with a quality criterion, build the evaluator-optimizer pattern: a generator call, an evaluator call returning structured pass/fail plus critique, and a loop with a hard round cap
Why: The evaluator-optimizer is the pattern most often described in prose and least often actually built; the round cap is the limit on the loop that production requires.
You should see: A loop that terminates either on a pass or at the cap, logging the critique each round.
- Choose what working state, if any, must outlive the run, persist it explicitly to a file, and close with one sentence per framework saying which of your three tasks, if any, has the need it puts first
Why: The memory decision and the framework mapping are the two judgements this sub-skill tests, and both should be based on your own tasks.
You should see: A persisted state file (or a note that none is needed) and three framework sentences.
Sources
- Building effective agents — Anthropic engineering, the five workflow patterns verbatim
- Effective context engineering for AI agents — Anthropic engineering, context rot, compaction, note-taking and sub-agent architectures
- Memory tool — Claude Docs, client-executed memory files under /memories, tool type memory_20250818, handler safeguards and the multisession pattern
- Compaction overview — Claude Docs, compaction on demand versus compaction at a token threshold
- Subagents in the SDK — Claude Docs, clean-window exploration returning condensed summaries
- LangGraph overview — LangChain, stateful graph orchestration for long-running agents
- Pydantic AI overview — Pydantic, the typed agent loop with validated outputs
- Strands Agents — Strands project, the open-source model-driven agent SDK from Amazon