DEV Community: Mahad Ansar

What I Changed After My Multi-Agent Coding Orchestrator Kept Choosing Zero Workers

Mahad Ansar — Sat, 22 Aug 2026 15:13:29 +0000

Last week, I wrote about a result I was not expecting.

I had built a multi-agent coding orchestrator, deliberately created workloads that should have favored parallelism, and then watched the supervisor choose zero workers in all six free-choice scale runs.

When I forced delegation, the workers still did not beat the supervisor working alone on the workloads I measured.

At the time, my main takeaway was:

The optimal number of workers can be zero.

I still believe that.

But after continuing to build and actually use the system, I realized there was another problem hiding behind the same symptom.

Sometimes "zero workers" meant:

The supervisor saw the orchestration tools and decided delegation was not worth it.

Other times it meant:

The supervisor never discovered the orchestrator in the first place.

Those are completely different failures.

That distinction changed the project more than another round of benchmarking would have.

Two very different kinds of zero workers

In the benchmarks from my previous article, discovery was never in question.

The prompts explicitly told the supervisor that delegate_task and delegate_tasks existed.

So when it chose zero workers, that was a routing decision.

It had the option to delegate.

It chose not to.

And on the workloads I measured, forcing it to delegate did not produce evidence that the decision was wrong.

But normal usage is different.

I do not want to start every Codex session with:

Use sol-luna-orchestrator.
Use three workers.
Run them in parallel.
Give one High effort and two Medium.

If I have to manually design the worker topology every time, I have not really built an orchestrator.

The goal is to install the tool once, open a normal Codex session, describe the engineering task, and let the parent decide:

Task
  |
  v
Discover orchestration guidance
  |
  v
Is delegation worth it?
  |
  +--> No  -> work solo
  |
  +--> Yes -> one bounded task
  |          dependent tasks in sequence
  |          or independent tasks in parallel
  |
  v
Review evidence

In fresh sessions, that was not consistently happening.

The original discovery hint installed by the CLI effectively said:

Consider the orchestrator when delegation might help.

The problem with "consider" is that the parent first has to know there is something to consider.

If it never looks at the MCP server, it never sees the detailed routing guidance.

So this was not a delegation-policy problem.

It was a discovery problem.

Discovery has to happen before the routing decision

I changed the onboarding behavior.

sol-luna-orchestrator init now installs a small managed instruction that tells a fresh Codex session to discover the configured orchestrator first, and then use the actual guidance to choose between:

working solo
delegating one task
running dependent tasks sequentially
running independent tasks in parallel

The important part is what the hint does not say.

It does not say:

You must delegate.

Zero workers remains explicitly valid.

That order matters:

Bad:

Should I delegate?
    |
    v
Maybe I should look for a tool?


Current:

Discover the orchestration policy
    |
    v
Understand the available execution modes
    |
    v
Now decide whether delegation makes sense

I wanted discovery to be stronger without turning it into forced fan-out.

Those are two separate decisions.

Then I tried it on a real task

After releasing v0.8.0, I wanted to test this outside the benchmark harness.

So I opened a fresh Codex session in another repository.

The repository was my GitHub profile README.

It had become outdated, especially around the open-source work I had done on Sol-Luna, and I wanted the agent to research my current public work and rewrite the profile into a concise landing page.

The important part was the prompt.

I did not mention:

Sol-Luna
MCP
delegation
workers
Luna
delegate_task
delegate_tasks

I simply asked it to inspect the repository, research the relevant public work from primary sources, verify claims, update the README, check the links, and leave the changes uncommitted.

The parent discovered the orchestration guidance on its own.

Then it made a fairly reasonable split.

The broad public-source investigation was one substantial, bounded research task, so it delegated that to a Luna worker at High effort.

Fresh Codex session: the parent discovered the orchestration guidance and chose one bounded research worker without being told to delegate.

The worker was explicitly read-only.

The parent kept the actual editorial decisions, synthesis, README editing, source checking, and final review.

Later, when I asked it to refine the README it had just written, it explicitly chose zero workers.

Its reasoning was basically that the remaining change involved one short, tightly coupled file and was already understood.

So within one real workflow I got both:

Broad independent research
        |
        v
1 bounded worker


Tightly coupled final refinement
        |
        v
0 workers

That is much closer to what I wanted when I started this project.

Not "multi-agent all the time."

Adaptive execution.

I am not claiming this run proved delegation was faster or cheaper.

There was no solo control.

It was not a benchmark.

What it demonstrated was narrower: a fresh session discovered the orchestrator without being prompted toward it, used a worker where it saw a clean seam, and later declined to use one where it did not.

That is a much more useful acceptance test than simply checking whether the tool call technically works.

The next problem was context

Once workers actually start receiving useful tasks, another obvious question appears:

How much of the supervisor's context should they get?

The naive answer is "all of it."

I increasingly think that is the wrong answer.

The parent may know:

the full conversation
architectural history
rejected approaches
unrelated files
debugging attempts
user preferences
prior decisions
broader product context

A worker handling one bounded task usually does not need all of that.

But giving it too little context creates another problem: it has to rediscover information the parent already knows.

So I added structured Context Capsules.

A worker can receive selected fields such as:

relevant context
interfaces
dependencies
invariants
upstream decisions
known pitfalls

The goal is not context maximization.

It is context allocation.

Give the worker the smallest useful view of the problem.

That turned out to apply in the other direction too.

The supervisor does not need every byte back either

Delegated tasks return evidence.

Originally, successful verification could send a lot of routine command output back into the parent's context.

But once a check passed, most of that output was rarely useful.

What the parent normally needs is:

what changed
what was verified
whether verification passed
whether scope was violated
whether the worker's claims matched observed changes
any discrepancy or failure that needs attention

So v0.7.0 added Compact Evidence Packets.

Successful verification stdout/stderr can be removed from the structured result while failures remain intact.

That gave me a more general rule:

Good multi-agent systems need to optimize context in both directions.

The worker should not receive the entire supervisor history.

The supervisor should not receive every routine byte the worker produced.

The useful information is somewhere in the middle.

A worker's PASS is still just a claim

This is probably the design principle I care about most in the project now.

Suppose a worker returns:

PASS

Changed:
- src/auth.ts
- src/auth.test.ts

Tests passed.

That looks reassuring.

But it is still generated text.

So Sol-Luna treats the worker's report as a claim, not the final truth.

A worker-reported PASS is treated as evidence to inspect, not as the final conclusion.

The orchestrator can independently:

observe which files actually changed
compare observed edits with claimed edits
check declared file scope
detect integration conflicts
re-run allowlisted verification commands
report discrepancies back to the parent

And then the parent still owns the final review.

The trust chain becomes:

Worker does the task
      |
      v
Worker reports what happened
      |
      v
Orchestrator independently observes and verifies
      |
      v
Parent reviews the evidence
      |
      v
Decision

That is intentionally different from:

Worker says PASS
      |
      v
Ship it

The real-world README run even found a small flaw in this logic.

The research worker had an explicitly read-only contract.

It correctly changed zero files.

But the orchestrator still emitted a generic warning:

Worker claimed PASS but no file changes were recorded.

For an implementation task, that warning can be useful.

For an investigation that was explicitly forbidden from editing anything, zero changed files is exactly what should happen.

So that run produced a new backlog item: classify zero-change results from the task contract's intent, not from the result alone.

That is the kind of bug I wanted real usage to expose.

Parallel agents eventually turn into normal concurrency engineering

There was another lesson from building the worker path that had very little to do with language models.

Parallel workers use isolated Git worktrees.

At one point, batches would occasionally fail even though the worker itself had done nothing wrong.

The problem was git worktree add.

Multiple processes were modifying shared metadata under .git/worktrees concurrently.

The failure was rare. I reproduced it at roughly once per thousand worktree creations.

That made it annoying enough to be real and infrequent enough to hide during casual testing.

The fix was not better prompting.

It was synchronization.

Operations that mutate the shared worktree metadata are now serialized.

Worker execution remains parallel.

That experience was a useful reminder that once you build enough infrastructure around AI agents, a lot of the difficult bugs become very ordinary software-engineering bugs:

race conditions
shared state
cleanup
cancellation
process trees
conflicting writes
malformed logs
stale configuration
backwards compatibility

The model is only one part of the system.

If workers run in parallel, I also need to know what they are doing

Another problem became obvious during longer delegations.

From the normal Codex interface, a worker could be running for a while and the parent could appear to be doing nothing.

So I added:

sol-luna-orchestrator activity --watch

It shows things like:

execution mode
active and total workers
model and reasoning effort
elapsed duration
verification state
changed-file counts
failures
concurrency

Initially this sounds like a straightforward observability feature.

Then the privacy question appears:

What exactly should an activity log contain?

Earlier activity output exposed far more of the delegated task than was necessary.

The redesigned view keeps the operational signal: worker, effort, state, duration, and verification status.

A useful activity feed does not need the worker's entire objective, prompt, context, source code, or successful command output.

So the current event stream deliberately excludes those.

Task IDs are opaque rather than derived from task descriptions.

A parent can optionally provide a short activity label, but that is documented as locally revealing because it is persisted.

There is also a separate diagnostic log with more detail, and that file is explicitly treated as sensitive.

Nothing is remotely transmitted by Sol-Luna.

Both files are local.

The broader lesson for me was:

Agent observability becomes a privacy-design problem almost immediately.

"Log everything" is not a good default when prompts and source code may be involved.

I also had to correct my own architecture description

The earlier version of the project described GPT-5.6 Sol as the supervisor.

That was how I personally used it, but it was not actually an architectural requirement.

The parent is now explicitly model-agnostic.

Any compatible Codex parent with access to the MCP can supervise.

The worker side remains GPT-5.6 Luna.

That correction also forced me to clean up another argument I had been making around cost.

I had been thinking in terms of:

expensive parent
      +
cheaper workers
      =
possible savings

But that only makes sense when the parent model the user selected is actually priced above the worker under the current pricing schedule.

It is not a universal property of the architecture.

Raw token counts are not cost either.

A system can use more raw tokens but fewer credits, or the reverse, depending on the models involved.

So the project now makes the narrower claim:

Delegation has a coordination cost. Worker economics depend on the models you actually selected. No realized cost saving has been measured.

I would rather weaken a claim than keep one the implementation or data no longer supports.

What the project looks like now

The basic philosophy is still simple:

Not every task should be delegated.

But the machinery around that idea has grown quite a bit.

The parent can now choose:

0 workers       -> solo
1 worker        -> one bounded task
N sequential    -> dependent/shared work
N parallel      -> independent/disjoint work

Each worker gets its own reasoning effort.

Parallel workers use isolated worktrees.

Tasks have declared scopes.

Verification is independently re-run.

Claimed and observed changes are compared.

Workers receive structured context instead of a full conversation dump.

Successful evidence can be compacted before returning to the parent.

Fresh sessions can discover the orchestration policy without the user naming the tool.

Single and batch delegations are observable through the CLI.

And importantly, the parent still owns the final judgment.

v0.8.0 is now live on npm.

At the time I am writing this, npm is showing 659 downloads in the last seven days.

I am deliberately calling those downloads, not users. Package downloads can include CI, reinstalls, automated activity, and other things that do not map one-to-one to humans.

Still, for something I originally built because I wanted it for my own Codex workflow, seeing other people pull the package has been pretty cool.

What I want to build next

I do not think the next step is "add more workers."

The roadmap currently goes in a different direction.

Worker continuation

If a worker already investigated or implemented something, the parent should be able to continue that worker's thread instead of starting from zero every time.

Bounded repair

If verification finds a narrow problem, the same worker should be able to receive the evidence and make a bounded correction.

Not an infinite autonomous loop.

A controlled one.

Reasoned retries and effort escalation

A timeout, a misunderstood requirement, an implementation failure, and an environment problem should not all trigger the same retry behavior.

The system should classify the failure before deciding what to do next.

Adaptive worker routing

Eventually I want the supervisor to choose not just effort and worker count, but among a user-authorized pool of worker capabilities.

But I deliberately put this later in the roadmap.

Routing a failed task to a more expensive model before continuation and bounded repair exist would mostly be a sophisticated way to spend more money on the same failure.

The recovery loop needs to become smarter first.

The thing I changed my mind about

When I started building Sol-Luna, the interesting problem looked like:

How do I run several coding agents at once?

I do not think that is the interesting problem anymore.

Running several agents is relatively easy.

The harder questions are:

Did the supervisor even discover the orchestration policy?
Should this task be delegated?
Where is the clean task boundary?
What context does the worker actually need?
What evidence does the parent actually need back?
Can the worker's claims be independently checked?
What happens when verification fails?
How much information should observability persist?
When is the coordination overhead simply not worth it?

The fresh-session README task was a tiny example, but I liked what happened.

One part of the work had a clean research seam.

The supervisor used a worker.

The next part was tightly coupled and already understood.

The supervisor used zero workers.

No swarm.

No fixed workflow.

No rule saying more agents must be better.

Just two different execution decisions for two different pieces of work.

That is increasingly what I think orchestration should mean.

Try it

The project is open source on GitHub:

mahadansar/sol-luna-orchestrator

Install it from npm:

npm install -g sol-luna-orchestrator
sol-luna-orchestrator init

Then open a fresh Codex session and work normally.

You should not need to choose a worker count or manually call the orchestration tools.

And if the parent decides the right worker count is zero, that may be exactly what you want.

Final thought

My first experiment taught me:

More agents are not automatically better.

The work since then taught me something slightly broader:

Delegation itself is the easy part. Making delegation worth its complexity is the real engineering problem.

I think that is the direction I want to keep pushing.

I Built a Multi-Agent Coding Orchestrator. It Kept Choosing Zero Workers.

Mahad Ansar — Sat, 15 Aug 2026 07:47:40 +0000

I expected more AI agents to make coding faster.

They didn’t.

That was not the result I was looking for, but it ended up being the most interesting result of the project.

Over the past few weeks, I have been building Sol-Luna Orchestrator, an open-source orchestration layer for OpenAI Codex.

The idea started with a simple question:

What if one strong AI could decide when it actually needed help from other AI agents?

Instead 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.

That distinction ended up mattering much more than I expected.

The basic idea

Sol-Luna has two roles.

GPT-5.6 Sol acts as the supervisor. It owns the overall task, decomposition, verification, and final review.

GPT-5.6 Luna instances act as bounded workers when Sol decides delegation is useful.

Conceptually:

Task
  |
  v
Sol Supervisor
  |
Should I delegate?
   /          \
 No            Yes
 |              |
Sol          Split into
handles       bounded tasks
the work          |
              Choose worker
                 effort
                  |
           Luna  Luna  Luna
                  |
               Results
                  |
            Sol verifies
             and reviews

There are really two separate adaptive decisions.

1. Adaptive delegation

Sol decides whether to delegate at all.

The optimal worker count is allowed to be zero.

Small tasks, tightly coupled work, or tasks where coordination looks more expensive than simply doing the work can stay entirely with Sol.

2. Adaptive worker effort

If Sol does delegate, it separately decides how much reasoning effort each Luna worker needs.

A worker can receive:

Medium
High
XHigh
Max

A mechanical change does not necessarily need the same reasoning budget as a difficult debugging problem.

So the goal was never simply to spawn more agents.

The goal was to let the strongest model decide how the work should be executed.

Making delegation safer

Once multiple coding agents start working at the same time, practical problems appear pretty quickly.

Workers 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.

Sol-Luna adds controls around those problems.

Parallel 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.

Workers also cannot recursively invoke the orchestrator and create their own worker trees.

That gave me a functioning orchestration system.

But I still had a more basic question.

When does parallelism actually become faster?

My earlier benchmarks had already shown that parallel Luna workers could beat sequential Luna delegation.

But one Sol working alone was still faster.

For small tasks, that made sense. Delegation itself has overhead.

So I assumed there must be a break-even point.

Make the task large enough. Give workers genuinely independent modules. Eventually multiple agents working at the same time should catch up and win.

That became the next experiment.

Looking for the crossover

I created progressively larger deterministic engineering fixtures.

The important part was that the parallel workloads were deliberately designed with independent streams of work.

I did not want to give parallel agents an artificially coupled task and then conclude that parallelism was bad.

The larger benchmark included:

a four-module independent workload
a six-module independent workload
a coupled control where decomposition was intentionally inappropriate

The six-module fixture contained roughly 530 lines of specification and 85 deterministic assertions.

Each module could be worked on independently, so six workers could theoretically make progress at the same time.

This was deliberately much larger than the earlier fixtures, but it still fit comfortably inside a single Sol session.

That limitation matters.

I 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.

For each fixture, I compared three modes.

Sol working alone

Delegation was disabled.

Free choice

Delegation was available, but Sol was free to decide whether to use it.

This is closest to how I actually want the orchestrator to behave.

Forced parallel delegation

Sol was required to delegate the independent work so I could measure what happened when the worker path was definitely used.

The scale benchmark completed 19 out of 19 runs successfully.

Then came the interesting part.

Sol kept choosing zero workers

Across all six free-choice runs, Sol declined to delegate.

Every time.

At first, that can sound like an orchestration system refusing to do its job.

But then I compared those decisions with the forced-delegation results.

Four independent modules

Mode	Median
Sol working alone	171.5s
Free choice, Sol chose 0 workers	120s
Forced parallel, 4 workers	250s

The free-choice runs used zero Luna workers.

Six independent modules

Mode	Median
Sol working alone	189.5s
Free choice, Sol chose 0 workers	186.5s
Forced parallel, 6 workers	394.5s

Again, Sol chose zero workers.

The interesting result was not simply that parallel workers lost.

The 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.

Going from four independent streams to six also did not move forced parallel execution closer to the solo baseline.

It moved further away.

Forced parallel was roughly 46% slower than solo at four streams and roughly 108% slower at six.

So the benchmark did not find the crossover I expected.

More agents were not free

Token usage told a similar story.

On the independent workloads, forced parallel execution used approximately:

5.1x the known tokens of solo execution at four streams
4.8x the known tokens of solo execution at six streams

There was no token crossover either.

That does not make the workers useless.

Parallel workers can still provide useful properties such as isolated workspaces, bounded tasks, separate context, independent verification, and explicit ownership of different pieces of work.

And when delegation is already required, the earlier benchmark showed that parallel workers can beat sequential delegation.

But for raw speed on the workloads I measured, forcing delegation was clearly not winning.

Where was the time going?

One possibility was that the orchestration machinery itself was expensive.

Maybe Git worktrees or integration were eating all the time.

They were not.

Measured median phases looked roughly like this:

Phase	Median
Supervisor work before batch	37.1s
Worktree setup	0.8s
Slowest worker	187.1s
Integration	0.4s
Supervisor review	32.4s

The mechanical Git orchestration was tiny.

Worktree setup plus integration was around 1.2 seconds.

Most of the fixed overhead came from useful supervisor work: decomposing the task, writing bounded worker contracts, and reviewing the results afterward.

But another effect became much more visible in the six-worker runs.

The slowest worker matters

Parallel completion time depends heavily on the worker that finishes last.

In one six-worker run, five workers finished within about 95 seconds.

One worker took 333 seconds.

The observed max-to-median worker-duration ratios in the two six-worker runs were around 3.5x and 2.7x.

So in these runs, finishing five tasks quickly did not help enough because the batch still had to wait for the final worker.

I also calculated a simple counterfactual using the measured timings.

If 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.

That counterfactual would have crossed the solo median.

But no observed run actually did.

The 176-second number is arithmetic on measured timings, not a benchmark result.

And with only two repetitions of the six-worker cell, I do not have enough data to characterize the full distribution of worker durations.

So the careful conclusion is that the slow-worker tail looks like a strong candidate for an important parallel-latency constraint.

It is not proven to be the only one.

The result changed how I think about orchestration

When I started this project, I thought a successful orchestrator would mainly be good at distributing work.

I now think that definition is incomplete.

A good orchestrator should also be good at not distributing work.

Across the workloads I measured, Sol chose zero workers in every free-choice run. Forced delegation was slower on the corresponding fixtures.

That does not prove that the free-choice policy itself caused the faster timings. These are stochastic model runs, and separate runs can behave differently.

But none of the measured workloads provided evidence that declining delegation was the wrong decision.

That leads to what is probably my favorite idea from the project so far:

The optimal number of workers can be zero.

More agents are a tool, not an objective.

Good orchestration is not about maximizing agent count.

Sometimes the strongest agent should simply do the work itself.

This does not mean one agent always wins

I want to be careful about what these results actually show.

They do not prove that one strong agent is universally better than multiple agents.

Every workload I tested still fit comfortably inside one Sol session.

A much larger production repository may behave differently.

A task running for hours may behave differently.

Work that requires several highly specialized contexts may behave differently.

And 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.

That remains an open question.

At what point does keeping everything inside one strong agent become more expensive than coordinating several workers?

I do not have that answer yet.

And 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.

The negative result is staying public

One temptation with developer-tool benchmarks is to keep changing the experiment until your tool wins.

I did not want to do that.

My original prediction was that larger independent workloads would eventually produce a latency crossover.

The benchmark falsified that prediction in the regime I tested.

So the methodology, benchmark harness, raw records, and results are staying public.

If someone wants to try the same setup on a genuinely large real-world workload, I would genuinely like to see what happens.

That is one of the benefits of making the whole thing open source.

Try it

Sol-Luna Orchestrator is open source:

https://github.com/mahadansar/sol-luna-orchestrator

Install it with:

npm install -g sol-luna-orchestrator
sol-luna-orchestrator init

The repository includes the architecture, security model, benchmark fixtures, raw results, and documentation around the delegation policy.

For now, I am deliberately holding off on major new features.

I 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.

Final thought

I started this experiment asking:

How many agents should work on a coding task?

I ended up with a question I like much more:

When should a strong agent delegate at all?

For the workloads I have measured so far, the answer was often:

It shouldn’t.

And I think knowing that is part of orchestration too.