Fanout: orchestrate parallel agents
Updated June 7, 2026
Fanout turns one Claude session into a manager for a whole team of agents. Give it a list of tasks and it figures out which project each one belongs to, opens a worker (a Claude running in its own shard) for each, watches over them (handling their approvals and answering their questions), and folds their finished work back in when they’re done. Instead of babysitting five agents in five tabs, you talk to one manager that runs the other five.
Guild feature. Fanout spawns, merges, and approves on your behalf, so it relies on the control commands of the
crystlCLI, which require a Guild membership.
Using it
/fanout is a slash command. crystl installs it automatically (to ~/.claude/commands/fanout.md) so it’s available in any Claude Code session, no setup. Type it with a freeform task list:
/fanout fix the login bug in webapp; add tests to the api; update the changelog in docs
The manager reads your list and runs the loop below on its own. You only hear from it when it needs you: a worker asked a question it can’t answer, or something risky needs your approval.
What it does
- Resolve each task to a project. It matches each task to an open gem by name (fuzzy is fine, so “webapp” finds “my-webapp”); if none is open it scans your projects directory and opens the best match; if it’s ambiguous it asks you.
- Spawn a worker per task. One shard per task, briefed with the task plus a protocol that tells the worker to report back over the quest channel.
- Attend the workers. It reads each worker’s reports (done / blocked / a question), approves their safe operations, answers their questions from your intent, and escalates to you anything it’s unsure about or anything risky.
- Merge finished work. When an isolated worker reports done, the manager merges its branch back into the project’s main branch. Conflicts are left for you to resolve.
- Report. When everyone’s finished it gives you a per-worker summary: what got done, what merged, what was blocked, and anything left for you.
Isolation: workers never clobber each other
Two or more tasks targeting the same project each run in their own isolated git worktree (a separate working copy on its own branch) so concurrent workers can’t step on one another’s edits. crystl merges each one back cleanly when it finishes (a clean auto-merge means they really didn’t collide; a conflict means they did, and the manager surfaces it instead of shipping a broken file). A lone worker in a project just runs in place. You can override this in plain language: “all isolated” or “all shared.”
Non-git projects can’t be isolated, so the manager won’t run multiple workers concurrently in one. It’ll suggest
git initor run them one at a time.
Approval and escalation
By default workers run in smart approval mode: crystl auto-approves safe, read-only operations, and anything destructive or risky comes to the manager, which escalates it to you. You can change the posture per run in plain language:
- “full auto”: workers run with everything auto-approved (good for trusted, low-risk task lists).
- “ask before anything destructive” / “check everything”: the manager escalates every approval to you.
- “report only, don’t merge”: finished branches are reported as ready instead of being merged.
When a worker asks a question the manager can’t confidently answer from your task description, it escalates it to you and relays your answer back, so you stay in the loop on the decisions that matter without watching every step.
A worker can also stall on the agent’s own in-terminal approval prompt (its “Do you want to proceed?” menu), which is separate from crystl’s approval flow. crystl flags these in crystl shards and crystl status as ⏸ awaiting input, so the manager spots a silently parked worker and clears it instead of mistaking it for one that is still working. A quiet worker is not necessarily finished, so the manager checks for this before treating a task as done.
How it’s built
Fanout is a prompt, not a separate app. The /fanout command drives the regular crystl CLI. The worker shards talk back through crystl’s quest message channel (quest_msg), the manager handles their approvals with crystl pending / crystl approve, and it integrates finished branches with crystl merge. Everything it does is something you could do by hand from the command line.