Swarm's Architecture
One Swarm can become many.
Swarm starts as a local AI coding workspace: the installed launcher starts the swarmd daemon, terminal UI, and browser desktop against local repositories and XDG-aware runtime state.
A local workstation, a local child container, and a remote Linux host are not separate products. They are places Swarm can route work, attach children, and report back through the same coordinated runtime model.
Replication model
One local runtime. Three places to run the work.
Origin swarm
swarmd
Local.
Run the installed launcher, swarmd daemon, terminal UI, and browser desktop beside your editor and files.
Child runtimeContainer.
Create local child swarms with selected workspace context when Podman or Docker is available.
Linux hostRemote.
Deploy a child swarm to a Linux host over SSH, then keep it attached through a configured callback endpoint.
Run paths
Start local. Grow when you need to.
Start on your own machine. Local Swarm runs next to your editor, terminal, browser, and files, so you can work with agents without setting up a network.
When the work needs a box around it, containers let your local Swarm create child runtimes with selected workspace context. Podman or Docker must be available for local child swarms.
When something should keep going somewhere else, remote hosts give Swarm a Linux machine to attach over SSH, run with Docker or Podman on that host, and call back through a configured reachable endpoint.
Flows
Flows are target-owned scheduled jobs.
For scheduled work, the controller syncs Flow assignments to a target, but the target swarm stores accepted revisions and runs its own scheduler. Once a target accepts a revision, controller downtime should not stop scheduled execution.
Remote and container targets only count as selectable when they are attached and have a reachable backend endpoint. If a target cannot be reached, Flow delivery remains pending instead of pretending the assignment installed successfully.