hive.worker-delegation

Model the goal as a tracker table with a done-predicate column, write the worker protocol as a skill, pilot one row yourself, then author a Python playbook that calls converge over the pending rows and run it with run_playbook. Re-running the playbook resumes only unfinished rows.

Skip fan-out when there are fewer than about three units of meaningful work, since spawning workers has overhead, or when the work is exploratory and open-ended. Decompose the problem into bounded units first, then fan out only the well-defined parts.

Call list_browser_profiles to discover connected profile labels, then pass each worker its label in the task string so it runs hive-browser commands with --browser-profile. Rotate the profile per row index and set a lane per account to cap concurrency and throttle rate limits.

The most common causes are awaiting tracker_query (it is synchronous and returns a list of row dicts), passing a COUNT query as pending instead of selecting undone rows, or calling worker() in a bare loop without converge. Parallel dispatch only happens through converge's dispatch lambda.

Re-running the playbook re-dispatches any row not marked done, including rows whose worker crashed. Tracker upserts are idempotent, but external side effects like sending messages must detect prior completion themselves to avoid duplicates.

Use the shared hive-crm CLI before fan-out: import the target people, then atomically claim their person_ids so only unclaimed leads enter your tracker. After the playbook completes, import the finished records back and release the claims.