I Actually Connected a Coordinator and Workers

✨ GPT-5.6 Sol’s Summary

A record of splitting one goal into Work Items, handing them to workers, and having a coordinator verify and integrate the results.

This was different from the old workers

I had used workers and a coordinator in an earlier data-collection project too. Back then, each worker repeated the same batch against a fixed goal, while the coordinator periodically organized the accumulated results.

This time was different. I gave the coordinator a goal in natural language. It defined the completion conditions and Work Items, then assigned each worker its own files and scope.

Each -W- worker finished and verified its assignment, then handed over a commit. The -C- coordinator reviewed those results, integrated them one by one, and checked the combined state again.

What happened when I actually ran it

The flow itself was simple.

Pass in the goal
→ Split it into Work Items
→ Execute and verify in each worker
→ Hand over commits
→ Coordinator reviews and integrates
→ Verify the combined state

The best part was that ownership became clear. If one task failed, it did not shake the others, and I could inspect every result as a commit.

The problem appeared immediately too. Once I started too many workers, reports arrived all at once. Duplicate sessions made the whole thing even harder to manage. More parallelism was not automatically better. I had to limit the split to what the coordinator could actually handle.

What I want to automate in OpenClaw

I do not want to reproduce today’s sessions, Worktrees, and Branches exactly inside the product. I want to automate the decisions behind them.

• how far to split a goal
• who owns each result
• what must be checked before a task is done
• where to restart after a failure

Launching several AIs at once was not the hard part. The hard part was combining their output without losing anything. Today I ran that process manually.