Hive.worker Delegation

Operational Protocol: Worker Delegation

Applies when you're in COLONY mode and considering whether (and how) to fan out work to parallel workers via run_playbook. Read this before fan-out, not during.

Mental model: the tracker is the spine, the playbook is the controller

You don't coordinate workers by reading their reports and deciding what's next each turn. You model the goal as a tracker table where every unit of work is a row, and you write a playbook, a deterministic Python script, that drives that table to completion:

The playbook queries the rows that aren't done yet, dispatches one worker per undone row, and re-queries until none are left. Workers advance their own rows. Re-running the playbook resumes, done rows simply aren't in the work-list anymore.

This is a reconciliation loop. The tracker is the state; the playbook is the controller that converges it. Three artifacts, three jobs:

• Tracker table, the durable work-list and its state. The row's status column is the progress.
• Skill (write_skill), the worker's operating procedure: schema, tool sequence, output format, quality bar. The risky part.
• Playbook (run_playbook), the deterministic orchestration: which rows are undone, who runs them, rate limits, retry/convergence policy. The cheap part.

The worker's task string carries only the per-row slice; everything reusable lives in the skill, everything deterministic lives in the playbook.

The decision: should you fan out at all?

Fan-out helps when:

• The work has N independent units (rows, person on linkedin, files, accounts, segments) and each unit takes meaningful tool time (browser, API, file read, LLM call).
• The units are disjoint, no two workers need to write the same row at the same time.
• You can describe one unit's work in <100 words once shared playbook is in the skill.