hermes - 💡(How to fix) Fix [Feature]: Add an opt-in /Efficiency mode for kanban-backed auto orchestration [1 participants]

Problem or Use Case

Hermes already has a strong durable collaboration substrate in Kanban, but today there is no opt-in user-facing mode that sits above it and automatically handles:

• task decomposition
• task dispatch
• lightweight result comparison
• result collection
• gradual experience accumulation for future routing

Right now, Kanban is powerful once the user (or agent) has already decided to use it, but there is still a gap between:

• normal one-shot chat execution, and
• a more workflow-oriented orchestration experience

I think this becomes especially interesting for longer or multi-stage tasks where Hermes could act more like a lightweight orchestrator without requiring a heavy new runtime.

Proposed Solution

I’d like to propose an opt-in /Efficiency mode built on top of the existing Kanban system.

MVP shape

The core of the MVP would be a thin auto orchestrator that mainly does:

• planning
• dispatching
• comparing
• collecting
• recording experience

Importantly, the orchestrator would not directly do most worker tasks itself. It would mostly route work into Kanban-backed execution.

Intended behavior

A user could do something like:

/Efficiency <task>

and Hermes would:

1. decide whether the task should be decomposed
2. create/drive a small Kanban workflow
3. dispatch most concrete work to workers
4. collect results and return a final answer

Conservative routing / probe idea

I also think there is a useful incremental path here for model efficiency:

• keep the user’s current default model path as the stable main lane
• optionally add a very lightweight low-cost probe lane (for example DeepSeek V4 Flash) on selected node types
• record whether the cheaper model was “good enough” on those nodes
• gradually build routing experience over time

However, I want to stress that I do not think this probe/routing part should dominate the initial PR. The main MVP value is the auto orchestration layer over Kanban. Probe-based learning can be a later incremental step.

Alternatives Considered

1. Build this as a separate product / external orchestration layer

I think this is worse because the idea depends heavily on existing Hermes-native primitives:

• Kanban
• slash commands
• worker profiles
• provider/model abstraction
• persistent memory / long-term adaptation
• gateway + CLI flows

So this seems much better as an upstream Hermes enhancement than as a separate standalone product.

2. Lead with heavier multi-lane parallelism

An earlier version of the idea emphasized 2–4 lane concurrent execution as the center of the feature.

I now think that is too broad for the first version.

A better progression seems to be:

• first add a thin opt-in auto orchestrator on top of Kanban
• then, if that direction is welcome, add a small observational probe lane later

3. Turn this into a general workflow/DAG engine immediately

I think that would be too much scope for an initial contribution. The more realistic path is a narrow, opt-in orchestration mode that reuses the existing Kanban substrate.

Feature Type

CLI improvement

Scope

Large (new module or significant workflow addition)

That said, I would propose implementing it in small PRs, not as one big change.

Non-goals for v1

To keep the scope reasonable, I would explicitly not target the following in the first version:

• a generalized DAG engine
• a heavy evaluator/gate system
• aggressive multi-model sampling by default
• automatic global model replacement
• RL training / policy optimization
• heavy sandbox/security changes
• replacing existing Kanban workflows

The intent is to add a thin orchestration layer, not a whole new platform.

Why I think this may fit Hermes well

This seems aligned with Hermes’ existing direction because Hermes already has:

• durable Kanban collaboration
• multiple execution paths
• model/provider flexibility
• long-term memory / personalization
• slash-command-driven power-user workflows

So this would feel less like “adding a separate product idea” and more like “adding an opt-in orchestration mode that helps Hermes become more workflow-aware over time.”

Contribution

I’d be happy to implement an initial small P0 PR if this direction seems aligned.

My current thought for the first mergeable step would be something like:

• add /Efficiency
• add a thin orchestration entrypoint over Kanban
• keep it conservative
• defer probe/routing memory to follow-up PRs unless maintainers think a tiny stub belongs in P0

If this direction is interesting, I can also turn it into a more concrete implementation plan / PR breakdown first.