One prompt goes in. A few minutes later there's a team of AI agents working in parallel on your project — each on its own branch, each fenced into its own set of files, each one's work reviewed by three AI reviewers before it merges. This post walks through how that looks in the Factory Nexus UI, and what the platform is doing underneath each thing you see on screen.
The Agent Panel
Open any project and the right side of the screen is the Agent Panel. It has three modes:
- Task — one agent, one job. You describe the work, pick a role if you want, and the agent runs it as a single swarm task.
- Orchestrate — the swarm mode. You describe a feature at whatever level you'd give a tech lead, and an orchestrator decomposes it into parallel tasks before any code gets written.
- Ask — a lightweight Q&A chat over the project. No branches, no reviews; if the conversation turns into real work, you can escalate it into a task.
Even single tasks go through the swarm machinery — worktree isolation, the review pipeline, retries. There's no "quick and unreviewed" path, on purpose.
What Orchestrate actually does
When you submit an orchestration, the orchestrator reads the project first: the directory tree, recent git history, dependencies. Then it breaks your request into worker tasks with dependency ordering, and — this part matters — each task declares the files it plans to touch.
We call those file lanes. Every task owns its lane, and every other task's files are explicitly fenced off in its prompt. This is the answer to the first question anyone asks about parallel agents: how do you keep five of them from stepping on each other's changes? Branch isolation handles the git side — each task runs in its own git worktree on its own branch — and file lanes handle the semantic side, so two agents don't both decide the same handler file is theirs.
Lanes aren't rigid. When an agent discovers mid-run that it needs a file outside its lane, it doesn't grab it — it writes a file request, finishes the rest of its work, and exits. The coordinator then grants the file if it's unowned or its owner has finished, and restarts the agent (without spending the retry budget). If another running task owns the file, the requester waits in the queue until that owner is done.
In the UI, all of this shows up as an orchestration card — status, progress bar, task counts — with a task card per worker underneath it. Expand a task card and you get its branch, a live activity feed streaming the agent's output over WebSocket, and its review results.
Three reviewers, no exceptions
When an agent finishes, its diff goes to three parallel AI reviews: architecture, security, and style. All three must approve before the task's branch merges. On each task card this renders as the review bar — three colored verdict dots you can expand to read the actual findings.
Rejections trigger a retry with the review feedback appended to the agent's prompt, in the same worktree, so it builds on its previous work instead of starting over. Two details here took us several iterations to get right:
- Focused re-review. On a retry, only the review types that rejected run again — and each is scoped to verifying its own previous findings were addressed. A reviewer that approved doesn't get a second chance to invent new objections. Before this, we watched tasks fail on round three for stylistic nitpicks that no reviewer mentioned on rounds one and two.
- Stale-loop detection. If reviews reject with the same issues repeatedly, the task fails early instead of burning its whole retry budget against the same wall. A stuck task fails in about three review rounds, and the UI tells you why.
When a task does fail permanently, the task card gives you two distinct recovery options: Reset Retries (extend the budget and resume in the same worktree, keeping everything the agent learned) or Redo (fresh task, fresh worktree, original prompt). Failed orchestrations get a Retry button that re-runs failed tasks in place.
The merge is not the finish line
Approved tasks merge into a factory branch — never directly into main. And when an orchestration merges two or more tasks, one final agent spawns before anything is called done: the integration verifier. Its worktree forks from the merged result, and its job is to run the full test suite and lints on the combined work and fix cross-task breakage — the class of bug where each task is individually correct but one task's behavior change breaks a test in another task's lane.
Only if the verifier passes is the orchestration marked completed. A green orchestration on a GitHub-connected project then shows a banner in the Agent Panel: Create factory → main PR. Nothing is pushed or opened silently — you click, the PR opens, and you review the combined diff on the project's Review page (per-task file changes with inline diffs) or in GitHub like any other PR.
That's the whole contract of the UI: agents propose, reviewers gate, a verifier checks the combination, and a human merges.
Capacity, queues, and plans
Parallelism is capped by plan — 1 concurrent agent on Free, 5 on Pro, 20 on Team. But the orchestrator doesn't shrink your feature to fit the cap: tasks beyond it are created in a queued state and spawn automatically, oldest first, as running tasks finish. You can hand a Free-tier project a six-task orchestration and it executes serially; the same request on Pro fans out five wide.
Watching it happen
Everything above streams into the UI live over WebSocket — task lifecycle events, agent output, review verdicts, orchestration progress. There's no refresh button to mash. For the aggregate view, the Agents page has a Metrics tab with per-project success rates and active tasks across everything you're running.
Try it
The fastest way to understand a swarm is to watch one. Describe a feature on the homepage — no signup required — and watch the decomposition, the parallel task cards, and the review dots turn green. If you're weighing a larger project first, the Idea Estimator is free too.