Build1 publisher3 min readPublished
A single supervisor's context saturates after about five worker interactions
An engineer writing on dev.to spent two weeks on prompts and a larger model before concluding that his ten-step agent workflow broke at the fourth handoff because one supervisor was holding every worker's output.
The Engineer · Build desk

What happened
- A ten-step content workflow with seven specialist agents and one routing supervisor worked in demos and began dropping tasks around the fourth or fifth handoff once it ran in production.
- By step 7 the supervisor was re-routing work it had already assigned and producing syntheses that contradicted decisions it made twenty minutes earlier.
- Two weeks of prompt tuning, a larger supervisor model and explicit instructions about not repeating work left the behaviour unchanged.
- The author attributes the failure to context accumulation: the supervisor holds every worker interaction, and after roughly five its context saturates and performance degrades.
- LangGraph's create_supervisor, CrewAI's Process.hierarchical and AutoGen's group chat all implement a version of the same central-supervisor pattern.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A seven-specialist chain already sits at the ceiling the post's cited literature gives for centralized orchestration, so the eighth agent has to go under a sub-orchestrator or not be added.
- decision A team watching handoffs drop chooses between tuning a step limit and reshaping the call graph into layers; the first is one more hyperparameter, the second is a rewrite of the orchestration code.
- exposure When decomposition goes wrong, the specialist still completes the wrong work and a human sees the mistake only at final synthesis, well past the point where it was cheap to correct.
- capability Isolating a cluster behind its own sub-orchestrator lets a team add a specialist by editing one inner graph, leaving the top-level routing code alone.
Set the five-interaction figure against the workflow that produced it. Seven specialists mean at least seven supervisor-worker exchanges [2]. If the supervisor's context saturates at about five, the last two routing decisions are made on a context the post describes as already degraded [2]. Seven specialists is also the top of the 3 to 7 range the post cites from 2026 literature on centralized orchestration [8][1]. Inside that band, the demos passed [3].
The degradation shows up first as repeated worker outputs and lost earlier decisions, then as inconsistent routing [10]. The post names three failure modes that compound at that point. A supervisor with a hallucinated decomposition delegates to the wrong specialist, and because the specialist works on what it was handed, the error only surfaces at final synthesis, one level removed from where a human could have caught it [12]. Meaning drifts on the way back up: a specialist returns "unable to verify claim X" and the supervisor summarizes it as "claim X not confirmed" [13]. Two specialists disagree, the supervisor asks them to reconcile, they re-delegate down, workers re-run and return slightly different answers, and the loop closes; CrewAI's `Process.hierarchical` guards against that with step limits, which the post notes becomes another hyperparameter to tune [14].
Alex Aslam, the author, credits a senior architect he does not name with the reframe. "Your supervisor isn't a manager. It's a router with amnesia. Stop asking it to remember the org chart and start encoding the org chart into the graph," the architect said [16]. The literature Aslam read told him goal drift cannot be solved by periodically telling the model to "stay focused" [15].
Roughly five is a number from someone else's workload [9]. If saturation is driven by accumulated worker returns and redundant tool schemas, the interaction count where it hits depends on how large those returns are, so a set of specialists that each answer in a line will get further than one that returns documents [4]. Aslam reports the same sequence across three different teams [11]. The post does not publish token counts, window sizes, or a measured before-and-after for the nested version.
The remedy is layers. Sub-orchestrators manage clusters of specialists and a top-level orchestrator coordinates the sub-orchestrators [17]. The top level issues business-level steps such as performing market analysis then checking compliance, without knowing that market analysis internally runs three specialist agents in parallel [18]. That isolation only holds while what a sub-orchestrator hands upward is smaller than the raw worker output it replaces, because the top-level orchestrator accumulates context the same way [5]. In LangGraph it is nested `create_supervisor` calls, the inner supervisor carrying its own graph [20].
What to watch
- Token counts or window occupancy figures for a saturating supervisor would turn "roughly five interactions" into a budget a team can check against its own tool schemas.
- Whether LangGraph, CrewAI or AutoGen add context scoping or state pruning per worker inside the orchestration APIs themselves.
- Whether the three teams the post cites publish their own accounts, which would move this past a single practitioner's report.