Running work on a swarm¶

Requires an initialized orchestrator with separately joined, running workers. Each worker needs a model backend. --role both can conflict with goal submission because the worker and submitting client share an agent identity.

Submit a goal¶

gdc swarm submit "summarise each service README and list exposed ports"
gdc swarm submit "<goal>" --wait --wait-timeout 600

Option	Behavior
No `--wait`	Return a workflow id after acceptance and planning
`--wait`	Poll until the workflow reaches a terminal state
`--wait-timeout`	Wait budget in seconds; default 300

Check on a workflow¶

gdc swarm result <workflow-id>
gdc swarm tasks --workflow-id <workflow-id>

result returns state and the aggregated artifact when available. tasks lists tracked subtasks. Network commands accept --tls-ca, --orchestrator-endpoint, --root and --swarm-id.

How the work flows¶

Step	Operation
Planning	Convert the goal to dependent subtasks
Dispatch	Assign ready tasks to eligible workers
Context	Pass bounded upstream outputs to dependent tasks
Recovery	Retry eligible transient failures
Aggregation	Combine task outputs into the workflow result

The result is returned by the command or terminal view, without a fixed output-file location.

From the terminal app¶

Open /swarm after joining a swarm locally.

Key	Action
`Enter`	Submit the typed goal
`r` with empty input	Refresh tasks
`w`	Refresh the active workflow
`Esc`	Leave the screen

The screen shows connection status, tasks and the active workflow result. Membership changes use CLI operations.

Giving the model to workers¶

gdc serve --role worker --base-url http://localhost:11434/v1 \
  --model qwen3.5:latest --swarm-tls-ca /path/to/cert.pem

Provider configuration can supply the same settings.

Bounding what a worker can reach¶

[swarm]
network_allowlist = ["api.github.com"]
profiles_exposed = ["review", "test"]

Advertised profiles must resolve at startup. See swarm configuration.