Split Hermes Work into Conflict-Safe Delegation Lanes
Hermes delegation creates isolated child agents, each with its own conversation, terminal session, and tool access. Only a child’s final summary returns to the parent, so delegation can protect the main context from noisy research or debugging traces. That isolation is useful, but it also means every child begins without the parent conversation’s accumulated knowledge.[1]
Decide whether delegation is the right tool
Delegate reasoning-heavy reviews, research synthesis, independent comparisons, or work that benefits from a fresh perspective. Do not delegate a single obvious tool call or a quick edit. Use execute_code for mechanical sequences with logic between many calls. Use a durable scheduler or a tracked background process for work that must survive session closure or process restart; delegated work remains tied to its owning Hermes process.[1]
Parallelism helps only when lanes are genuinely independent. Two research questions can run together. Two code lanes can run together when they own disjoint files. If both may edit a shared schema, lockfile, generated index, or central configuration, sequence that shared change or let the parent perform it after the parallel lanes finish.
Write a complete handoff packet
A child cannot infer what “the bug we discussed” means. Give each lane a self-contained goal and include the project root, relevant file paths, observed error, expected behavior, constraints, test command, and required return format. State whether the lane may edit files or should only investigate. Subagents inherit enabled parent toolsets and cannot grant themselves capabilities the parent lacks; some interaction and state-changing tools are intentionally unavailable to children.[1]
Separate lane work from integration
Use a simple ownership map before starting:
- Lane A: one directory, component, or research question.
- Lane B: a different directory, component, or question.
- Parent lane: shared files, synthesis, conflict resolution, and final verification.
For broad analysis, a gather-then-analyze pattern is efficient: collect structured data mechanically, then give one clean package to a reasoning-focused child. For alternative evaluation, assign one option per child and let the parent compare the summaries against the same rubric. Isolation prevents cross-contamination, but it does not make any conclusion automatically correct.[1]
Delegation checklist
- Confirm the task benefits from fresh context or parallel reasoning.
- Give every lane a self-contained goal, paths, constraints, and test command.
- Assign disjoint ownership for every file or output area.
- Reserve shared files and integration decisions for the parent lane.
- Match required capabilities to the parent’s enabled toolsets before starting.
- Plan a parent-run diff, test, and synthesis pass after all lanes return.
Common pitfalls
- Delegating a vague reference to prior conversation context.
- Running parallel edits against the same file or generated artifact.
- Using subagents for cheap mechanical work better handled in one batch.
- Assuming a final summary contains all evidence or accurately reports test status.
- Launching delegated work that must outlive the current Hermes process.
- Increasing concurrency without considering resource use, review load, or integration cost.
Verification
Treat child reports as leads. The parent should inspect changed files, compare lane outputs against their scopes, rerun the relevant tests, and resolve any shared assumptions. Confirm no lane touched another lane’s ownership area. If two summaries disagree, inspect the underlying evidence rather than averaging their conclusions.