Problem or Use Case
Current Behavior:
The delegate_task tool schema includes provider and model parameters, but these are ignored in the handler implementation (tools/delegate_tool.py lines 403~581). Subagents always use the provider/model configured in ~/.hermes/config.yaml under the delegation: section.
Current function signature:
def delegate_task(
goal: Optional[str] = None,
context: Optional[str] = None,
toolsets: Optional[List[str]] = None,
tasks: Optional[List[Dict[str, Any]]] = None,
max_iterations: Optional[int] = None,
parent_agent=None,
) -> str:
Desired Behavior:
Allow the provider and model parameters in delegate_task to override the global delegation configuration for that specific subagent call. This would enable:
- Orchestrators to spawn specialized subagents, i.e., vision models for image tasks, coding models for development, reasoning models for logic
- Per-task provider/model selection without changing global config
- Better resource utilization, i.e. use lower capacity model for small task, premium model for complex
Use Cases:
- Vision tasks: Spawn subagent with vision capability (e.g. qwen/qwen2.5-vl-72b-instruct:free) for image analysis
- Voice tasks: Use audio-optimized models for speech processing
- Mathematics/Logic: Deploy reasoning-capable models for problem-solving
- Language tasks: Use multilingual or language-specialized models (e.g. multilingual for translation )
- Cost optimization: Route simple tasks to cheaper/free models, complex tasks to premium models
Implementation Approach:
Modify the delegate_task handler in tools/delegate_tool.py to:
- Extract
provider and model from args if provided
- Pass these to the
_resolve_delegation_credentials() function (or equivalent)
- Allow parameter-provided values to override config.yaml delegation settings
- Maintain backward compatibility (when not provided, fallback to config.yaml)
Related Code:
tools/delegate_tool.py: Handler function (lines 403~581)
_resolve_delegation_credentials() function (lines ~583)
- Tool schema definition for
delegate_task
This would transform delegation from a "one-size-fits-all" approach to a flexible per-task provider/model selection system while maintaining the existing config-based approach as fallback.
Proposed Solution
Propose function signature:
def delegate_task(
goal: Optional[str] = None,
context: Optional[str] = None,
toolsets: Optional[List[str]] = None,
tasks: Optional[List[Dict[str, Any]]] = None,
max_iterations: Optional[int] = None,
provider: Optional[str] = None, # Allow provider
model: Optional[str] = None, # Allow model
parent_agent=None,
) -> str:
As mentioned, the source of this information can be from:
- .env
- config.yaml
- agent's decision upon delegation (according to config.yaml)
The actual logistic of the source needs further discussion. I don't mind looking into this, yet, I would prefer being pointed to the right direction for best efficiency
Alternatives Considered
No response
Feature Type
Configuration option
Scope
None
Contribution
Problem or Use Case
Current Behavior:
The
delegate_tasktool schema includesproviderandmodelparameters, but these are ignored in the handler implementation (tools/delegate_tool.pylines 403~581). Subagents always use the provider/model configured in~/.hermes/config.yamlunder thedelegation:section.Current function signature:
Desired Behavior:
Allow the
providerandmodelparameters indelegate_taskto override the global delegation configuration for that specific subagent call. This would enable:Use Cases:
Implementation Approach:
Modify the
delegate_taskhandler intools/delegate_tool.pyto:providerandmodelfromargsif provided_resolve_delegation_credentials()function (or equivalent)Related Code:
tools/delegate_tool.py: Handler function (lines 403~581)_resolve_delegation_credentials()function (lines ~583)delegate_taskThis would transform delegation from a "one-size-fits-all" approach to a flexible per-task provider/model selection system while maintaining the existing config-based approach as fallback.
Proposed Solution
Propose function signature:
As mentioned, the source of this information can be from:
The actual logistic of the source needs further discussion. I don't mind looking into this, yet, I would prefer being pointed to the right direction for best efficiency
Alternatives Considered
No response
Feature Type
Configuration option
Scope
None
Contribution