Loading today’s stories
Build1 distinct publisher3 min readUpdated
A TypeScript walkthrough of orchestrator fan-out and pipelines makes the arithmetic explicit: parallel work costs the slowest subtask, serial work costs all of them.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
A dev.to walkthrough, "Building a Multi-Agent System in TypeScript," published working implementations of two patterns, orchestrator/subagent and pipeline [1]. The interesting part is not the TypeScript; it is that the piece states the cost function out loud, which means you can price the decision before you write any of it.
The arithmetic, as the article gives it: a single agent doing three fetches then an analysis costs T(A) + T(B) + T(C) + T(analyze) [3]. An orchestrator that spawns one subagent per target costs max(T(A), T(B), T(C)) + T(synthesize) [4]. If the three fetches take roughly the same time, the fetch phase drops from 3T to T, a factor of three [1]. If one target is slow and the other two are fast, the ratio between the two formulas collapses toward 1 and you have paid for concurrency machinery to save almost nothing [2]. Fan-out is worth exactly the gap between the sum and the maximum.
The second reason is budget, not speed. The article lists three limits on single agents: long tasks exceed context windows, complex goals need different tools at different stages, and sequential reasoning is slow when subtasks are independent [2]. Only the third is about latency. In the competitor pricing example, the serial agent fetches and processes each page in turn and each step burns context window [5], while the orchestrator hands each page to a subagent that processes it independently and returns output [6]. That is a per-agent window, not a shared one, and it is the argument that survives even when the subtasks are fast.
Where the pattern degrades is the dependency graph. Each SubTask carries a toolSet, an optional dependsOn list of task IDs, a priority and a timeoutMs [8], and the article is explicit that dependsOn is what makes the graph work while estimatedParallelGroups is only the LLM's suggestion about what can run together [11]. The executor filters each group down to tasks whose dependencies completed successfully, skips the group if nothing is executable, and writes results only for tasks that actually ran [14]. So if the model returns a plan where every task depends on the one before it, the orchestrator becomes the pipeline: one executable task per group, total time back to the sum, plus the extra planning call the decompose step makes at temperature 0 [4] [12]. Pipeline is not a lesser pattern; it is what you are running whether you named it or not.
Two operational details worth noting. The concurrency cap defaults to 3 [13], so a group of nine independent tasks needs at least three waves and the ceiling is a floor on latency [3]. And SubTaskResult defines a status of success, failed, timeout or skipped [9], but the loop shown never writes a result for a task it filtered out, so the results map has holes rather than skipped entries [5]. Downstream synthesis has to tolerate missing keys.
What to watch: instrument durationMs per subtask [9] and compare the maximum against the sum on real plans. If that ratio sits near 1, the decomposition is serial in disguise and the orchestrator is overhead. Also note that the material supplied here covers the orchestrator implementation, not the pipeline one [1], so treat the second half as unverified until you read it.
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
A dev.to article titled "Building a Multi-Agent System in TypeScript" walks through two patterns, Orchestrator/Subagent and Pipeline, implemented entirely in TypeScript. The supplied text includes the orchestrator types and execution code but not the pipeline implementation.
The article states that single agents hit real limits in production: long tasks exceed context windows, complex goals need different tools at different stages, and sequential reasoning is slow when subtasks are independent.
For a single agent running serially (fetch A, fetch B, fetch C, analyze), the article gives total time as T(A) + T(B) + T(C) + T(analyze).
For the multi-agent parallel version, the article gives total time as max(T(A), T(B), T(C)) + T(synthesize), described as roughly the time of the slowest agent rather than the sum.
The worked example is the task "Analyze our competitors' pricing pages and summarize the key differences"; a single agent must fetch page 1, process it, fetch page 2, process it, fetch page 3, process it, then write the analysis, and each step burns context window.
The orchestrator-based approach in the example spawns three agents in parallel, one per competitor, each fetching and processing its page independently, followed by a synthesize step.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Primary code, zero measurement
The source is a primary artifact: the type definitions, decompose(), executeParallel() and executeBatch() are quoted verbatim, so claims about the design are directly checkable and the latency formulas are stated by the author. But every performance assertion is analytic — no timings, token counts, costs, or test runs appear — and the excerpt is truncated mid-executeTask, so the Pipeline pattern and the timeout path cannot be verified at all.
No adoption signal supplied
The supplied material contains no release, package, repository, deployment, benchmark, pricing, or usage disclosure — only an author's own code listing. There is no basis to estimate whether this pattern or codebase is used anywhere, so no adoption observations were recorded.
Slightly overstated
The framing is unusually disciplined for the genre — it reduces multi-agent design to latency and context budgets rather than promising emergent capability — so the gap is small. It is positive rather than zero because the headline benefit ('roughly the time of the slowest agent') is asserted without any measurement, ignores the added planning call and per-subagent ReAct loops, and depends entirely on the LLM emitting a genuinely wide plan; a fully chained plan reverts to serial cost plus overhead.
No disclosed interests
The supplied text discloses no sponsorship, employer, vendor affiliation, product being sold, or funding relationship, and no model or platform provider is named (callLLM and ReActAgent are the author's own abstractions). Publishing-platform incentives cannot be characterized from this material without inference, so no score is issued.
Moderate on design, low on impact
Confidence is fair for what the code says — the excerpts are verbatim and internally consistent — but weak beyond that: one publisher, one article, no independent replication, no measurements, and a body that stops mid-function. Derived conclusions about wave counts, speedup bounds, and the unreachable 'skipped' status follow from the shown code but could be contradicted by the unseen remainder.
build
Splitting one agent into five is a purchase, not a promotion1 distinct publisher
build
Allow-list the closed set, block-list the open one: 193 thin geo pages, one gate1 distinct publisher
build
A GAN beauty filter is a device budget allocation, not a feature toggle1 distinct publisher
build
Your inference bill is an architecture defect: declare the task before you call the model1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 15, 2026