Skip to main content
Lesson 12. You now understand the technical difference between single LLM calls, workflows, and agents. The practical question remains: which one should you build for a given problem? Choosing the wrong approach has real consequences — more expensive runs, higher latency, brittle systems, and harder debugging. Use one guiding principle: start with the simplest solution that will do the job, and only add complexity when necessary. Most tasks do not require an agent. Often a single LLM call or a straightforward workflow is enough. Before you build, ask the simplest question: can a single LLM call handle this? If yes, use that. If you need multiple calls in a fixed sequence, use a workflow. If the LLM must decide its own steps based on discoveries at runtime, consider an agent. Each step up the ladder (single call → workflow → agent) adds cost, latency, and complexity — so justify the upgrade.
A retro-style infographic titled "Start Simple" that advises adding complexity only when needed. It compares three approaches: "Single LLM Call" (one request, one response) on the left, "Workflow" (fixed sequence of steps) in the center, and "Agent" (decides its own path) on the right.
Only move to a more complex approach when the simpler one genuinely can’t do the job.

​
When to choose a workflow

Workflows are best when the problem is well understood and the sequence of steps can be defined up front. They are predictable, easy to debug, and cost is easier to control. Common workflow use cases include:
  • Email classification and templated responses
  • Daily briefing or report generation
  • Structured data extraction pipelines
  • Translation chains or other deterministic processing chains
These are repeatable, deterministic tasks: every input follows the same path even if the inputs vary.
The image is a dark, grid-styled slide titled "When Workflows Win" with icons and labels for examples like Email Classification, Daily Briefing, Data Extraction, and Translation Chains. Below are green-highlighted checklist boxes noting characteristics such as "Steps Known," "Debuggable," "Predictable," and "Cost Fixed."

​
When to choose an agent

Use an agent when the correct path cannot be determined ahead of time and the LLM must adapt or explore at runtime. Agents provide flexible orchestration: they decide which tools or steps to use based on what they discover. Typical agent scenarios:
  • Trip planning that requires multi-step research and trade-offs
  • Personal assistants coordinating dynamic tasks and contexts
  • Complex scheduling where constraints emerge during the interaction
  • Coding assistants that iteratively inspect, edit, and rerun code
These tasks are open-ended: different inputs may trigger different paths and the system benefits from on-the-fly decision-making.
The image is a retro-style infographic titled "When Agents Win" with icons and labels for open-ended tasks like Trip Planning, Personal Assistant, Complex Scheduling, and Coding Assistant. Below are four highlighted criteria: "Steps can't be predicted," "Task requires flexibility," "Open-ended problems," and "Environment gives feedback."

​
Trade-offs and costs

Agents introduce additional operational complexity:
  • Higher per-request compute costs
  • Increased latency due to multiple LLM calls and tool invocations
  • Greater surface area for bugs and unexpected behavior
  • More effort required to test and debug decision logic
Conversely, forcing a workflow on an open-ended problem leads to brittleness: it will break on unanticipated inputs and require frequent, costly updates.
Agents add flexibility at the cost of predictability and price. If strict cost or latency constraints exist, prefer workflows or enforce strong guardrails on agents.

​
Decision checklist — quick diagnostic

Run through these four questions to guide the choice. Answering “Yes” or “No” points you toward the simpler, more robust option when possible.
A retro-styled "Decision Checklist" table comparing Workflow vs Agent across four questions (paths defined in advance, LLM decides next step, well-defined/repeatable, cost strictly controlled) using green checkmarks, red Xs and an orange dash. Workflow is checked for most items while the Agent is only checked for "LLM decides next step," with mixed marks elsewhere.
Use the checklist above: if most answers point to a workflow, start there. If answers lean toward openness and runtime decision-making, design an agent — and add guardrails to control cost and behavior.

​
Combining workflows and agents

Production systems often need both. A common pattern is a hybrid design:
  • Use a workflow to orchestrate predictable, repeatable parts (validation, batching, fixed transforms).
  • Insert an agent for sub-tasks that require exploration, adaptive decision-making, or tool usage.
  • Start with a workflow; if it hits a limitation, extract the decision-heavy portion into an agent with clear interfaces and safety checks.
This hybrid approach balances predictability and flexibility.
An infographic titled "Best Systems Combine Both" that shows a workflow (predictable parts) plus an agent (flexible parts) equals a "Flexible Hybrid." A caption at the bottom advises to start simple with a workflow and add an agent when needed.

​
Summary

  • Workflows follow a path you design; agents decide their own path.
  • Most tasks are best handled by a single LLM call or a workflow.
  • Use an agent only when runtime adaptability, exploration, or tool orchestration is required.
  • The wrong choice increases cost, latency, and debugging burden.
  • Start simple; add complexity only where it provides clear value.
A neon-styled infographic titled "What You Need to Remember" showing four colored boxes with tips about workflows and agents (e.g., "Workflows follow a path," "Agents decide their path," "Most tasks need workflows," "Wrong choice costs"), plus a "Your Next Steps" checklist at the bottom.
Further reading and references:

Watch Video