[🛠] 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.

From repetitive workers to Work Item-based 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.

More workers also meant higher integration costs

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.

That day, I also refined the Orchestrator and Acceptance baselines, shared Workflows and Skills, and the operating rules for worker and coordinator sessions.

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

OpenClaw needed a coordinator that managed result ownership, verification, and restart points more than it needed a large number of workers.