Build1 publisher3 min readPublished
Multi-agent orchestration is a latency and context budget, not an architecture trend
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
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- 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.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
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.