Workflow Patterns and Multi-Agent Orchestration: Matching Pattern to Task

1.Prompt chaining and routing: fixed paths with easier steps

All workflow patterns have one thing in common: code fixes the control flow, and each LLM call gets a narrower job. The simplest is prompt chaining. It splits a task into a sequence of steps, and each LLM call works on the output of the one before. You can add programmatic checks, called gates, on any intermediate step to make sure the process is still on track. Chaining fits tasks that split cleanly into fixed subtasks. You accept extra latency, and in return each call has an easier job and accuracy goes up. Anthropic's examples are writing marketing copy and then translating it, and writing an outline, checking it against criteria, and then writing the document from it. The cookbook chain does the same with data. One step extracts metrics from a quarterly summary, later steps normalize and sort them, and the last step formats them as a table.

Routing classifies an input and sends it to a specialized follow-up task. This separates concerns and lets you write more specialized prompts. Without routing, tuning a single prompt for one kind of input can hurt performance on others. Routing works when the categories are distinct and the classification is accurate, whether an LLM or a traditional classifier does it. Anthropic gives two examples. One sends general questions, refund requests and technical support down different processes. The other sends easy or common questions to smaller, cheaper models like Claude Haiku 4.5 and hard ones to more capable models. Managed Agents applies the same cost logic to multiagent work with its escalation pattern, where harder subtasks go to a more capable agent or model.

Sources12

2.Parallelization versus orchestrator-workers: who decides the subtasks

Parallelization runs LLM calls at the same time and combines their outputs in code. It comes in two forms. Sectioning splits a task into independent subtasks. One example is a guardrail, where one model instance screens a query for inappropriate content while another writes the response. That tends to work better than asking one call to do both. Voting runs the same task several times to get diverse outputs, for example several prompts each reviewing code for vulnerabilities. Use parallelization when splitting the work saves time, or when you need several perspectives to be more confident in the result.

Orchestrator-workers looks similar in a diagram, but it works differently. A central LLM breaks the task down at runtime, delegates the pieces to worker LLMs, and combines their results. The difference is flexibility: in parallelization your code defines the subtasks, while here the orchestrator decides them for each input. The cookbook says when not to use it: when subtasks are predictable (use simpler parallelization instead) and when latency is critical. Managed Agents describes the same fan-out pattern, where a coordinator sends independent subtasks to agents at the same time and combines the results. The research example below shows the shape. A lead agent splits the query into facets, runs one subagent per facet concurrently, and synthesizes the findings.

async def research_topic(query: str) -> dict:
    # Lead agent breaks query into research facets
    facets = await lead_agent.decompose_query(query)

    # Spawn subagents to research each facet in parallel
    tasks = [
        research_subagent(facet)
        for facet in facets
    ]
    results = await asyncio.gather(*tasks)

    # Lead agent synthesizes findings
    return await lead_agent.synthesize(results)

Sources123

3.Evaluator-optimizer, verification, and the cost of multiple agents

In the evaluator-optimizer pattern, one LLM call generates a response and another evaluates it and gives feedback, in a loop. It works when you have clear evaluation criteria and refining the output adds measurable value. Look for two signs of a good fit. First, responses clearly improve when someone gives feedback. Second, an LLM can give that feedback itself. Anthropic's examples are literary translation and complex search, where the evaluator decides whether more searching is needed. A related multi-agent version is the verification subagent, whose only job is to check the main agent's work. It works well because verifying something needs very little context.

Every multi-agent design comes with a cost structure you need to know. On Managed Agents, each agent runs in its own isolated thread with its own model, prompt and tools. Anthropic's guidance names three situations where multiple agents reliably beat one: context pollution that degrades performance, work that can run in parallel, and specialization that improves tool selection or focus. Outside those situations, the cost of coordinating the agents is usually higher than the benefit. Multi-agent systems typically use 3 to 10 times more tokens, and they often take longer overall, so their main benefit is thoroughness, not speed. When you do split the work, divide it by context, not by job role. Planning, implementing and testing the same feature share too much context to separate.

On Managed Agents, you set up a coordinator by declaring which agents it can delegate to:

---
name: Engineering Lead
model: claude-opus-5-5
tools:
  - type: agent_toolset_20260401
multiagent:
  type:  ? 
  agents: # paths: ant apply substitutes {type: agent, id, version}
    - ./reviewer.md
    - ./test-writer.md
---

Sources124

Exam traps

Each one states something that sounds right. Open it to see what is actually true.

1. 1.Orchestrator-workers is just parallelization with a different name, since both fan work out to several LLMs.Why is that wrong?

   They look similar in a diagram but differ in who defines the subtasks. In parallelization, code defines them in advance. In orchestrator-workers, the orchestrator decides them for each input.

   Covered in Parallelization versus orchestrator-workers: who decides the subtasks

2. 2.Choose a multi-agent architecture when the main requirement is lower latency.Why is that wrong?

   Multi-agent systems use several times more tokens and often take longer overall. They are worth it for thoroughness, such as covering a large search space, not for speed.

   Covered in Evaluator-optimizer, verification, and the cost of multiple agents

3. 3.The cleanest way to decompose work across agents is by role: planner, implementer, tester, reviewer.Why is that wrong?

   Decompose by context boundaries, not by type of problem. Split work only where its context can truly be isolated.

   Covered in Evaluator-optimizer, verification, and the cost of multiple agents