Synergy: a persistent agent workspace from SII-Holos, not the KVM tool

What Synergy actually solves, and for whom

Most agent tooling assumes a task fits inside one conversation. The README opens with the opposite premise: "AI agent work often outlives a single conversation." Synergy treats that work as durable workspace state, so a task can move between Web, Desktop, CLI, background execution and specialist agents while keeping its project, history, files, tools and operating context.

The target user is a developer or knowledge worker who runs long tasks across a real repository and does not want to re-establish context every time a session ends or a model's context window compacts. The README states that sessions stay attached to an explicit home or project Scope with complete history even when older model context is compacted. That is the specific promise: the transcript may be trimmed, the record is not.

It is not aimed at someone who wants a single API call wrapped in a CLI. The feature list (Agenda scheduling, Library memory, Blueprints, Boss Mode worker trees, Channels, Synergy Link remote targets) describes a workspace with its own vocabulary, and the README points to docs/product/overview.md for the complete product model. If you are not prepared to learn that model, the surface area is a cost rather than a benefit.

One runtime behind Web, Desktop, CLI and SDK

The architectural claim is that the same sessions and state are reachable from the Web workbench, the Desktop app, the CLI, the server API and the SDK. That is a single-runtime design rather than a set of front ends that each own their own conversation store, and it is why the CLI can hand a task to the Desktop app or to background execution without a migration step.

Around that runtime sit the coordination primitives. The README lists delegation to specialist subagents, durable Blueprints, independently reviewed BlueprintLoops, Light Loop for focused work, and Boss Mode for orchestrating a tree of persistent specialist workers. Files and a session-owned Browser page stay in context rather than being moved into a separate tool. Library holds reusable memory and evaluated experiences with reward-signal analytics per behavioral dimension, and Notes and Blueprints are authored as durable documents scoped per project.

Extension points are named but not specified in the README: providers, tools, Skills, commands, MCP servers, plugins, Channels and remote Synergy Link targets. The repository layout is consistent with that breadth (apps/, packages/, a packages/synergy-link package with its own CLI entry, patches/, and a benchmark/ directory), but the README does not document the plugin or Channel interfaces themselves. Treat the extension story as something to verify in docs/ before you design around it.

Installing Synergy and running a first task

The README gives two install paths. Desktop users download an installer from GitHub Releases: a .pkg for macOS, an NSIS .exe for Windows, a .deb for Linux. Desktop installers include the app and expose the packaged runtime as the synergy CLI. Portable artifacts are published too, but the README states they do not configure a system CLI, and Windows Desktop and CLI releases currently support x64.

CLI and Web users install the current release with the curl installer:

curl -fsSL https://raw.githubusercontent.com/SII-Holos/synergy/main/install | bash

That places the runtime, Web UI and schema assets under ~/.synergy/. Setting SYNERGY_HOME=/path changes that root to /path/.synergy/. The README is explicit that the CLI installer does not install the Electron Desktop app.

With the runtime in place, configure a provider, start the background runtime and open the Web client:

synergy config wizard
synergy start
synergy web

For a one-shot task from the terminal, the README's example is:

synergy send "summarize this repository"

The runtime has its own inspection commands. synergy status reports state, synergy logs reads the log stream, synergy doctor checks the installation, and synergy stop shuts the background runtime down. Run synergy doctor first on any machine where you have previously installed an agent CLI: it lists every detected installation channel and exits nonzero when channels conflict or an installed version cannot be verified.

The multi-channel install rule is the sharpest edge

Synergy deliberately allows more than one installation channel to coexist. You can keep the standalone CLI, a package-manager install via npm, yarn, pnpm or bun, and the Desktop app side by side. The constraint is that only one of them should be the synergy command your shell actually runs.

That constraint is enforced softly rather than absolutely. The curl installer and the npm package postinstall warn about other channels they detect and never auto-uninstall them. synergy doctor is the detector: it lists every channel and exits nonzero on conflict or an unverifiable version. Upgrades are where this bites. The README states that when multiple channels are installed, synergy upgrade stops instead of guessing, and you must rerun it with --method <npm|yarn|pnpm|bun|desktop|standalone> to select an installed, healthy channel.

There is a naming trap worth stating plainly. The README notes that Homebrew's synergy formula is unrelated to this project and is not detected or managed. Anyone who searches for how to install Synergy on macOS and reaches for brew will get a different program entirely, and synergy doctor will not warn about it because it does not know it exists. Version pinning is available by passing --version <version> to the installer, which is the safer route for a team that needs reproducible runtimes.

What the published benchmark does and does not tell you

The README reports results on DeepSWE v1.1, described as 113 real repository engineering tasks. Running deepseek-v4-flash with the synergy-max agent is reported to lift Pass@1 from 53% to 67.3% (+14.3pp, 1.27x) at $0.54 per task, against the official mini-swe-agent run of the same model. The failure breakdown given is 76 of 113 tasks fully passed, with 24 of the 37 unsolved tasks missing by only one or two tests.

Those numbers come with a methodology note that matters more than the headline. Synergy figures are from local full-benchmark runs, official leaderboard numbers were fetched from deepswe.datacurve.ai on 2026-08-22, and all costs are computed at API prices in effect before 2026-08-17 00:00 Beijing time, prior to DeepSeek's price increase and peak/off-peak pricing. The cost figure is therefore historical, and the README says so. The resource profile also notes that passed tasks average $0.60 over roughly 2.3 hours.

The honest reading: this is a self-reported comparison of one model under two harnesses, on one benchmark, with the cost basis frozen at a pre-increase price. It is evidence that the harness matters, not evidence that Synergy will improve your specific workload. Nothing in the README reports variance across repeated runs, and there is no independent replication.

Where Synergy is the wrong tool

If your work is a stateless transformation (classify these documents, generate this function, answer this question once), the durable-state machinery is overhead. You pay for a background runtime, a local data root under ~/.synergy/, a provider wizard and a Scope model in exchange for continuity you never use. A plain SDK call or a thin CLI wrapper is the smaller tool.

Platform coverage is another boundary. Windows Desktop and CLI releases currently support x64 only, so ARM Windows machines are not covered by the published installers. The CLI installer also does not install the Desktop app, so a user who wants the Electron surface must take the installer path separately and then manage two channels.

Finally, the extension surface is advertised more than it is documented in the README. Providers, tools, Skills, MCP servers, plugins and Channels are listed as things you can add, but the README does not describe their interfaces or lifecycles, and it does not document rollback behaviour for an upgrade that goes wrong. If your adoption decision depends on a stable plugin contract, the README alone will not settle it.

How it compares to a stateless agent harness

The natural alternative is a stateless harness in the mini-swe-agent style, which is the baseline the README benchmarks against. The difference in approach is where state lives. A stateless harness reconstructs context at the start of each run from whatever the caller passes in, and discards everything at the end. Synergy keeps the session, project Scope, files, tools, Browser page and accumulated Library memory in a local runtime that survives the run.

That changes failure modes in both directions. A stateless harness has no channel conflicts, no upgrade ambiguity, no local data root to back up, and no risk that a stale session misleads the next task. Synergy has all of those, and gains the ability to schedule recurring runs through Agenda, delegate to persistent specialist workers under Boss Mode, and carry learned experience forward in Library. The README's own framing is that connecting a Holos agent adds account identity, messaging, presence and Synergy Link remote execution without replacing local projects, providers, sessions or data, so the local-first posture is a deliberate design position rather than a default.

Pick by task duration. If your tasks reliably finish inside one context window and you do not want them to persist, the stateless harness is simpler and the benchmark's cost comparison does not apply to you. If your tasks span hours, touch a real repository, and need to survive a context compaction, the durable model is the reason to accept the extra moving parts.

Licence, upgrades and the maintenance question

Synergy is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. The README does not state a contributor licence agreement or a trademark policy, and MIT says nothing about the Holos account, Synergy Link remote execution or the hosted website at synergy.holosai.io, which are separate from the code. None of this is legal advice; if you ship Synergy inside a product, have counsel read the LICENSE file at the repository root rather than the README's badge.

Upgrade cost is a real line item here. synergy upgrade handles the simple case, but the multi-channel rule means an upgrade on a machine with both a package-manager install and the Desktop app will stop and require an explicit --method flag. The curl installer and npm postinstall warn about other channels but never remove them, so conflicts accumulate silently until synergy doctor reports them. Version pinning with --version <version> is the available escape hatch for reproducible environments.

On activity: the repository is not archived, and the last push was on 2026-08-23, the same day as the v3.0.21 release. The preceding releases were v3.0.19 on 2026-08-19 and v3.0.18 on 2026-08-15, so the recent cadence is a release roughly every four days. The README does not publish a support window, a deprecation policy or a compatibility guarantee for the SDK and server API, so pin versions and read release notes before upgrading a working install.

Editorial conclusion

Adopt Synergy if your agent work is long-running and you want sessions, files, Browser state and subagent coordination under one local runtime you own, and you are willing to keep exactly one install channel healthy. Do not adopt it if you only need a stateless one-shot completion, if you need Windows on ARM today, or if you want a hosted service rather than a local workspace. Before committing, run synergy doctor on a machine that already has an npm or Desktop install to see how it reports channel conflicts, and read docs/product/overview.md for the Lattice Pathways, Agenda and Channel model, which the README only names.

Frequently asked questions

Official sources

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