When should teams choose workflows over agents?

Anthropic's engineering post, co-authored by Erik S. and Barry Zhang and published 2024-12-19, draws a hard line between "workflows" and "agents": workflows are "systems where LLMs and tools are orchestrated through predefined code paths," while agents are "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks." The post's central recommendation is to "find the simplest solution possible, and only increas[e] complexity when needed," which for many applications means "optimizing single LLM calls with retrieval and in-context examples is usually enough" before reaching for either workflows or full agents.

The reasoning given is a tradeoff, stated plainly: "Agentic systems often trade latency and cost for better task performance." Workflows earn their keep on well-defined tasks because they "offer predictability and consistency," while agents are justified only "when flexibility and model-driven decision-making are needed at scale." The post operationalizes this with named workflow patterns — prompt chaining, routing, parallelization, orchestrator-workers, evaluator-optimizer — each paired with a "when to use" condition keyed to how decomposable, classifiable, or iterable the task is; agents proper are reserved for "open-ended problems where it's difficult or impossible to predict the required number of steps, and where you can't hardcode a fixed path."

This sits alongside When should you actually deploy an AI agent instead of simpler automation? — both refuse to treat "agent" as the default unit of automation, but where McKinsey ties the choice to task variance and standardization at the business-process level, Anthropic ties it to decomposability and predictability at the system-architecture level, and adds a named taxonomy of intermediate workflow patterns McKinsey doesn't specify. It also gives an architectural vocabulary for why Can algorithms control LLM reasoning better than LLMs alone? works: that pattern is one instance of what Anthropic calls prompt chaining or orchestrator-workers, with "a classic program" supplying the predefined code path Anthropic's workflows are defined by.

The post is a practitioner's design argument, not a measured study — it reports what "we've worked with dozens of teams" and found, without naming the teams, the tasks, or any comparative numbers for workflows versus agents. It does not establish that simpler-first is optimal in any measured sense, only that Anthropic's engineers recommend it as a starting discipline. The implication, at the strength the post supports, is that a team reaching for an "agent" by default — rather than first checking whether the task is decomposable into a workflow — is adding latency, cost, and compounding-error risk the post argues is often avoidable.