Workflow, agent or augmented LLM, the problem picks the pattern

The sponsor saw a demo and asks for “an agent”. The risk team asks for every case to follow the same auditable path. Finance asks for the cost per case not to spike. Choosing the pattern is the first architecture decision, and it is almost always decided by the shape of the problem, not by what the client asks for.

Three patterns, one question

The question is: can you know in advance which steps are needed?

• Augmented LLM: a single model call with retrieval, tools or memory. It fits when the task is solved in one step: answering from documents, extracting fields, classifying.
• Workflow: the steps and their order are defined in code. The model solves each step, but it doesn’t choose the path. It includes prompt chaining, with code checks between steps, routing and parallelization.
• Agentic pattern: the model decides which tool to use and when to stop, in a loop. It fits when the number of steps can’t be predicted because each result decides the next one.

If the scenario says…	Go with
“Always the same steps, in the same order”, “auditable”, “regulated”	Workflow
“Each result decides what to check next”, “sometimes 1 step, sometimes 6”	Agent, with a stopping condition
“Answer questions from the knowledge base”	Augmented LLM

The underlying rule: start with the simplest thing that works and add complexity only when it improves a measurable outcome. An agent gives autonomy in exchange for predictability, higher cost and errors that compound across steps.

When multi-agent is justified

An orchestrator-workers design pays off when at least one of these conditions holds:

• the work can be parallelized into independent parts (40 companies to research, 300 contracts to review);
• the work doesn’t fit in a single context;
• it needs many different tools that would confuse a single agent.

If the steps are sequential and each one needs what the previous one saw, splitting them into subagents only adds handoffs: more tokens, more latency and context lost at every hop. A single agent with good tools is enough and costs less.

When there are subagents, each one needs a clear objective, explicit boundaries (what it owns and what it doesn’t), just the tools it needs and an output format. And it returns a condensed summary to the orchestrator, not its raw notes.

The usual traps

• The agent “because the sponsor asked for it”: a regulated, predictable process is a workflow, even if the request says otherwise. Explain the trade-off in terms of audit and risk.
• Multi-agent by default: four subagents in sequence, each passing a short instruction to the next. The fix is not another reviewer subagent or passing the whole history to each one, but going back to a single agent.
• More fixed branches in a chain that can’t keep up: if the number of steps can’t be predicted, adding predefined paths never ends. That is the signal to move to an agent.
• One giant prompt for a big task: a single request that has to do everything fails in parts. That calls for decomposition, not a model with more context.
• Agents that “negotiate” the final decision among themselves, with no defined path and no person who decides.

In the exam

Look in the scenario for the sentence that describes the shape of the steps: “always in that order” points to a workflow with code checks; “each diagnostic decides the next one” points to an agent with a stopping condition and human approval for anything that changes something. If the scenario describes a slow, expensive multi-agent system where nothing runs in parallel, the answer is usually to simplify. Be wary of options that add components (another agent, another reviewer model) without addressing the cause.