AnthropicClaude Certified Architect – Professional2026-101.3 Select appropriate architectural patterns (workflow, agentic, augmented LLM)

Match workflow shape to task dependencies

Completed by the knowledge check

Learning objective

Select workflow patterns — prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer — by task structure.

Core idea

You already know when ordered stages and adaptive decomposition differ. The professional decision is which structure resolves the uncertainty in this task: dependencies between outputs, distinct input categories, independent work, unknown assignments, or a result that improves through feedback.

Anthropic’s five workflow patterns are composable structures, rather than five exclusive products. Select a pattern for the work it organizes. A router can select a chain, a chain can contain parallel checks, and an orchestrator can send a worker’s draft through evaluation. Every added structure needs a reason grounded in that task.

The selection artifact is a task-dependency map. Name the outputs, mark which depend on earlier outputs, identify which assignments are known before execution, and state how acceptance is determined. That map supplies a defensible pattern choice before the team chooses a framework.

How it works

Preserve a chain when the handoff matters

Prompt chaining earns its place when prescribed intermediate outputs need inspection or a specific pipeline must run. Keep the established stages, and ask what each handoff lets the application inspect, reject, or route.

Anthropic’s prompting guidance says explicit chaining remains useful for inspecting intermediate outputs or enforcing a pipeline, while adaptive thinking and subagent orchestration handle much multistep reasoning internally. Several reasoning steps alone do not justify several external calls. If no stage output needs independent treatment, compare the chain with one focused call before accepting its latency.

A programmatic gate must test the property its successor relies on. If a downstream draft requires a complete product specification, the gate checks required specification coverage. A readable summary is not evidence that all necessary inputs arrived.

Route when categories need different treatment

Routing classifies input and sends it to a specialized follow-up. It fits distinct categories that can be classified accurately and benefit from different prompts, tools, or processing paths. Anthropic notes that optimizing one prompt for one category can harm another; routing provides separation.

Make category ownership explicit. Define the supported category values and map each to a handler in code. Include an unresolved-input path so classification does not force an unsupported case into the nearest category. For a Messages API router, use output_config.format with type: "json_schema" and a category field whose enum contains the supported values plus the unresolved value; see 1.2.3 for structured-interface support and failure boundaries. The handlers remain application code.

Structured outputs do not guarantee the capitalization of string enum or const values. A case-only mismatch completes normally, with no error or special stop_reason. Compare categories case-insensitively before dispatch, and avoid category values that differ only in capitalization. A schema-valid category still needs the classification-quality checks described here.

Every category the classifier returns is compared case-insensitively, then dispatched to its handler in code or to the unresolved-input path.

Evaluate wrong-path consequences as well as classification accuracy. A misrouted request can receive a polished answer from the wrong specialist. A cheap first call is only useful if its downstream behavior still satisfies the result contract.

Parallelize independent work or diverse attempts

Anthropic distinguishes sectioning, where independent subtasks run concurrently, from voting, where multiple attempts address the same task and their outputs are aggregated. Sectioning fits separable considerations; voting fits a need for multiple perspectives or attempts.

Use sectioning when a check can proceed without another check’s findings. Two reviews that must inspect different aspects of the same supplied document can run together. A translation that needs the finalized English copy cannot run as an independent peer of that copy’s generation.

For voting, define the aggregation rule. Anthropic gives examples with different vote thresholds to balance false positives and false negatives. A majority rule and an any-positive rule express different risk choices. Repeated agreement is not proof of correctness: attempts can share a mistaken premise. Preserve the individual findings that explain an aggregate decision.

Concurrency can reduce elapsed time relative to sequential execution of independent calls. It still purchases every attempt and needs a join that handles missing or conflicting results. Specify which checks are required before downstream work proceeds, rather than treating a partial join as completed review.

Use an orchestrator when assignments emerge

Orchestrator-workers lets a central model determine subtasks, delegate them, and synthesize the results. Its distinction from sectioning is that the required assignments are not predefined. A fixed list of departments reviewed concurrently is sectioning; discovering which departments a proposal affects is dynamic decomposition.

Keep the worker assignment tied to an output and evidence requirement. Dynamic task selection does not require dynamic acceptance criteria. If the orchestrator finds an additional affected interface, it expands the assignment set while the required compatibility evidence remains fixed.

This pattern also introduces synthesis responsibility. Workers can answer their individual questions correctly while their conclusions conflict. The orchestrator’s output must resolve those relationships or preserve the unresolved conflict; concatenating reports does not complete synthesis. Detailed delegation mechanisms belong to subsection 1.4.

Refine only when evaluation can help

Evaluator-optimizer uses one model call to generate a response and another to evaluate it and provide feedback. Anthropic identifies two conditions: clear evaluation criteria and measurable value from iterative refinement. The evaluator must be able to articulate feedback the generator can use.

Separate “the evaluator liked it” from the required outcome. Give the evaluator specific criteria, preserve its feedback, and measure whether revisions improve acceptance. If feedback remains vague or repeated revisions do not help, the loop has not earned its extra calls.

Define a terminal outcome for unresolved criticism and an application-owned iteration limit. Those are workflow controls, not a built-in evaluator-optimizer API. A bounded refinement loop remains a workflow when its generator, evaluator, feedback transition, and exits follow the designed structure.

Key distinctions and trade-offs

The deciding properties differ across patterns:

Pattern	Deciding task property	Added responsibility
Prompt chaining	Ordered handoffs must be inspected or enforced	Intermediate gates and dependency preservation
Routing	Distinct categories need specialized treatment	Accurate classification and an exception handler
Parallelization	Independent parts or useful diverse attempts	Join completeness and aggregation rules
Orchestrator-workers	Assignments cannot be listed in advance	Assignment quality and cross-worker synthesis
Evaluator-optimizer	Clear feedback measurably improves the result	Evaluator quality and bounded termination

A variable number of workers distinguishes orchestration from predetermined sectioning. A repeated call distinguishes neither evaluation nor voting by itself: evaluation feeds critique into revision, while voting aggregates attempts. A fixed sequence of draft, review, and revision can express self-correction without committing to an indefinite refinement loop.

Architecture / decision scenario

A retail team launches regional product pages with a thirty-minute publication-preparation target. Publication requires approved claims, consistent specifications, and reviewed translations.

The architect keeps specification extraction before copy generation as a chain because the copy depends on validated facts. A router selects the regional policy handler from a supported market list; an unresolved market goes to the merchandising team.

Independent claim and formatting checks run as sectioned parallel work. A high-risk claim can receive multiple independent review attempts with an any-positive escalation rule, rather than silently applying majority voting. Translations wait for approved source copy because they depend on it.

A cross-brand campaign needs an orchestrator to discover which product teams must contribute evidence. Ordinary single-product pages retain predefined assignments. For wording that fails clear editorial criteria, evaluator feedback drives a bounded revision loop; unresolved claims go to review rather than further stylistic refinement.

All five patterns have a specific job. The team does not deploy all five on every page, and the target includes the join, revision, and human exception paths. The dependency map explains why each added call exists.

Common exam traps

Parallelizing dependent outputs because concurrent calls appear faster.
Calling a predefined worker list orchestrator-workers.
Using routing when categories cannot be classified reliably.
Treating majority agreement as an independent factual check.
Adding an evaluator without actionable criteria or measured improvement.
Extending a refinement loop indefinitely because its output sounds better.

What to remember

Select from dependencies, category separation, independence, emergent assignments, and useful feedback. Combine patterns only where those properties coexist. Keep intermediate gates, joins, synthesis, and exits explicit so the workflow’s shape remains an operable decision.