Fusion Software Factory
Turn software requests into planned, reviewed, implemented, and Git-delivered changes through multi-agent workflows.
The evidence shows read-only contents permissions in CI, disabled credential persistence in one workflow, isolated git worktrees/branches, optional plan approval, per-task merge policy, pausing, and prompt adjustment. It also documents dashboard-token storage, overrides, revocation/reset references, and an authentication opt-out. Deductions apply because the runtime least-privilege model for filesystem, network, shell, and third-party access is not shown; auto-merge and long-running autonomy can create substantial effects without confirmation being demonstrated on every path; tokens are stored in localStorage and settings.json without shown encryption, log redaction, or key-rotation implementation; dependency pin and packaging checks exist but vulnerability scanning, provenance signing, and critical-vulnerability response are not shown; worktrees aid recovery, but no comprehensive transactional rollback procedure is evidenced. Upstream attribution and copyright are present, while publisher identity remains unknown.
The README, package metadata, test scripts, and CI workflows give a reasonably consistent account of Node/pnpm requirements, cross-platform packaging, exact dependency checks, and workspace validation. Tests demonstrate stable mock behavior, cwd-independent fixture reads, and explicit absolute-path ENOENT failures. Deductions apply because only a narrow sample of tests and declarative scripts is supplied; core orchestration, retries, checkpoint recovery, provider fallback, and multi-node failure handling are not statically demonstrated. Desktop packaging is explicitly advisory, availability still depends on registries, model providers, and native binaries, and most end-user failure reporting is described rather than shown comprehensively.
The source thoroughly addresses individual development, multiple projects and nodes, desktop/mobile/web/CLI use, local and cloud models, and customizable per-task workflows, supporting full scores for audience coverage and environment fit. Deductions apply because the product is labeled early preview and several integrations or chat-room features are experimental. Workflow selection and approval controls are documented, but boundaries and precise triggers for long-running autonomy, research, self-improvement, and environment tool use are not comprehensively enumerated.
The README has strong hierarchy, quick starts, workflow diagrams, feature explanations, platform coverage, and documentation links. It provides npx, shell installer, Homebrew, global npm, source-development, and authentication notes. The MIT text agrees with package metadata, justifying full license credit. Deductions apply because fn, fusion, runfusion.ai, and the package name coexist during a beta release; no complete FAQ is supplied; limitations are mostly scattered early-preview or experimental labels; and although changesets, release scripts, a version, issue tracker, and a weekly-shipping claim exist, the evidence contains no actual changelog, support policy, security contact, or clearly assigned individual maintenance responsibility.
Plans with acceptance criteria, live diffs, changed-file views, review gates, task chat, and isolated worktrees are concrete, directly usable software-delivery outputs. Deductions apply because claims such as zero conflicts, human-hours saved, and autonomous operation for weeks are primarily promotional and are not substantiated by the supplied implementation or measurements. Token/productivity telemetry and local-model options help cost awareness, but resource ceilings, detailed budget controls, and comparative outcome data are not shown, limiting marginal-value and cost-benefit scores.
Some claims trace to named settings, file paths, workflow identifiers, version metadata, tests, and CI checks, with limited corroboration across README, package.json, tests, and workflows. Deductions apply because many central capabilities are evidenced only by an automatically translated README, while referenced documentation and core implementation are absent. Claims about 440+ agents, 70+ themes, live fleet statistics, weekly shipping, zero conflicts, and weeks-long autonomy lack independent corroboration, and factual behavior, roadmap-like ambition, and marketing inference are not consistently separated.
- This is a low-confidence static assessment based only on the supplied files; no code, package, test suite, or agent task was executed.
- Before granting access to real repositories, shells, networks, or cloud credentials, verify runtime permission boundaries, command approval, domain restrictions, log redaction, and key revocation behavior.
- Auto-merge, long-running autonomy, self-improvement, and multi-node synchronization can amplify impact; initially disable auto-merge and validate recovery in an isolated non-production repository.
- The curl installer and npx path retrieve remote code; pin and inspect artifacts, verify integrity, and confirm the current vulnerability state of the full dependency tree.
- README claims concerning scale, efficiency, zero conflicts, and weeks-long operation are not sufficiently corroborated by the supplied source and should not be treated as procurement or production guarantees.
What does this agent do, and when should you use it?
Fusion is an MIT-licensed, self-hosted development orchestrator that turns natural-language tasks into reviewable plans, code changes, and Git delivery outcomes. Its components include @fusion/core, @fusion/dashboard, @fusion/engine, and the @runfusion/fusion CLI, exposed through a web board, fn commands, Electron desktop apps, Capacitor mobile apps, and a PWA. A planning agent reads the project and produces a PROMPT.md containing steps, file scope, and acceptance criteria, after which the selected workflow governs planning, review, execution, and rework. Each task runs on a separate fusion/{task-id} branch and Git worktree, so independent jobs can execute concurrently before being delivered through a squash merge or pull request. Runtime metadata uses zero-configuration embedded PostgreSQL by default, with an external shared database available for multi-project and multi-node setups. Support for Anthropic, OpenAI, Ollama, Google Generative AI, Z.ai, Kimi K3, llama.cpp, and custom compatible endpoints makes it suitable for teams that want control over models, source code, infrastructure, and approval boundaries.
A user submits work through the board, chat, or commands such as fn task create and fn task plan. The planning agent reads project context and writes PROMPT.md with ordered steps, affected files, and acceptance criteria. A task can use builtin:coding, builtin:quick-fix, builtin:review-heavy, builtin:stepwise-coding, builtin:compound-engineering, or builtin:pr-workflow, while the Workflow Editor can duplicate and modify workflow graphs, columns, gates, model lanes, and review policy. @fusion/engine then runs planning, review, execution, and rework nodes inside an isolated Git worktree; dependent tasks are processed sequentially and independent tasks can run in parallel. Fusion streams plans, logs, diffs, file changes, PR and issue state, and agent messages to the dashboard, where a user can pause, re-prompt, or steer active work; fn task steer provides the corresponding CLI control. Passing work can be delivered by direct squash merge or a merged PR, but merge and PR progression plus destructive or external-service side effects always require explicit recorded human confirmation. Additional operations include hierarchical Missions, bounded research, scheduled automations and routines, agent mail, task chat, experimental multi-agent rooms, and synchronization across nodes.
- An engineering team maintaining several repositories can run unrelated fixes concurrently while isolating every task in its own Git worktree.
- A team with strict review requirements can select Review-heavy or Stepwise coding and assign separate models and approval rules to planning, execution, validation, and merging.
- A solo developer can keep Fusion running on a Mac mini, Linux host, or cloud VM and inspect tasks, logs, and diffs from a browser, desktop app, or phone.
- A GitHub maintainer can import labeled issues, generate implementation plans, execute changes, create pull requests, and follow live PR and issue status from the board.
- A platform group can define an internal delivery process in the visual Workflow Editor, including nodes, gates, fields, columns, fallback models, and approval policy.
- An organization experimenting with long-running virtual teams can import companies.sh rosters and coordinate them through Missions, heartbeats, mailboxes, and delegation.
What are this agent's strengths and limitations?
- A dedicated fusion/{task-id} branch and Git worktree for every task enables concurrent independent work with reduced file contention.
- Multiple built-in workflows and a visual Workflow Editor expose graph nodes, gates, model lanes, fields, columns, and approval policy without requiring an engine fork.
- The provider layer spans cloud and local models and accepts custom OpenAI-compatible, OpenAI Responses, Anthropic-compatible, and Google Generative AI endpoints.
- Web, CLI, desktop, mobile, and PWA interfaces are paired with documented multi-project and multi-node operation.
- Plans, execution logs, file diffs, reviews, and delivery state remain visible, while merge, PR, destructive, and external-action boundaries retain mandatory human confirmation.
- The repository labels the product an early preview and says it ships weekly, so adopters should budget for rapid change and upgrade validation.
- Useful execution requires at least one authenticated AI provider or a functioning local model service; cloud choices add connectivity, credential-management, and model-usage costs.
- PostgreSQL is now the default runtime store, while legacy SQLite files are accepted only as one-time migration inputs, creating migration work for older deployments.
- Hermes, Paperclip, and OpenClaw runtime plugins and multi-agent Chat Rooms are explicitly experimental, with APIs or wire formats that may change between minor releases.
- Operating the full system involves Git worktrees, a daemon, provider configuration, workflow policy, and database storage, giving it a larger operational footprint than a single coding assistant.
- Even autonomous planner oversight cannot remove the confirmation requirement for merge, PR progression, destructive actions, or external-service effects, which limits fully unattended delivery.
How do you install or deploy this agent?
For the shortest path, run npx runfusion.ai; this launches the dashboard without a global install. On macOS or Linux, the one-line installer is curl -fsSL https://runfusion.ai/install.sh | sh, followed by fusion dashboard. Homebrew users can run brew install runfusion/fusion/fusion and then fusion dashboard; the global npm route is npm install -g @runfusion/fusion, followed by fn dashboard. For source development, run pnpm install and then pnpm dev dashboard. Open the token-bearing URL printed by the command; the server persists the dashboard/daemon token in ~/.fusion/settings.json after the first authenticated run. During onboarding, configure at least one supported AI provider or local model runtime. GitHub authentication is optional and is needed only for issue import and PR management.
How do you use this agent?
Start fusion dashboard or fn dashboard, register or select a project directory during onboarding, and authenticate at least one model provider. Create work on the board or run fn task create "Fix the login bug" to send a task into planning; use fn task plan "Build auth system" for AI-guided planning. Inspect a task with fn task show FN-001, follow execution using fn task logs FN-001 --follow, and redirect active work with fn task steer FN-001 "Use TypeScript". To build a queue from GitHub, run fn task import owner/repo --labels bug. Select the workflow, model lanes, planner oversight level, and auto/manual merge behavior in the task controls. Review the generated plan, live diffs, and gate results, then explicitly approve any merge or PR progression.
How does this agent compare with similar options?
Fusion describes its board as being like Trello, except that cards are specified, executed, and delivered by agents instead of only being moved by people; it also credits dustinbyrne/kb as foundational work. Compared with Paperclip, Fusion natively accepts companies.sh teams and can delegate agent execution to Paperclip through an experimental plugin. Hermes and OpenClaw are likewise presented as experimental runtime integrations, making them optional execution backends rather than complete replacements for Fusion's board, workflow, and Git delivery layers.
FAQ
Does adoption require one particular paid model provider?
Can it merge code or perform destructive actions without approval?
Can it handle multiple tasks and repositories at once?
What security detail matters for remote dashboard access?
~/.fusion/settings.json after the first authenticated run unless overridden. For a remote node, LAN address, or reverse proxy, supported provider logins rewrite callbacks through /api/auth/oauth-callback so they return to the active browser session.How can an operator recover when execution fails or heads in the wrong direction?
fn task logs FN-001 --follow and fn task steer FN-001 "Use TypeScript", while workflow review nodes can route work back to planning or execution for revision.