| name | fanout |
| description | Fan one task out to multiple independent lionagi workers through `fanout.submit`, optionally synthesizing their answers. Use when several parallel perspectives can work without dependency handoffs.
|
| allowed-tools | ["Bash","Read","Write","Glob","Grep"] |
Running a Fanout
Use fanout.submit when every worker can receive the same task independently. Use flow when
one worker needs another's output or the run should discover reactive follow-up work.
Required call sequence
Ask for the catalog first, in its own call, and confirm fanout.submit is available:
mcp__plugin_orchestrate_lion__request(help=true)
Then fetch the verb's full current schema and fingerprint:
mcp__plugin_orchestrate_lion__request(help="fanout.submit")
Do not combine help and ops. Copy the returned fingerprint beside args, never inside it.
Worked example
Run four independent analyses and synthesize them into one recommendation:
mcp__plugin_orchestrate_lion__request(ops=[
{"op": "fanout.submit",
"args": {
"query": ["claude"],
"prompt": "Identify the main risks in migrating a Python service from threads to asyncio.",
"num_workers": 4,
"with_synthesis": true,
"synthesis_prompt": "Merge the analyses into a prioritized migration checklist."
},
"schema_fingerprint": "<fingerprint from help=\"fanout.submit\">"}
])
The response returns a run_id immediately while the run continues in the background. It is
not the synthesized answer. Observe and retrieve it with separate calls:
mcp__plugin_orchestrate_lion__request(ops=[
{"op": "job.status", "args": {"run_id": "<run_id>"}}
])
mcp__plugin_orchestrate_lion__request(ops=[
{"op": "job.output", "args": {"run_id": "<run_id>"}}
])
job.list finds recent runs, and job.kill stops one by run_id.
Capacity and boundaries
num_workers caps the initial independent assignments; the planner may produce fewer.
fanout.submit is a fixed fanout. Its current schema has no reactive, max_ops, or
dry_run argument, so do not pass those names.
- For reactive discovery, use
flow.submit. Its spawn capacity is
max_ops - initial assignment count when max_ops is nonzero. A plan that fills
max_ops has no capacity left for follow-ups; reserve headroom and verify the initial plan
with dry_run: true.
- Ops in one request run in order. A failed op returns
ok=false without stopping its
siblings, so inspect every op result.
Checkout-local alternative
Inside a lionagi checkout with li on PATH:
li o fanout claude "Identify the main risks in migrating a Python service from threads to asyncio." \
-n 4 --with-synthesis --synthesis-prompt "Produce a prioritized migration checklist."