{"slug": "i-built-a-multi-agent-coding-orchestrator-it-kept-choosing-zero-workers", "title": "I Built a Multi-Agent Coding Orchestrator. It Kept Choosing Zero Workers.", "summary": "A developer built Sol-Luna Orchestrator, an open-source orchestration layer for OpenAI Codex, and found that the supervisor model often chose to do the work itself rather than delegate to multiple AI agents. The system lets the strongest model decide whether delegation is worth the coordination cost, and benchmarks showed that for small tasks, a single agent was faster than parallel workers.", "body_md": "I expected more AI agents to make coding faster.\n\nThey didn’t.\n\nThat was not the result I was looking for, but it ended up being the most interesting result of the project.\n\nOver the past few weeks, I have been building **Sol-Luna Orchestrator**, an open-source orchestration layer for OpenAI Codex.\n\nThe idea started with a simple question:\n\nWhat if one strong AI could decide when it actually needed help from other AI agents?\n\nInstead of automatically splitting every coding task across multiple workers, I wanted the supervisor to look at the work first and decide whether delegation was actually worth the coordination cost.\n\nThat distinction ended up mattering much more than I expected.\n\nSol-Luna has two roles.\n\n**GPT-5.6 Sol** acts as the supervisor. It owns the overall task, decomposition, verification, and final review.\n\n**GPT-5.6 Luna** instances act as bounded workers when Sol decides delegation is useful.\n\nConceptually:\n\n```\nTask\n  |\n  v\nSol Supervisor\n  |\nShould I delegate?\n   /          \\\n No            Yes\n |              |\nSol          Split into\nhandles       bounded tasks\nthe work          |\n              Choose worker\n                 effort\n                  |\n           Luna  Luna  Luna\n                  |\n               Results\n                  |\n            Sol verifies\n             and reviews\n```\n\nThere are really **two separate adaptive decisions**.\n\nSol decides whether to delegate at all.\n\nThe optimal worker count is allowed to be zero.\n\nSmall tasks, tightly coupled work, or tasks where coordination looks more expensive than simply doing the work can stay entirely with Sol.\n\nIf Sol does delegate, it separately decides how much reasoning effort each Luna worker needs.\n\nA worker can receive:\n\nA mechanical change does not necessarily need the same reasoning budget as a difficult debugging problem.\n\nSo the goal was never simply to spawn more agents.\n\nThe goal was to let the strongest model decide how the work should be executed.\n\nOnce multiple coding agents start working at the same time, practical problems appear pretty quickly.\n\nWorkers can edit overlapping files. A worker can move outside its declared task scope. Verification can disagree with what the worker reports. Parallel Git operations can interfere with each other.\n\nSol-Luna adds controls around those problems.\n\nParallel workers run in isolated Git worktrees. Tasks declare their intended file scope, and scope violations are checked after execution. Verification is independently rerun instead of trusting a worker’s own PASS result. Sol remains responsible for reviewing the final output.\n\nWorkers also cannot recursively invoke the orchestrator and create their own worker trees.\n\nThat gave me a functioning orchestration system.\n\nBut I still had a more basic question.\n\nMy earlier benchmarks had already shown that parallel Luna workers could beat **sequential** Luna delegation.\n\nBut one Sol working alone was still faster.\n\nFor small tasks, that made sense. Delegation itself has overhead.\n\nSo I assumed there must be a break-even point.\n\nMake the task large enough. Give workers genuinely independent modules. Eventually multiple agents working at the same time should catch up and win.\n\nThat became the next experiment.\n\nI created progressively larger deterministic engineering fixtures.\n\nThe important part was that the parallel workloads were deliberately designed with independent streams of work.\n\nI did not want to give parallel agents an artificially coupled task and then conclude that parallelism was bad.\n\nThe larger benchmark included:\n\nThe six-module fixture contained roughly **530 lines of specification and 85 deterministic assertions**.\n\nEach module could be worked on independently, so six workers could theoretically make progress at the same time.\n\nThis was deliberately much larger than the earlier fixtures, but it still fit comfortably inside a single Sol session.\n\nThat limitation matters.\n\nI was testing whether clean parallelism alone was enough to create a crossover. I was not trying to simulate a huge production repository or a task running for several hours.\n\nFor each fixture, I compared three modes.\n\nDelegation was disabled.\n\nDelegation was available, but Sol was free to decide whether to use it.\n\nThis is closest to how I actually want the orchestrator to behave.\n\nSol was required to delegate the independent work so I could measure what happened when the worker path was definitely used.\n\nThe scale benchmark completed **19 out of 19 runs successfully**.\n\nThen came the interesting part.\n\nAcross all six free-choice runs, Sol declined to delegate.\n\nEvery time.\n\nAt first, that can sound like an orchestration system refusing to do its job.\n\nBut then I compared those decisions with the forced-delegation results.\n\n| Mode | Median |\n|---|---|\n| Sol working alone | 171.5s |\n| Free choice, Sol chose 0 workers | 120s |\n| Forced parallel, 4 workers | 250s |\n\nThe free-choice runs used **zero Luna workers**.\n\n| Mode | Median |\n|---|---|\n| Sol working alone | 189.5s |\n| Free choice, Sol chose 0 workers | 186.5s |\n| Forced parallel, 6 workers | 394.5s |\n\nAgain, Sol chose **zero workers**.\n\nThe interesting result was not simply that parallel workers lost.\n\nThe supervisor had been given the option to use them, declined to do so, and none of the measured workloads gave me evidence that this was the wrong call.\n\nGoing from four independent streams to six also did not move forced parallel execution closer to the solo baseline.\n\nIt moved further away.\n\nForced parallel was roughly **46% slower** than solo at four streams and roughly **108% slower** at six.\n\nSo the benchmark did not find the crossover I expected.\n\nToken usage told a similar story.\n\nOn the independent workloads, forced parallel execution used approximately:\n\nThere was no token crossover either.\n\nThat does not make the workers useless.\n\nParallel workers can still provide useful properties such as isolated workspaces, bounded tasks, separate context, independent verification, and explicit ownership of different pieces of work.\n\nAnd when delegation is already required, the earlier benchmark showed that parallel workers can beat sequential delegation.\n\nBut for raw speed on the workloads I measured, forcing delegation was clearly not winning.\n\nOne possibility was that the orchestration machinery itself was expensive.\n\nMaybe Git worktrees or integration were eating all the time.\n\nThey were not.\n\nMeasured median phases looked roughly like this:\n\n| Phase | Median |\n|---|---|\n| Supervisor work before batch | 37.1s |\n| Worktree setup | 0.8s |\n| Slowest worker | 187.1s |\n| Integration | 0.4s |\n| Supervisor review | 32.4s |\n\nThe mechanical Git orchestration was tiny.\n\nWorktree setup plus integration was around **1.2 seconds**.\n\nMost of the fixed overhead came from useful supervisor work: decomposing the task, writing bounded worker contracts, and reviewing the results afterward.\n\nBut another effect became much more visible in the six-worker runs.\n\nParallel completion time depends heavily on the worker that finishes last.\n\nIn one six-worker run, five workers finished within about 95 seconds.\n\nOne worker took **333 seconds**.\n\nThe observed max-to-median worker-duration ratios in the two six-worker runs were around **3.5x** and **2.7x**.\n\nSo in these runs, finishing five tasks quickly did not help enough because the batch still had to wait for the final worker.\n\nI also calculated a simple counterfactual using the measured timings.\n\nIf every worker in the six-stream runs had completed around that run’s median worker duration, parallel execution would have landed around **176 seconds**, compared with the 189.5-second solo median.\n\nThat counterfactual would have crossed the solo median.\n\nBut no observed run actually did.\n\nThe 176-second number is arithmetic on measured timings, not a benchmark result.\n\nAnd with only two repetitions of the six-worker cell, I do not have enough data to characterize the full distribution of worker durations.\n\nSo the careful conclusion is that the slow-worker tail looks like a strong candidate for an important parallel-latency constraint.\n\nIt is not proven to be the only one.\n\nWhen I started this project, I thought a successful orchestrator would mainly be good at distributing work.\n\nI now think that definition is incomplete.\n\nA good orchestrator should also be good at **not distributing work**.\n\nAcross the workloads I measured, Sol chose zero workers in every free-choice run. Forced delegation was slower on the corresponding fixtures.\n\nThat does not prove that the free-choice policy itself caused the faster timings. These are stochastic model runs, and separate runs can behave differently.\n\nBut none of the measured workloads provided evidence that declining delegation was the wrong decision.\n\nThat leads to what is probably my favorite idea from the project so far:\n\nThe optimal number of workers can be zero.\n\nMore agents are a tool, not an objective.\n\nGood orchestration is not about maximizing agent count.\n\nSometimes the strongest agent should simply do the work itself.\n\nI want to be careful about what these results actually show.\n\nThey do **not** prove that one strong agent is universally better than multiple agents.\n\nEvery workload I tested still fit comfortably inside one Sol session.\n\nA much larger production repository may behave differently.\n\nA task running for hours may behave differently.\n\nWork that requires several highly specialized contexts may behave differently.\n\nAnd a workload large enough to push beyond what one supervisor can comfortably keep in context may be exactly where delegation starts to become much more valuable.\n\nThat remains an open question.\n\nAt what point does keeping everything inside one strong agent become more expensive than coordinating several workers?\n\nI do not have that answer yet.\n\nAnd I think that is more interesting than simply adding eight or ten agents to another synthetic fixture until I find a benchmark where parallelism wins.\n\nOne temptation with developer-tool benchmarks is to keep changing the experiment until your tool wins.\n\nI did not want to do that.\n\nMy original prediction was that larger independent workloads would eventually produce a latency crossover.\n\nThe benchmark falsified that prediction in the regime I tested.\n\nSo the methodology, benchmark harness, raw records, and results are staying public.\n\nIf someone wants to try the same setup on a genuinely large real-world workload, I would genuinely like to see what happens.\n\nThat is one of the benefits of making the whole thing open source.\n\n**Sol-Luna Orchestrator** is open source:\n\n[https://github.com/mahadansar/sol-luna-orchestrator](https://github.com/mahadansar/sol-luna-orchestrator)\n\nInstall it with:\n\n```\nnpm install -g sol-luna-orchestrator\nsol-luna-orchestrator init\n```\n\nThe repository includes the architecture, security model, benchmark fixtures, raw results, and documentation around the delegation policy.\n\nFor now, I am deliberately holding off on major new features.\n\nI would rather see how people actually use it, what larger real-world workloads expose, and whether the assumptions behind the project continue to hold before deciding what is worth building next.\n\nI started this experiment asking:\n\n**How many agents should work on a coding task?**\n\nI ended up with a question I like much more:\n\n**When should a strong agent delegate at all?**\n\nFor the workloads I have measured so far, the answer was often:\n\n**It shouldn’t.**\n\nAnd I think knowing that is part of orchestration too.", "url": "https://wpnews.pro/news/i-built-a-multi-agent-coding-orchestrator-it-kept-choosing-zero-workers", "canonical_source": "https://dev.to/mahadansar/i-built-a-multi-agent-coding-orchestrator-it-kept-choosing-zero-workers-4bc3", "published_at": "2026-08-15 07:47:40+00:00", "updated_at": "2026-08-15 08:10:39.161468+00:00", "lang": "en", "topics": ["ai-agents", "ai-infrastructure", "developer-tools"], "entities": ["Sol-Luna Orchestrator", "OpenAI Codex", "GPT-5.6 Sol", "GPT-5.6 Luna"], "alternates": {"html": "https://wpnews.pro/news/i-built-a-multi-agent-coding-orchestrator-it-kept-choosing-zero-workers", "markdown": "https://wpnews.pro/news/i-built-a-multi-agent-coding-orchestrator-it-kept-choosing-zero-workers.md", "text": "https://wpnews.pro/news/i-built-a-multi-agent-coding-orchestrator-it-kept-choosing-zero-workers.txt", "jsonld": "https://wpnews.pro/news/i-built-a-multi-agent-coding-orchestrator-it-kept-choosing-zero-workers.jsonld"}}