Most "we need an agent" requests need a workflow. This playbook applies the industry's shared design vocabulary — prompt chaining, routing, parallelization, orchestrator–workers, evaluator–optimizer — to classify a use case and select the simplest pattern that works, with full autonomy reserved for cases that actually justify it.
Tier: Core · Hands-on time: ~30 minutes
Anthropic's "Building Effective Agents" pattern taxonomy has become the de-facto agent design vocabulary — mirrored in Spring AI documentation and echoed in the AWS Agentic AI Lens design principles — which makes it the rare piece of this fast-churning field an architect can standardize on. The taxonomy's core discipline is the point: workflows (predefined code paths with LLM steps) before agents (LLM-directed control flow), and the simplest pattern that clears the requirement wins.
Write the task as steps and decisions, without AI words. Inputs, transformations, decision points, outputs, and error paths — as if specifying it for a junior engineer. If you cannot enumerate the steps, note where the genuine open-endedness lives; that is the only place agency might belong.
Classify against the five patterns, in escalating order. Prompt chaining — fixed sequence, each step's output feeds the next; fits decomposable tasks with a known order. Routing — classify the input, dispatch to a specialized path; fits heterogeneous inputs with distinct handling. Parallelization — independent subtasks fan out and aggregate (sectioning or voting); fits volume and multi-perspective checks. Orchestrator–workers — a central LLM decomposes dynamically and delegates; fits tasks where subtasks cannot be predicted upfront. Evaluator–optimizer — one LLM generates, another critiques in a loop; fits tasks with clear evaluation criteria and value in iteration. A true agent — LLM-directed control flow with tools — is the escalation past all five, justified only when the path genuinely cannot be predetermined.
Make the AI attack your classification. Rajesh is classifying the Meridian Retail order-status feature the RFP calls an "agent":
I've classified a use case and want you to attack the classification.
Use case: customer asks about an order; system looks up order status,
shipping events, and return eligibility; composes an answer; escalates
to a human when the account has an open dispute.
My classification: routing (query type -> one of three fixed lookup
paths) + prompt chaining (lookup -> compose -> policy check). No agent:
the tool sequence is predictable per query type.
Attack it three ways:
1. What inputs would break the fixed paths and genuinely require
dynamic tool selection?
2. What is the cost of misclassification at the router, and how would
I measure router accuracy?
3. If volume of edge cases grows, what is the trigger that would
justify escalating to orchestrator-workers or a real agent?
Do not upgrade the design for elegance. Simpler wins ties.
Price each candidate pattern. More autonomy costs more everywhere: tokens per request (agent loops multiply calls), latency (sequential loops stack), testability (predefined paths are testable; emergent paths need evals), and failure surface (pb-38's blast-radius work grows with agency). Put rough multipliers next to each candidate.
Choose the simplest pattern that clears the requirement — and write down the escalation trigger. The design says: pattern chosen, patterns rejected and why, and the measurable condition (edge-case rate, new task classes, router accuracy floor) that reopens the decision. This makes "we chose the simple thing" defensible rather than timid.
Sketch the selected pattern with its control points. Even a workflow gets drawn: where the LLM steps sit, where deterministic code owns control flow, where structured outputs constrain interfaces, and where a human gate sits if failure costs demand one.
Name it correctly in every artifact. If it is routing plus chaining, the design doc says so — "agent" appears only where LLM-directed control flow actually exists. Vocabulary discipline is what makes the next review faster.
Pattern classification needs no client data — describe the use case abstractly (task shape, decision points, failure costs) and the exercise works in any approved assistant, or fully offline with a local model via Ollama. The MSA discipline bites at the sketch stage: real system names, API surfaces, and client vocabulary stay out of external tools; keep the annotated diagram in client-approved tooling. Where an engagement's deliverable includes this classification, the pattern worksheet with justifications is itself client work product — produce it inside the client boundary.
Classify before you build: five named patterns in escalating order, the simplest one that clears the requirement, autonomy justified in writing, and a measurable trigger for revisiting — that is the whole discipline.