Runfusion/Fusion: a multi-agent software factory you run from a browser board

The problem Fusion targets: agents without a paper trail

Running a coding agent in a terminal produces a conversation. Running twenty of them produces twenty conversations, and none of them is attached to the branch, the acceptance criteria or the reviewer. Fusion's answer is to make the task the unit of work rather than the chat session. The README describes the project as "a software factory, run by a multi-agent orchestrator", and the flow diagram it prints is the whole pitch: a person describes a task in plain language, a planning agent reads the project and writes a PROMPT.md containing steps, file scope and acceptance criteria, and then the task moves through plan, review, execute and review again inside an isolated git worktree.

The audience is narrow and identifiable. It is a developer or small team already paying for one or more model providers and already convinced that agent-written code is worth reviewing. Fusion does not try to make agents trustworthy; it assumes you will want to look. Every task shows its plan, its reviews, its diffs and its file changes, and the README states that merge and pull request actions plus destructive actions always require explicit human confirmation. That is a design position, not a feature list: the orchestrator is allowed to be autonomous about writing code and is not allowed to be autonomous about landing it.

The project is TypeScript, MIT licensed, published to npm as @runfusion/fusion, and the repository's last push was on 2026-08-27. It is not archived. The most recent releases listed are v0.77.0-beta.9, v0.77.0-beta.10 and v0.77.0-beta.8, all published in August 2026, while the workspace package.json carries version 0.78.0-beta.4. Everything in the published line is a beta.

How the orchestrator actually moves a task

The mechanism visible in the repository is a pipeline with a persistent store behind it. A task enters the board, a planning agent produces PROMPT.md, and execution happens on a branch named fusion/{task-id} in its own worktree. That branch naming is what makes parallel tasks safe: two tasks touching the same repository do not share a working directory, so they cannot collide on files. The README calls this "concurrent, zero file conflicts", which is accurate about file conflicts and says nothing about semantic conflicts, such as two worktrees editing different files that both assume the same function signature.

Oversight is a per-task or per-workflow setting with four levels: off, observe, steer and autonomous. The README describes it as governing how closely a planner overseer watches and intervenes. This is the most interesting knob in the product, because it is the difference between an agent that reports and an agent that redirects. The documentation points to the Settings Reference and the Dashboard Guide for the details, and the README does not spell out what each level does in practice, so treat the four names as labels to verify in the docs rather than as a described behaviour.

Storage is embedded PostgreSQL by default, described as zero-config for local runtime metadata. Legacy SQLite files are one-time migration inputs only. For multi-project and multi-node setups the README directs you to a shared external database, and there is a multi-project document in the docs directory. Worktree handling has an abstraction layer with optional delegation to worktrunk through the worktrunk.enabled setting. The repository layout backs this up: packages/ contains cli, cli-alias, core, dashboard, desktop, droid-cli, engine, i18n, mobile, pi-claude-cli, pi-llama-cpp and plugin-sdk, plus a plugins/examples directory with auto-label, ci-status, notification and settings-demo plugins. That is a plugin surface and a workspace, not a single script.

Installing Fusion and creating a first task

The README leads with a zero-install path, which is the fastest way to see whether the dashboard is something you want in your workflow. Running the package directly launches the dashboard; subcommands forward through the same entry point.

npx runfusion.ai

The README gives this as the quick start and notes that subcommands forward, for example `npx runfusion.ai task create "fix X"` and `npx runfusion.ai --help`. The verbose equivalent is `npx @runfusion/fusion dashboard`. On first launch the dashboard opens an onboarding wizard with three steps: AI Setup, an optional GitHub connection for issue import and pull request management, and First Task. The wizard is dismissible, and the README states you can reopen it later from Settings, Authentication, Reopen onboarding guide.

If you would rather have a binary on the machine, there are three documented routes. The one-line installer works on macOS and Linux and auto-picks Homebrew, falling back to npm.

curl -fsSL https://runfusion.ai/install.sh | sh
fusion dashboard

Homebrew is the second route, and the README warns about a specific failure: if you already ran `brew tap runfusion/fusion` and the short-name install fails with "untrusted tap", run `brew trust --formula runfusion/fusion/fusion` and then install. The npm global route gives you both the `fn` and `fusion` command names.

npm install -g @runfusion/fusion
fn dashboard

For development from a clone, the README uses pnpm. The repository's package.json pins packageManager to [email protected], and the Dockerfile activates the same version with corepack, so the pin is real rather than aspirational.

pnpm dev dashboard

After the dashboard starts, the terminal prints an Open URL containing a bearer token of the form http://localhost:4040/?token=fn_... . The browser captures that token into localStorage on first visit and reuses it. On the server side, Fusion persists the dashboard and daemon token in ~/.fusion/settings.json on first authenticated run. You can override it with --token, the FUSION_DASHBOARD_TOKEN or FUSION_DAEMON_TOKEN environment variables, or turn authentication off entirely with --no-auth. The README points to the CLI reference under fn dashboard, Authentication for the full precedence order and for reset and revocation. That file is the one to read before exposing the daemon beyond localhost.

Where Fusion is the wrong tool

The published line is all beta. v0.77.0-beta.9, v0.77.0-beta.10 and v0.77.0-beta.8 are the recent releases, and the workspace manifest sits at 0.78.0-beta.4. If your team requires a release you can pin for a year and upgrade on a schedule, this is not that project yet, and the CHANGELOG plus the .changeset directory tell you the maintainers are still moving the surface between releases.

Second, the storage choice has a floor. Embedded PostgreSQL is described as zero-config for a single local runtime, but the README explicitly directs multi-project and multi-node setups to a shared external database. A team that wants three laptops and a build box coordinating on one board is signing up to run PostgreSQL, back it up, and keep it available. That is a normal cost, but it is not the cost the quick start implies.

Third, the approval gate cuts both ways. Merge and pull request actions always require explicit human confirmation. That is the correct default for code, and it means Fusion cannot be left unattended overnight to land work. You get throughput on planning, writing and reviewing, and you stay in the loop for delivery. A team hoping for a fully hands-off pipeline is buying the wrong shape of tool.

Finally, the README does not document rollback of a completed task, and it does not describe what happens to a worktree when a task is abandoned mid-execution. Those are the two questions a new operator asks first, and the answers are not in the front door documentation.

Fusion against a plain agent CLI

The honest alternative is the thing most readers already use: a coding agent run directly in a terminal, or a thin wrapper script that starts it in a git worktree and opens a pull request. The difference is not model quality. It is where state lives.

A terminal agent keeps state in a session and in the filesystem. Fusion keeps state in PostgreSQL and a dashboard, which is why it can show a board of tasks, attach a plan and reviews to each one, and let you jump into an active task to nudge direction, tighten constraints, pause, or re-prompt. The cost is that you now operate a daemon, a database and a token. The benefit is that a task survives your terminal closing and someone else can look at it.

A second alternative is a general CI system with agent steps bolted on. That gives you scheduling, secrets and logs, which Fusion also has in its own way, but CI is built around a commit that already exists. Fusion is built around a task that does not exist yet, which is why the planning step and the PROMPT.md artifact are central rather than incidental. If your work is already decomposed into issues and branches, CI plus an agent CLI may be less machinery for the same result. If your work arrives as sentences, Fusion's planning stage is doing something your CI will not.

Maintenance, upgrade cost and the MIT licence

The repository is not archived and the last push was on 2026-08-27, with three beta releases in the days around it, so the project is moving. Moving also means upgrade friction. The changeset directory and the CHANGELOG are the places to look before bumping, and the workspace manifest version running ahead of the published beta tags tells you the repository is not always in the state you installed.

The Dockerfile is worth reading as a statement of build cost. It is a multi-stage build on node:22-slim, installs git, build-essential and python3, activates [email protected] through corepack, and copies each workspace manifest individually before a frozen install, with a comment explaining that every selected workspace manifest must be copied first or pnpm omits its dependencies. That is a real constraint if you plan to containerise: a partial copy of the workspace will fail the install, not silently degrade.

The licence is MIT, declared in both the repository LICENSE file and the workspace package.json. MIT permits commercial use and modification and requires that the copyright notice and permission notice be preserved in copies or substantial portions. It provides no patent grant and no warranty. That is a summary of the licence text, not legal advice, and if you are redistributing Fusion inside a product you should have counsel read the LICENSE file rather than this paragraph.

Editorial conclusion

Adopt Fusion if you already run coding agents ad hoc and want the plan, the diff and the review attached to a task board instead of a terminal scrollback, and if you are comfortable running a dashboard that persists a bearer token in ~/.fusion/settings.json. Do not adopt it if you need a stable, non-beta release line, or if you cannot give the daemon a PostgreSQL instance once you move past a single machine. Before committing, verify two things yourself: that `npx runfusion.ai --help` lists the subcommands your workflow needs, and that the onboarding wizard's provider list actually contains the model endpoint you intend to use.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes