Delegate Task 4 Lane Workaround

---
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:

1. Put 3 tasks into one batched `delegate_task(tasks=[...])` call.
2. Put the 4th task into a separate single-task `delegate_task(goal=...)` call.
3. Launch those two delegate calls in parallel from the parent agent.
   - If available, use `multi_tool_use.parallel`.
4. 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.