Problem
When git.use_worktrees = true, each ticket gets an isolated worktree at a different path, so there is no technical reason two agents can't work on the same repo simultaneously. However, the dispatch logic in try_launch and auto_launch calls State::is_project_busy() — a hard boolean that blocks any second agent on a repo, regardless of worktree isolation.
This makes the 1-per-repo limit feel arbitrary and frustrating when worktrees are enabled.
Proposed solution
Add a max_agents_per_repo field to [agents] in config.toml:
[agents]
max_parallel = 5
max_agents_per_repo = 3 # default: 1 (fully backward-compatible)
When set to 1 (the default), behaviour is identical to today. When set higher, the dispatch logic counts running agents for that project and only blocks when the count reaches the limit.
Implementation
- Add
max_agents_per_repo: usize to AgentsConfig with #[serde(default = "default_max_agents_per_repo")] (default returns 1)
- Add
State::project_agent_count(project: &str) -> usize alongside is_project_busy()
- Refactor
is_project_busy() to delegate to project_agent_count() >= 1 (no behaviour change)
- Update
try_launch and auto_launch to compare project_agent_count against max_agents_per_repo
- Status message updated to show
N/MAX agents active for clarity
A working implementation is available in PieterPel/operator#feat/multiple-agents-per-repo.
Problem
When
git.use_worktrees = true, each ticket gets an isolated worktree at a different path, so there is no technical reason two agents can't work on the same repo simultaneously. However, the dispatch logic intry_launchandauto_launchcallsState::is_project_busy()— a hard boolean that blocks any second agent on a repo, regardless of worktree isolation.This makes the 1-per-repo limit feel arbitrary and frustrating when worktrees are enabled.
Proposed solution
Add a
max_agents_per_repofield to[agents]inconfig.toml:When set to
1(the default), behaviour is identical to today. When set higher, the dispatch logic counts running agents for that project and only blocks when the count reaches the limit.Implementation
max_agents_per_repo: usizetoAgentsConfigwith#[serde(default = "default_max_agents_per_repo")](default returns1)State::project_agent_count(project: &str) -> usizealongsideis_project_busy()is_project_busy()to delegate toproject_agent_count() >= 1(no behaviour change)try_launchandauto_launchto compareproject_agent_countagainstmax_agents_per_repoN/MAX agents activefor clarityA working implementation is available in PieterPel/operator#feat/multiple-agents-per-repo.