Summary

Allow delegate_task to spawn subagents from named agent profiles defined in config.yaml, so users can build custom orchestration harnesses (similar to oh-my-opencode-slim's Pantheon agents) without modifying Hermes core.

Problem

Currently, delegate_task creates subagents as clones of the parent agent with limited customization:

This means building multi-agent orchestration patterns (e.g., "route codebase exploration to a fast/cheap model, architectural decisions to a strong model, UI work to a specialist") requires either:

1. A skill that manually constructs the right context string for each delegation — fragile, not composable
2. An external agent CLI via acp_command — loses Hermes integration (memory, tools, config)
3. Modifying Hermes core — defeats the purpose of a user-facing feature

Proposed Solution

1. Config-level agent profile definitions

Add an agent_profiles section to config.yaml:

agent_profiles:
  explorer:
    model: google/gemini-2.5-flash          # cheap, fast
    system_prompt_file: ~/.hermes/profiles/explorer.md  # optional: external file
    toolsets: [file]                          # read-only codebase access
    max_iterations: 30
    delegation:                               # inherit from parent's delegation config
      provider: openrouter

  oracle:
    model: anthropic/claude-opus-4             # strong, expensive
    system_prompt_file: ~/.hermes/profiles/oracle.md
    toolsets: [file, web]
    max_iterations: 50

  fixer:
    model: meta-llama/llama-4-maverick         # fast implementation
    system_prompt_file: ~/.hermes/profiles/fixer.md
    toolsets: [terminal, file]

  wp-designer:
    model: anthropic/claude-sonnet-4
    system_prompt_file: ~/.hermes/profiles/wp-designer.md
    toolsets: [file, browser]
    skills: [web-design-guidelines, gsap-core]  # load specific skills

2. Profile-aware delegate_task

Add an optional profile parameter:

delegate_task(
    goal="Analyze the codebase structure",
    profile="explorer",   # <-- new parameter
)

When profile is specified:

• Load the named profile from agent_profiles config
• Use the profile's model instead of delegation.model
• Use the profile's system_prompt_file (or inline system_prompt) instead of _build_child_system_prompt()
• Use the profile's toolsets intersection with parent's enabled toolsets
• Use the profile's max_iterations if set
• Use the profile's delegation (provider/api_key) overrides if set

When profile is omitted, behavior is unchanged (backward compatible).

3. Batch mode with mixed profiles

delegate_task(tasks=[
    {"goal": "Find all API endpoints", "profile": "explorer"},
    {"goal": "Review the auth module architecture", "profile": "oracle"},
    {"goal": "Fix the failing test in test_auth.py", "profile": "fixer"},
])

4. Profile prompt resolution

Priority (highest wins):

1. profile.system_prompt — inline prompt in config
2. profile.system_prompt_file — external .md file
3. Fallback to current _build_child_system_prompt(goal, context) behavior

This lets users either embed short prompts in config or maintain separate prompt files.

Use Cases

Use Case 1: Cost-optimized delegation (personal)

Currently all subagents run on the same model as the parent. With profiles:

• Codebase exploration → gemini-2.5-flash (cheap, fast)
• Architecture decisions → claude-opus-4 (strong, expensive)
• Test fixes → llama-4-maverick (fast, capable)

This alone can cut subagent costs by 50-80% for mixed workloads.

Use Case 2: Custom orchestration harness (project-specific)

A WordPress renewal project could define:

• wp-designer — UI/UX specialist with browser + design skills
• wp-deployer — SSH deployment specialist with terminal only
• wp-reviewer — QA reviewer with browser + vision

The orchestrator (main agent) routes work to the right specialist based on the task type.

Use Case 3: oh-my-opencode-slim parity

oh-my-opencode-slim implements a "Pantheon" of 6 specialized agents (Orchestrator, Explorer, Librarian, Oracle, Designer, Fixer) with per-agent model/tool/prompt configuration and a Council multi-model consensus system. Agent profiles would allow Hermes users to replicate this pattern natively.

Use Case 4: Team/organization profiles

Different teams could maintain different profile sets:

• security-audit/ profiles (read-only, no shell)
• frontend/ profiles (browser + file, design skills)
• devops/ profiles (terminal, SSH, Docker)

Environment

• Hermes version: latest (master branch)
• OS: Oracle Linux 9 (aarch64), macOS 15 (Apple Silicon)
• Python: 3.11

Affected Code Paths

• tools/delegate_tool.py — _build_child_agent(), _build_child_system_prompt(), DELEGATE_TASK_SCHEMA, delegate_task()
• hermes_cli/config.py — config loading (add agent_profiles schema)
• cli-config.yaml.example — documentation of new config section

Non-Goals

• Inter-agent communication — subagents still return summaries to parent only (addressed by Feature: Multi-Agent Architecture — Orchestration, Cooperation, Specialized Roles & Resilient Workflows #344)
• Dynamic profile switching mid-session — profiles are static config
• Profile inheritance/composition — each profile is self-contained (no base+override pattern)
• Built-in profiles — no default profiles shipped; users define their own

Related Issues

This feature overlaps with several existing proposals. Rather than subsuming them, this issue focuses specifically on the config-level profile definition + delegate_task integration:

• Feature: add named delegation capability profiles for subagents #4928 — Named delegation capability profiles (closest in scope; focused on tool/memory scoping)
• Feature: Agent Mode System — Persona + Tool Scoping + Behavioral Constraints (inspired by Kilocode) #476 — Agent Mode System with persona + tool scoping (broader; includes single-agent mode switching)
• Feature: Multi-Agent Architecture — Orchestration, Cooperation, Specialized Roles & Resilient Workflows #344 — Multi-Agent Architecture umbrella issue (full orchestration vision; this is a stepping stone)
• Feature Request: Native Multi-Agent Support #7517 — Native Multi-Agent Support (session-level agent isolation; complementary)
• feat: delegation model tiers + list_models tool (builds on #7586) #7929 — Delegation model tiers (model selection per delegation; subsumed by profile's model field)
• [Feature]: Allow delegate_task to accept provider/model parameters #5012 — Allow delegate_task to accept provider/model parameters (per-call override; profiles generalize this)

Open Questions

1. Should profiles support skills loading? (complex — requires skill resolution at delegation time)
2. Should profiles support per-tool allow/deny/ask rules like Kilocode's mode system (Feature: Agent Mode System — Persona + Tool Scoping + Behavioral Constraints (inspired by Kilocode) #476), or is toolset-level scoping sufficient for v1?
3. Should there be a default_profile in delegation config that applies when profile is omitted but agent_profiles are defined?