Blog
One line in, verified work out.
A mission in Loom Conductor starts as a single sentence and ends as reviewed commits in git. This post walks the full path between those two points, stage by stage.
The brief
Everything begins with a goal in plain language: add dark mode, fix the failing CI suite, migrate the API client. You do not write tickets or assign work. The brief is the entire input, and your first one is a one-minute exercise covered in your first goal.
The plan becomes a DAG
The Conductor, a bring-your-own-key reasoning model from any of 12+ providers or a local one, breaks the goal into concrete tasks and arranges them as a directed acyclic graph. The DAG is the honest shape of the work: which tasks are independent and can run at once, and which must wait for another to land first. Planning is where parallelism is won or lost, so it happens before any session touches the code.
Dispatch
Tasks whose dependencies are satisfied get dispatched across the fleet, six real Claude Code CLI sessions running on your existing Claude login, no API key needed. Independent tasks ship simultaneously instead of queueing behind each other. As tasks complete, their dependents unlock and dispatch in turn.
Activity strips
While the fleet works, live activity strips show what each terminal is doing right now, and the mission DAG shows how far the whole goal has progressed. You get both altitudes at a glance: the mission and the moment. And because every slot is a real terminal, you can open any of them and watch the raw session whenever you want.
Steering
The Conductor watches every terminal for the whole run. It answers permission prompts, with auto-accept pressing only the safe affirmative, and it recovers the failures that kill unattended runs: stalled sessions get nudged, exited CLIs get relaunched, rate limits trigger rotation across pooled accounts. The mechanics get a full post in The watchdog that never sleeps.
Verification
A session announcing it is finished does not finish the task. Work is re-checked before it counts as done, so a premature "done" gets caught and sent back instead of silently poisoning the tasks that depend on it. The reasoning behind that gate is in verification.
Review in git
The mission ends where your normal workflow begins. Everything the fleet produced is ordinary commits, visible in Loom's source control panel with a full git graph, diffs you can walk hunk by hunk in the editor, and an auto-detected web preview if the work runs a dev server. Nothing is hidden in a proprietary format. The last reviewer is still you, with better evidence than usual.
The shape of it
Three properties that hold the pipeline together.
Plan before code
The DAG is drawn before any session writes a line, so parallelism comes from the structure of the work, not from luck.
Supervised, always
Every terminal is watched for the entire run. Prompts get answered, stalls get recovered, and nothing waits on you.
Git is the output
The deliverable is commits in your repo. Review happens with the tools you already trust, inside Loom or out.
Hand it the work.
Walk away.
macOS, Linux, and Windows. Around 13 MB. Free and open source.