Workflow vs Agent: Choosing the Right Architecture.

Anthropic's own canonical taxonomy ("Building Effective Agents", Dec 2024 - still the reference doc for this objective) names three tiers of increasing autonomy. An augmented LLM is a single call enhanced with retrieval, tools, or memory but no orchestration layer. A workflow is LLMs and tools orchestrated through predefined code paths - the sequence is fixed by the architect, not the model. An agent is a system where models dynamically direct their own process and tool use, maintaining control over how they accomplish a task - the number and order of steps can't be predetermined.

The architect's job is picking the cheapest, most predictable tier that satisfies the requirement, not defaulting to the most autonomous option available. Anthropic states this directly: "Success in the LLM space isn't about building the most sophisticated system. It's about building the right system for your needs. Start with the simplest solution possible, and only increase complexity when needed." The enterprise framing sharpens this further - the choice is justified by task unpredictability and value at stake, not technical preference.

Within the workflow tier, Anthropic names five specific patterns. Prompt chaining runs sequential steps, optionally with a programmatic checkpoint between them. Routing classifies the input first, then dispatches to a specialized downstream path. Parallelization runs simultaneous LLM calls, either sectioning a task into independent pieces or voting across redundant attempts. Orchestrator-workers has a central LLM decompose a task and delegate pieces to workers, then synthesizes their results. Evaluator-optimizer pairs a generator with a critic in an iterative refine loop.

Agents differ structurally, not just in degree: "as agents gain complexity, they begin to make more autonomous decisions... their control flow is directed by the LLM itself" rather than by predefined code. That single fact drives the tradeoff - a workflow's fixed path is cheaper, faster, and easier to evaluate for a genuinely predictable task; an agent earns its cost only when the task is open-ended enough that no fixed path could cover it.

A manager/supervisor architecture - one coordinator LLM that decomposes work and dispatches it to subagents - looks like orchestrator-workers on the surface, but which pattern it actually is depends on who decides the decomposition, not on whether subagents are involved. If the split is fixed code ("always send billing questions to worker A, technical to worker B"), it's a workflow using the routing pattern - the branches are predetermined, so this is not orchestrator-workers even though it dispatches to "workers." Orchestrator-workers specifically requires the manager LLM to decide, at run time, how to split and re-split the work as it learns more; only that dynamic-decomposition case earns the orchestrator-workers name (and, if the re-planning is genuinely open-ended, may cross into agentic territory). Either way, subagents improve task execution by giving each worker a clean, narrow context window focused on one piece of the problem - the tradeoff is that a standard subagent does not see the coordinator's conversation history, so the manager must pass every fact a worker needs explicitly in its task string.

Because the three tiers share primitives (an LLM call, optional tool use, optional multi-step orchestration), a single production system routinely mixes them: an agent's one tool call can itself trigger a fixed workflow, and a workflow step can be an augmented LLM call with no further orchestration. The decision is per-component, not a single label for the whole system.