Multi-agent architectures have quietly become the default for anything more ambitious than a single-turn chat, but when to reach for them — and how to keep them from blowing up your token budget — is still guesswork in most codebases. In this 26-minute LangChain talk, Colin Flaherty lays out a clean, prescriptive mental model built on top of Deep Agents: sub-agents are just a way to parallelize work and control what returns to the parent context, and there are exactly four patterns worth memorizing.

If your Claude Code or LangGraph project has more than one Task(...) call in it, this is the piece to watch.

Static vs dynamic — pick the right knob

Static sub-agents fan out at plan time; dynamic ones decide at run time

Flaherty opens by separating the two flavors:

  • Static sub-agents — the parent agent knows at plan time that it wants to fan out (e.g. “for each file in this PR, review it”). The plan enumerates the calls up front.
  • Dynamic sub-agents — the parent agent decides at runtime, mid-execution, that a piece of work benefits from being handed off in parallel.

The interesting design surface is dynamic. Static fan-out is just a map. Dynamic requires giving the agent both the ability to write code that spawns work and a discipline around what comes back.

Code, not tokens, is the coordination layer

Sub-agent results returned through a task global, not shoved back into the parent’s context window

The core mechanical claim: in Deep Agents, dynamic sub-agents are launched from code the parent agent writes. Results come back through a shared task global, not by concatenating the sub-agent’s transcript into the parent’s context window.

Two things fall out of that decision:

  1. The parent’s context stays clean. Completeness of a batch job stops depending on how well the parent can hold N sub-transcripts in its head.
  2. You can express the whole workflow — spawn, collect, aggregate, filter — as ordinary code. The LLM writes the code; the runtime executes it deterministically. That is what he means by putting workflow in your request.

The four patterns

Pattern 1 — Triage / classify-and-route

Triage: each ticket gets routed to a specialized sub-agent by class

Input: a batch of heterogeneous items (support tickets, PR files, incoming emails). Each item needs a different handling path depending on class.

Shape: parent classifies, then dispatches each item to a class-specific sub-agent in parallel. All bug-report tickets flow to one sub-agent, feature-request tickets to another, etc. Reach for this when items have very different downstream needs and the class is cheap to determine.

Pattern 2 — Parallel batch with a single consolidated report

Input: a homogeneous batch, one workflow per item, need one unified report at the end.

The talk’s example: “Review every file in this PR and produce a single prioritized report of the top findings.” The parent fans out one sub-agent per file, each performs the same review, and the parent consolidates. Straightforward map-reduce, but done through code + task-global so the parent context stays a summary.

Pattern 3 — High-confidence deep inspection

High-confidence pattern: focused deep dive on a single target

Input: a single high-stakes target where you want maximum thoroughness — a security-critical file, a suspect regression, an audit target. You want a sub-agent that gets its own clean context, plenty of tool budget, and returns a structured verdict.

Flaherty’s example: a targeted security review of one file. The sub-agent confirms 22 of 26 findings with 4 marked uncertain — the parent gets a clean structured result rather than 8k tokens of thinking-out-loud. Reach for this whenever you want isolation and depth on one item rather than breadth.

Pattern 4 — Generate-and-filter (candidate competition)

Generate multiple candidates in parallel, then filter through an evaluator

Input: a problem with multiple reasonable solutions where you don’t know which is best (rate-limiter design: token bucket, sliding window, leaky bucket).

Shape: spawn N sub-agents to generate candidates in parallel, then spawn a filter/evaluator sub-agent that picks. The parent never has to hold the competing implementations in its own context — the filter returns the winner as a structured diff object with justification.

Flaherty calls out the subtle payoff: response schemas from each sub-agent are what makes this work. The evaluator receives structured candidates, not raw transcripts, so the picking step is bounded.

Putting it together: nested workflows

The closing example is a “thorough security review” that composes the patterns: broad triage first (pattern 1), parallel batch across all five files (pattern 2), high-confidence deep dive on the flagged file (pattern 3), then a final generate-and-filter for the recommended remediation (pattern 4). Each layer contributes a clean structured output; the parent context never balloons.

Practical guidance

The talk closes with a rule of thumb: when in doubt, break the task into more, smaller sub-agents rather than fewer, larger ones. Small sub-agents with tight response schemas are cheap to debug, easy to parallelize, and their failure modes stay local. The pathology to avoid is one giant “do everything” sub-agent whose output is a wall of text you now have to re-parse.

Key takeaways

  1. Static ≠ dynamic. Fan-out at plan time is a map; fan-out at run time needs code-as-coordination.
  2. Results return via task-global, not context concatenation. The parent’s window stays clean.
  3. Pattern 1 — Triage/route heterogeneous items to class-specific sub-agents.
  4. Pattern 2 — Parallel batch with a single consolidated report; classic map-reduce.
  5. Pattern 3 — High-confidence deep dive on one target for maximum thoroughness with a structured verdict.
  6. Pattern 4 — Generate-and-filter competing candidates, then a separate evaluator picks the winner.
  7. Response schemas are load-bearing. Structured returns are what keep the parent’s context bounded.
  8. Prefer many small sub-agents over few large ones. Failures stay local; parallelism is cheap.

Source