Workflows vs Agents: Orchestration & Reliability

"Should this be an agent?" is the most common design question in applied AI right now, and the usual answer is less exciting than people hope: often not. Anthropic's engineering team, in its widely read guide on building effective agents, draws a line that is worth learning, and then argues for starting on the simpler side of it.

A recipe is a fixed list of steps. Anyone can follow it and get a predictable dish, and you can test it. A chef improvises: they taste, adjust, and decide what to do next. A chef can handle a surprise ingredient, and may also ruin the dinner in a way a recipe never would. A workflow is a recipe, and an agent is a chef.

• -A workflow orchestrates model calls and tools through paths written in code. The steps and their order are decided by the developer.
• -An agent lets the model decide its own steps and which tools to use, looping until it finishes. The model directs the process.

Agents suit open-ended problems where you cannot predict the number of steps or hard-code a path. They cost more, are slower, and their errors compound, so they need thorough testing in a sandbox with guardrails. The guide's core advice: find the simplest solution, often a single well-prompted call with retrieval, and add complexity only when it measurably improves outcomes.

• -Prompt chaining: split a task into fixed sequential steps, each model call working on the previous output, with optional checks between them. Use it when the task decomposes cleanly and you will trade some latency for accuracy.
• -Routing: classify an input and send it to a specialized handler. Use it when distinct categories need different treatment and can be classified accurately.
• -Parallelization: run calls at the same time, either on independent parts of a task (sectioning) or on the same task several times (voting), and combine the results in code. Use it for speed or for extra confidence.
• -Orchestrator-workers: a central model breaks a task into subtasks it did not know in advance, delegates them to workers, and merges the results. Use it when the subtasks cannot be predicted, such as changes spread across many files.
• -Evaluator-optimizer: one model drafts, another critiques, and the loop repeats. Use it when you have clear criteria and refinement measurably helps.

Every step can go wrong. If each step is right 95% of the time, ten steps in a row are all right only 0.95¹⁰, about 60% of the time. The longer the chain, the faster reliability falls. That is the arithmetic behind the advice to keep chains short and to put checks into them. The code computes it, and then shows two repairs. The first adds a check that catches most failures and retries. The second takes a majority vote across three independent answers. Press Run and read each section.

At 90% per step, a chain of 10 steps succeeds 34.9% of the time, and 20 steps only 12.2%. Even at 99% per step, 20 steps give 81.8%. Now add a check that catches 90% of failures and allows two retries. The effective success of one step rises to 98.8%, and ten steps succeed 88.9% of the time instead of 34.9%. Voting helps too: three independent answers that are each right 80% of the time give a majority that is right 89.6% of the time. Both rely on the checks or votes being independent and good, so a judge that shares the original model's blind spot repairs less than the numbers suggest.

Try the demo below. Set how reliable one step is and how long the chain is, then add a check with retries and compare the two curves to see how much of the loss a check can win back.

• -Start with one call. Add retrieval and examples. Measure with an eval.
• -If one call is not enough, use a workflow: a chain, a router, or parallel calls, with checks.
• -Use an agent only when the path cannot be written down in advance, and give it limits: a maximum number of steps, a budget, tools with narrow permissions, and a human approval step for risky actions.
• -Measure each added layer. Keep it only if the success rate improves enough to justify the extra cost and latency.