Run a fleet of agents in parallel
You have the same change to make in forty repositories, and one agent at a time would take all week. With Marshal you save the job once as a mission and launch it once per repository. Each launch becomes its own run in its own fresh space, as many run side by side as you allow, and the rest wait in line and start by themselves.
The result
- One saved prompt, launched once per repository, with the repository passed in as an input.
- Every run works alone in a clean space, so one repository’s build never touches another’s.
- You decide how many run at once. Extra launches wait and start, oldest first, as slots free.
- One list shows the whole fleet, and the dashboards show what it cost.
How it works
The Platform team owns a deputy, platform-bot, with a mission migrate-logging whose prompt uses the input {{.repo}}. You launch it once per repository from the CLI. The mission’s Runs at once, per mission limit decides how many run together. Each run starts in its own space, sized by the deputy’s Default compute class. Launches over the limit show in the deputy’s Waiting to start card and start by themselves when a run finishes. You follow them all on Runs, filtered to the mission.
- A run counts against the limit while it is pending, running, waiting on a person or taken over. A parked run frees its slot.
- A mission can hold up to 100 waiting launches, and a waiting launch expires after 24 hours.
- An org owner or admin can set an org-wide Runs at once, per mission under Settings > Deputies. A deputy can go lower, never higher.
What you use
| Piece | Its role here |
|---|---|
| Deputies | Owns the mission, the manifest and the concurrency limit for the fleet. |
| Runs | One per repository, each in its own fresh space with its own record. |
| Manifests and stacks | The one environment every run in the fleet gets. |
| Compute sizes | The size of each run’s space. |
| Start and track runs | The Runs list, its filters, and the CLI to watch the fleet. |
| Home and notifications | Where a run’s question reaches you, so one stuck repository never holds up the rest. |
| Admin dashboards | Compute and LLM cost for the fleet. |
Build it
-
Create a team manifest with
claude-code,githuband your toolchain, bound to the team’s GitHub credential. See Create a manifest. -
Create the deputy, and a mission with an input
repothat its prompt uses as{{.repo}}. Try it with Dry run, then Activate. See Create a deputy and a mission. -
On the deputy’s About card, set Runs at once, per mission and Default compute class. See Configure a deputy.
-
Launch once per repository:
for repo in acme/api acme/web acme/jobs acme/billing; do marshal deputies launch platform-bot --mission migrate-logging --input repo=$repo doneSee Launch a mission.
-
Open Runs, filter by the deputy and the mission, and add a status filter for the runs that need you. See The Runs list.
-
Answer questions from Home or Slack as they come in. See Answer a question from a run.
-
An org owner or admin checks the cost on Dashboards > Costs: LLM and compute side by side, with each deputy’s share on the Deputies dashboard. See Costs.
Make it yours
- Let an event fill the fleet. Bind the mission to a GitHub event, and every new pull request adds a run. See Schedules and triggers.
- Run it every night. Put the mission on a schedule, and let each night’s runs queue behind the limit. See Nightly dependency upgrades.
- Bigger repos, bigger spaces. Pick Compute class for this run in the launch dialog for the monorepo, and keep the rest on the default.
- Steer one without stopping the rest. Open any run to message it or take over its space. See Steer a live run.