Workflows vs. Agents vs. Subagents: Choosing the Right Tool in Agentic Coding
Spend a week with modern AI coding tools and you'll hear "agent," "subagent," and "workflow" used as if they were synonyms. They aren't. They sit at different points on a single spectrum — from "let the model decide everything" to "the code decides, the model fills in the gaps" — and picking the wrong one is how teams end up with runs that are either too rigid to be useful or too loose to be trusted. This is a practical guide to what each one is, when to reach for it, and how to combine them.
First, untangle the words
The confusion is understandable, because each term names a different axis of the same system. Here's the working vocabulary we'll use.
- Agent — a model in a loop with tools. It reads, decides, calls a tool, observes the result, and repeats until the task is done. The defining trait is autonomy: the control flow is chosen by the model at runtime, not written down in advance. Your main coding assistant in the terminal is an agent.
- Subagent — an agent spawned by another agent to handle a scoped piece of work in its own fresh context, returning just a result. The point isn't more intelligence; it's context isolation and parallelism. A subagent can read 40 files and hand back a three-line conclusion, so the parent's context stays clean.
- Workflow — a deterministic program (loops, conditionals, fan-out) that orchestrates one or more agents. The structure is fixed in code; the agents fill in the judgment-heavy steps. A workflow is what you reach for when you want to own the control flow and only delegate the fuzzy parts.
The single most useful distinction: in an agent, the model decides what happens next; in a workflow, the code decides what happens next and calls models as steps. Subagents are an implementation detail either can use to stay fast and focused.
The spectrum, from loose to structured
| Single agent | Agent + subagents | Workflow | |
|---|---|---|---|
| Who controls flow | Model | Model (delegates) | Code |
| Determinism | Low | Low–medium | High |
| Best for | Open-ended, exploratory | Big context, parallel scouting | Repeatable, structured fan-out |
| Token cost | Low | Medium | Medium–high |
| Reproducibility | Hard | Hard | Easy (same script, same shape) |
When a single agent is the right answer
Most coding tasks are best served by one capable agent. If the work is exploratory — "figure out why this test is flaky," "add a field to this form and wire it through" — you want the model to choose its own path, because you don't know the steps in advance either. Reaching for orchestration here just adds latency and cost without buying control you need.
Rule of thumb: if you can't write down the steps ahead of time, don't try to. Let the agent run. Add structure only when you find yourself doing the same multi-step dance repeatedly, or when one context can't hold the whole job.
When to add subagents
Subagents earn their keep in three situations, and they're worth recognizing because they're the most under-used of the three tools.
- Context would overflow. A task that means reading across dozens of files — "where is authentication handled across this monorepo?" — pollutes the main context with file dumps you'll never need again. Send a subagent to sweep and return the conclusion. You keep the answer, not the noise.
- Work is genuinely parallel. Reviewing a diff along five independent dimensions (security, performance, correctness, style, tests) is five jobs that don't depend on each other. Run them concurrently as subagents and you get five perspectives in roughly the time of one.
- You want independent perspectives. Asking three fresh subagents to refute a proposed finding — each blind to the others — is a cheap, powerful way to kill plausible-but-wrong conclusions before they reach you. This adversarial-verification pattern is one of the biggest quality wins in agentic work.
💡 Subagents are about context, not horsepower. A subagent isn't "smarter" than the parent — it just starts clean and works in isolation. Use them to protect the main thread's attention and to fan work out, not in the hope of a better answer from the same model.
When to graduate to a workflow
A workflow is the right tool when the shape of the work is known even if the content isn't — and when you want that shape to be reliable, repeatable, and auditable. Signs you've outgrown a single agent:
- You need the same structure every time. "For each changed file, review it, then adversarially verify each finding, then synthesize" is a pipeline. Encoding it as code means it runs the same way on Tuesday as it did on Monday — no prompt drift.
- The job is too big for one context. Migrations, audits, and broad sweeps across hundreds of files exceed what any single run can hold. A workflow decomposes the work, runs pieces in parallel, and assembles the results.
- You want confidence through structure. Generate N independent solutions, score them with a judge panel, synthesize from the winner. That's a tournament — deterministic scaffolding around non-deterministic agents.
- You need loops with real stopping conditions. "Keep finding bugs until two consecutive rounds turn up nothing new" or "fan out until the token budget is spent" are control-flow decisions that belong in code, not in a model's discretion.
The pattern that ties workflows together is pipeline by default, barrier only when needed. A pipeline runs each item through all stages independently — item A can be in stage three while item B is still in stage one — so wall-clock time is the slowest single chain, not the sum of stages. You only force a barrier (wait for all of stage one before starting stage two) when a later stage genuinely needs every prior result at once — to deduplicate findings, say, or to bail early if the count is zero.
A decision guide
When you're unsure which to reach for, walk down this list and stop at the first "yes":
- Can you write the steps down in advance, and will you run them more than once? → Workflow.
- Is the job too large for one context, or made of independent parallel parts? → Agent with subagents (or a workflow, if it's also repeatable).
- Do you need a second, independent opinion to trust a result? → Subagents for adversarial verification.
- None of the above — it's open-ended and one-off? → A single agent. Don't over-engineer it.
The costs nobody mentions up front
Orchestration isn't free, and the failure mode of "more agents = better" is real.
- Tokens multiply. Ten subagents reading the same context cost roughly ten times the input. A workflow that fans out aggressively can consume an order of magnitude more than a single agent for the same task. Fan out when the parallelism or coverage is worth it — not by reflex.
- Coordination overhead is real. Spawning, scheduling, and merging results adds latency. For small tasks, a single agent finishes before an orchestration layer has even handed out the work.
- Barriers waste wall-clock. If five reviewers run and the slowest takes three times the fastest, a needless barrier strands the four fast ones idle. Default to pipelines.
- Silent truncation reads as completeness. A workflow that quietly caps at "top 20 files" can look like it covered everything. If you bound coverage, say so — to yourself and to whoever reads the output.
Guardrails that apply at every level
Whichever you choose, the same disciplines from real-world agentic work apply — the ones we covered in Shipping Faster with Agentic AI Workflows and Least Privilege for AI Agents. More autonomy and more parallelism mean more surface area, so:
- Scope tools tightly. An agent — or a swarm of subagents — with broad write access is a broad blast radius. Default to read-only; gate anything destructive or outward-facing behind a human.
- Verify before you trust. Independent verification (a refutation pass, a judge, re-running tests) catches the confident-but-wrong answers that a single linear run sails right past.
- Make it observable. When work fans out, you need to see what each branch did. Logs, structured results, and progress you can watch are what keep an orchestration debuggable.
- Cap the spend. Token budgets and round limits turn "keep going until done" into something bounded and predictable.
The bottom line
There's no hierarchy here where workflows are "advanced" and single agents are "basic." They're different tools for different shapes of problem. Reach for a single agent when the path is unknown and the job is one-off; add subagents when context would overflow or work is genuinely parallel; graduate to a workflow when the structure is known, repeatable, and worth owning in code. The teams that get the most out of agentic coding aren't the ones that orchestrate everything — they're the ones who match the tool to the task, and who keep a human in the loop for the decisions that matter. If you want the foundations underneath all of this — the cloud, security, and automation skills these agents are operating on — that's exactly what our certification labs are built to teach.