Hermes orchestrator harness architecture

Hermes Orchestrator Harness Architecture

The Hermes orchestrator harness is designed with Hermes serving as the control plane rather than the primary implementation worker Verified Answer #1. In this architecture, the control plane maintains project-wide context, decomposes goals, selects execution paths, and manages budgets and approvals Verified Answer #1. It is also responsible for communicating with the founder and independently verifying outputs Verified Answer #1. Implementation tasks are performed in bounded, disposable workspaces by specialized workers Verified Answer #1.

Delegation Planes

The architecture utilizes two distinct delegation planes to manage work Verified Answer #1:

• Native delegate_task: This plane is used for fast, isolated, and homogeneous subagent work, typically utilizing a cheap local model pool Verified Answer #1.
• Worker Profiles: This plane uses Kanban or one-shot CLI dispatch for heterogeneous routing to various models, including local Ollama instances, Anthropic/Claude, OpenAI Codex, and specialized reasoning models Verified Answer #1.

Technical Constraints and Schema

As of August 12, 2026, the delegate_task tool call in Hermes follows a specific model-facing schema Verified Answer #1. Accepted fields include goal, context, tasks, role, and output_schema Verified Answer #1. The background field is currently deprecated or ignored Verified Answer #1. Valid roles for subagents are strictly limited to leaf and orchestrator Verified Answer #1.

The native delegate_task function does not support per-call arguments for model, provider, toolsets, sandbox, or max_iterations Verified Answer #1. All native child agents use the single provider and model configured in the delegation.* settings Verified Answer #1. Furthermore, subagents inherit the toolsets enabled for the parent, though they remain subject to specific child restrictions Verified Answer #1.

Execution Surface Recommendations

The architecture recommends specific execution surfaces based on the nature of the task Verified Answer #1:

• Mechanical operations: Tasks requiring no judgment should use terminal or execute_code without an LLM Verified Answer #1.
• Bounded reasoning: Cheap, isolated reasoning by a single homogeneous worker should use the native delegate_task Verified Answer #1.
• Independent subtasks: Multiple cheap subtasks should be handled via delegate_task(tasks=[...]) Verified Answer #1.
• Heterogeneous tasks: When different models are required for each task, worker profiles should be used Verified Answer #1.