Concurrent Sub-Agents

The agent can dispatch multiple sub-agent tool calls concurrently. When the LLM emits 2+ sub_agent_* calls in a single response, they execute in parallel via futures::future::join_all rather than sequentially. This is transparent to the LLM — it doesn't need to know about concurrency. It just emits multiple tool calls when the tasks are independent. Non-sub-agent tool calls (file ops, shell commands, etc.) always execute sequentially.

` LLM response contains N tool calls │ ▼ partition_tool_calls(tool_calls) │ ├── sub_agent_* calls (M of them) │ │ │ ├── M >= 2 → futures::future::join_all (concurrent) │ └── M < 2 → sequential (no spawn overhead) │ └── other calls (N - M of them) │ └── sequential (always) │ ▼ merge results by original index │ ▼ feed all results back to LLM as one User message `

Partitioning (agentic_loop.rs): • is_sub_agent_tool(name) — checks name.starts_with("sub_agent_") • partition_tool_calls(calls) — splits into (Vec<(index, call)>, Vec<(index, call)>) preserving original indices Concurrent dispatch (agentic_loop.rs): • Each sub-agent call runs through execute_single_tool_call() which handles loop detection, HITL approval, execution, event emission, truncation, and post-tool hooks • join_all collects (original_index, result) tuples • Results are placed into a pre-allocated Vec<Option<...>> by index, then flattened in order Shared state — all references are concurrency-safe: • AgenticLoopContext fields are &Arc<RwLock<T>> — cloneable across tasks • LoopCaptureContext uses std::sync::Mutex for interior mutability (&self, not &mut self) • ToolRegistry::execute_tool takes &self (uses read() lock, not write()) • SubAgentContext.depth is passed by value — no shared mutable state • Each sub-agent gets its own SubAgentTranscriptWriter keyed by request ID HITL approval works naturally — each concurrent sub-agent independently creates its own oneshot channel and emits its own ToolApprovalRequest event. Since join_all runs all futures concurrently, all approval requests appear in the UI simultaneously.

No file locking is used. When two concurrent sub-agents edit the same file, edit_file's old_text exact-match semantics act as natural conflict detection — the second edit fails because the file content changed. The sub-agent sees the error, re-reads the file, and retries. In practice, conflicts are rare since the main agent dispatches agents to different tasks.