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 it. Memory is state an agent keeps and reads back. A framework is a library supplying pre-built loop, state and orchestration machinery.
Take a bed shop that sells mattresses online and wants to automate listings and customer emails.
The Five Workflow Patterns
Prompt chaining splits a task into a fixed sequence where each call works on the previous output, with optional programmatic gates between steps. The shop's listings fit: draft, check, shorten. Routing classifies an input and sends it to a specialised follow-up: a different prompt, tool set or model per category. Delivery, returns and mattress-advice emails each get their own prompt.
Parallelization runs model work simultaneously in two forms. In sectioning, independent subtasks run side by side, such as a listing's price and size checks. In voting, the same task runs several times for diverse or confident answers.
Orchestrator-workers has a central model break the task down at runtime and delegate to workers. It is the pattern behind subagent architectures. Its signature is that the subtasks are not known in advance. A customer's question about delivery dates and monthly payments needs lookups the model finds only by reading it. Evaluator-optimizer pairs a generator with an evaluator that scores output against explicit criteria. The critique goes back until the result passes, as with listings graded on the shop's checklist.
Telling the Patterns Apart
The mechanism separates four easily confused pairs.
- 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 listing takes the same steps; the emails do not.
- Sectioning versus orchestrator-workers: subtasks known in advance versus decided at runtime by the model. Enumerable, independent parts need no orchestrator. The listing checks are enumerable; the delivery question is not.
- Voting versus evaluator-optimizer: independent repeated attempts aggregated by code versus a feedback loop where the evaluator's critique drives the next generation. Voting never converges on anything; 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 loops back with a critique.
The simplest-thing rule from 1.1 covers all of it: the requirement profile justifies a pattern, never sophistication.
Memory Is a Design Decision
An agent remembers nothing between sessions unless the design adds a mechanism. In-context memory is the conversation itself: free until the window fills, gone 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 builds up state across sessions and references earlier work without holding it all in context. The context-engineering post calls this structured note-taking: persist notes outside the window, read them back on demand. Session resume is related but distinct: it restores one specific conversation, whereas memory files carry curated state into any future session. A memory file could carry a shop customer's chosen mattress size into any later chat.
Because your application executes every memory command, the safeguards live in your handler. The /memories path is a prefix your handler maps onto real storage, such as a per-user directory. The docs say it must reject paths outside it: resolve each path to its canonical form, reject ../ sequences and watch for URL-encoded ones such as %2e%2e%2f. As of September 2026 they also suggest tracking file sizes and capping how many characters a view returns, letting Claude page through the rest with view_range.
For long-horizon work across sessions, the docs describe a multisession pattern: each new session opens by reading a progress log from memory rather than re-exploring the codebase. One rule keeps that log honest: mark a feature complete only after end-to-end verification confirms it works, not when the code is written.
Context as a Constraint
Context is a finite resource, and recall degrades as token counts grow; Anthropic's engineering guidance calls this context rot. Long-running agents need a design answer. The documented moves are compaction, structured note-taking and sub-agent architectures. Compaction summarises the conversation and starts a new window with the summary, which the Agent SDK does automatically. A focused subagent explores in a clean window, say a month of the shop's orders, and returns only a condensed summary.
On the Messages API, as of September 2026, compaction comes in two beta forms. On demand, your code requests the summary and swaps it in. At a token threshold, the API compacts once input tokens reach a trigger 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, what to prune and how to summarise, are Domain 6. Items here key the design move, not the technique detail.
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. Its pitch: model agent control flow explicitly as a graph, mix deterministic steps with model-driven ones, resume durable executions, and inspect state with a human in the loop. Pydantic AI is the typed Python agent SDK from the Pydantic team: give the agent an output type and every run comes back validated against it. Strands Agents is an open-source agent SDK for Python and TypeScript, built from production systems inside Amazon. Its approach is model-driven: the model drives the loop and orchestration code stays minimal.
A framework buys that machinery at the price of a dependency and an abstraction between you and the model. The simplest-thing rule applies to tooling too: plain code beats a framework for a fixed pipeline, and a framework must earn its abstraction cost. The shop's listing chain needs no framework.
In the exam
Selection items give a requirement profile and reward the pattern whose mechanism matches, with the adjacent pattern as the distractor. Brute force (run everything, run it bigger) is a recurring distractor. Memory items reward explicit persistence over hoping the window holds. A closing tooling question asks which framework, if any, a stated need points at. The guide names three agentic abstraction frameworks as examples, and items test matching a need to the framework that leads with it, never API trivia.
The exam takes its pattern names verbatim from Anthropic's "Building effective agents", American spellings included.
Exam Traps
Keying sectioning when the stem says the model must work out the subtasks at runtime, or orchestrator-workers when the parts are enumerable up front.
The dividing line is who decides the subtasks and when. Known and independent up front means sectioning; discovered at runtime by the model means orchestrator-workers. Each is the other's favourite distractor.
Assuming an agent retains memory between sessions by default, so yesterday's decisions are available today.
Nothing persists unless the design adds it: memory files, session resume or retrieval. Distractors that rely on automatic recall across sessions are always wrong.
Swapping framework identities: recommending LangGraph for typed output validation, or Pydantic AI for graph-shaped control flow.
The keyed mapping follows what each framework leads with: stateful, inspectable graphs point at LangGraph; schema-validated typed outputs in Python point at Pydantic AI; a model-driven loop from the AWS ecosystem points at Strands.
Treating voting and evaluator-optimizer as interchangeable quality loops.
Voting aggregates independent attempts in code, with no information flowing between them. Evaluator-optimizer feeds a model's critique back into regeneration. A stem naming explicit criteria and iterative feedback keys the latter.
Practice Scenario
A subtitling team automates broadcast subtitle files. Every file must meet a published style code covering line length, reading speed and terminology. They want one model call to draft the file and a second call to grade it against the style code, 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 reaching for a framework
- How to wire 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: Patterns are keyed to requirement profiles; writing the profile first makes the choice mechanical instead of aesthetic.
You should see: Three short profiles, each answering the four questions.
- Assign each task a pattern from the canonical five with a one-line justification tied to the profile, and name the adjacent pattern you rejected and why
Why: Naming the rejected neighbour is exactly what exam distractors 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 hand-rolled sequencing.
- For the task with a quality criterion, wire the evaluator-optimizer shape: 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 loop guard 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 leads with
Why: The memory decision and the framework mapping are the two judgements this sub-skill keys, and both should end grounded in 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