The conductor is the bottleneck: local agent stacks fail at orchestration, not at the workers

A build log published on dev.to reports that its local multi-agent setup broke at the coordinator rather than at the workers: Gemma 4 26B, described as the best of the local models in the worker seat, handled one or two sequential hand-offs and then lost the plan, dropping a step, summarising prematurely, or narrating the work instead of delegating it ^[1][2]. That relocates the ceiling on self-hosted agent stacks away from raw model quality and onto two duller constraints, role-casting and how much RAM the machine has ^[3][15].

The author's diagnosis is that this is not weakness. Gemma sustains deep single-session work and will iterate on one artifact for a long time without drifting ^[4]. What it cannot hold is the coordination loop: tracking several delegations, remembering which are outstanding, and assembling the results into a whole ^[5]. That is breadth of attention across threads rather than depth on one, and it is not what a model built for on-device, single-purpose work was designed to do ^[6]. The workers were cast correctly; only the conductor was miscast ^[7].

Two of the replacement candidates failed instructively. The first, llama3-groq-tool-use:8b, is a tool-calling specialist scoring about 89% on the Berkeley Function-Calling Leaderboard ^[8]. Given a real task it staged a collaboration instead of running one, emitting an invented session identifier, a call to a tool that exists nowhere in the system, a fabricated teammate with a hobbies bio, and a final "task complete" for work that never ran ^[9]. The author's reading is that a high tool-use score certifies one well-formed function call in isolation and says little about whether the model will track a multi-step task without inventing its own progress ^[10].

The second failure was arithmetic. gpt-oss:120b, roughly 77 GB, genuinely reasoned about the plan, sequenced its delegations and did not fabricate, though the summary table also records it stumbling on the agentic loop ^[11][12]. It ran mostly on CPU and system RAM, spilling far past the machine's 16 GB of VRAM, at around 9 tokens per second, which the author calls tolerable ^[13]. What was not tolerable: the machine has about 80 GB of RAM, the coordinator claimed about 77 GB of it, and the Gemma workers needed roughly 20 GB more ^[14][15]. A 97 GB working set on an 80 GB box is short by about 17 GB, so nothing can be co-resident ^[1]. Every hand-off became an eviction cycle, on the order of 100 GB of weights moved in and out for a single delegation ^[16]. A single "introduce yourself" call timed out at 121 seconds on the first attempt and completed in 291 seconds on the second ^[17]. Nearly five minutes to say hello, and none of it spent thinking ^[18].

The fallback is the shape of the answer: gpt-oss:20b at about 14 GB, small enough to sit alongside the workers, noted here and taken up in a later entry ^[19]. With the workers' 20 GB that is a 34 GB resident stack on an 80 GB machine, leaving around 46 GB of headroom ^[2]. qwen3:30b, a mixture-of-experts model in Gemma's speed class, was set aside once a clearer contender appeared ^[20].

Worth watching: whether the 20B coordinator holds a plan across more than the two hand-offs Gemma managed ^[2][19], and whether anyone reporting local agent results states their co-resident memory budget rather than a leaderboard number ^[10][1].