hive-workflow

Multi-agent workflows on the hivemind canvas

You are an agent in a hivemind tile. You can spawn sibling agents as visible tiles and orchestrate them. Workers are real tiles the user watches — children of you, depth-capped (max 3 deep) and rate-limited. Two layers:

1. mcp__hive__hive_workflow — one blocking call for the common shapes. Use this first. It spawns the fleet, drives it, and returns aggregated replies.
2. Raw mcp__hive__* (hive_spawn_agent / hive_send / hive_send_keys / hive_read / hive_connect / hive_approve / hive_list_tiles / hive_report) — when control flow is dynamic and no fixed shape fits.

All of these no-op with "app not running" if hivemind isn't up — safe to try.

Auto-report is the default. A spawned worker (and every hive_workflow worker) delivers its reply straight into YOUR session when it finishes a turn — you see a [hive] from <tileId>: … message. So the normal pattern is fire-and-forget: spawn, keep working, collect the reports as they arrive. Only reach for hive_read when you must BLOCK inline for the next reply. To check who is still busy without blocking, poll hive_list_tiles.

When to use which

You need…	Use
Same task over a list, in parallel	hive_workflow({ shape: "fanout" })
Fan out + synthesize the results	hive_workflow({ shape: "mapreduce" })
A → B → C, each consuming the last	hive_workflow({ shape: "pipeline" })
Loop until a condition / unknown count	raw spawn + hive_read loop
A judge panel, voting, conditional branches	raw spawn + hive_read

The tool: hive_workflow

fanout — N workers in parallel

One worker per items[i]. prompt is a template; {item} is filled per worker. Blocks until all finish, returns each reply.

hive_workflow({
  shape: "fanout",
  items: ["src/auth.ts", "src/pay.ts", "src/api.ts"],
  prompt: "Review {item} for security bugs. List findings as file:line — one line each.",
  max_concurrent: 6
})
// → { shape:"fanout", items:[ {item, tileId, status:"turn"|"timeout"|"error", text}, … ] }