Agentic Design Patterns, Part 2: The Workflow Patterns That Make Agents Reliable

Prompt chaining is the entry point because it fixes the most common failure mode: asking one prompt to summarize, extract, transform, judge, and format all at once. Decomposing the work into smaller steps gives each stage a narrower job and makes debugging possible. You can improve a chain because you can inspect it. You cannot improve a monolith nearly as easily because you do not know which internal move actually failed.

Routing exists because not every request deserves the same prompt, model, tool set, or workflow depth. Good routing sends easy work down cheap paths and harder work into deeper workflows. Parallelization exists because many jobs contain independent subproblems that should not wait on each other. Both patterns are really about operational efficiency, not elegance.

• Route heterogeneous tasks to specialized logic instead of forcing one generic path
• Parallelize independent work when aggregation is easier than sequential waiting
• Make the routing criteria and merge logic inspectable so failures stay diagnosable

Reflection is one of the most important patterns because it converts generation into a loop instead of a one-time act. A critique step can catch weak evidence, shallow reasoning, formatting errors, or bad tool choices. Tool use changes the system's ceiling in a different way. Once the model can call APIs, browse, execute code, or inspect external state, it is no longer trapped inside its weights.

Both patterns are powerful, but both create failure surfaces. Reflection can become expensive or circular if you do not bound it. Tools create authorization, validation, and security problems the moment they touch the real world. The pattern only helps if the control layer is as serious as the capability layer.

Planning is valuable for long-horizon tasks because it introduces explicit subgoals and a structure for revising them as reality changes. Multi-agent decomposition can be useful when role specialization genuinely maps to the problem. But the summary is right to resist romanticizing either one. Plans become brittle when detached from feedback, and multi-agent systems create coordination overhead, token cost, and debugging pain fast.

The right lesson is not that more agents or more planning is always better. It is that decomposition should match the structure of the job. If it does not, you are just multiplying moving parts.