| name | delegate-task-4-lane-workaround |
| description | Work around delegate_task batch concurrency cap when the user wants four parallel review lanes. |
| version | 1.0.0 |
| author | Hermes Agent |
| category | coordination |
| tags | ["delegate_task","parallelism","adversarial-review","queue-sweeps","subagents"] |
Delegate Task 4-Lane Workaround
Use when the user explicitly wants 4 parallel subagent lanes, but a single delegate_task(tasks=[...]) batch fails because the environment is capped at delegation.max_concurrent_children=3.
Problem
In this environment, sending 4 tasks in one delegate_task(tasks=[...]) call can fail with an error like:
Too many tasks: 4 provided, but max_concurrent_children is 3.
This happens before any task starts, so you do not get an automatic queue or partial execution.
Reliable workaround
To preserve true 4-lane parallelism:
- Put 3 tasks into one batched
delegate_task(tasks=[...]) call.
- Put the 4th task into a separate single-task
delegate_task(goal=...) call.
- Launch those two delegate calls in parallel from the parent agent.
- If available, use
multi_tool_use.parallel.
- Keep delegated tasks read-only when possible (
terminal, file) and have the parent session do all persistent writes, GitHub comments, and artifact creation.
Best fit
This pattern is especially useful for:
- adversarial plan-review sweeps
- issue triage across multiple independent items
- read-only repo audits where each lane produces a verdict or checklist
Example pattern
Parent launches in parallel:
- Call A:
delegate_task(tasks=[task1, task2, task3])
- Call B:
delegate_task(goal=task4)
Then the parent:
- aggregates the returned summaries
- writes canonical review artifacts
- posts GitHub comments
- updates local tracking docs
Why this is better than serial fallback
If the user asked for "4 at a time," dropping to 3 serially changes throughput and intent. Splitting into 3 + 1 preserves the requested concurrency without requiring config changes.
Cautions
- Do not use delegated children for repo writes you need to persist.
- Be explicit about paths, issue numbers, and output schema because child summaries are compressed.
- If the task is data-gathering-heavy rather than reasoning-heavy, prefer
execute_code instead of more subagents.
- Treat subagent timeouts as recoverable orchestration failures, not task failure. If one or more read-only lanes time out, immediately continue in the parent with direct
gh/git/search/read-file grounding for the missing facts, then record which lanes timed out in the handoff. Do not let a timed-out research lane block obvious safe closeout actions that have been independently verified in the parent session.
