hermes - 💡(How to fix) Fix UX feedback: explicit worker cockpit before always-on concierge routing

Hi Hermes team — I wanted to share a user experience report from trying to use Hermes as a more “agentic cockpit” for my own workflows.

This is not a bug report exactly. It is more of a product/UX reflection from a local experiment.

What I was trying to do

My original goal was to use Hermes in a way that feels closer to a multi-agent cockpit:

• keep a main conversation open,
• spin up multiple longer-running agent/worker tasks,
• see those tasks in one place,
• close and reopen the interface without losing the sense of what is running,
• ask “what is happening?” / “status?” / “stop this” naturally,
• and eventually use Telegram/CLI/TUI as different surfaces for the same ongoing work.

In other words, I wanted Hermes to feel less like a single chat session and more like a control surface for multiple agent threads.

Around the same time, Claude Code introduced more visible agent/thread-style affordances, which made this desire more concrete for me: I wanted something lightweight where I could have several background tasks running, but still have one understandable view of them.

What I tried locally

I experimented with a “concierge/frontdesk” style layer in Hermes.

The idea was:

• the main agent would remain available,
• long-running work would be routed to worker lanes / Kanban-style tasks,
• status/stop/meta questions would be intercepted by the control layer,
• and worker progress/results would be surfaced back to the user.

I tried several approaches:

• letting Hermes itself attempt the orchestration,
• delegating pieces to Claude Code,
• using the Telegram gateway as a control surface,
• running overnight Codex iterations to stabilize parts of the behavior,
• and testing worker lanes / Kanban / gateway status handling.

Some of it worked technically, but the overall UX still felt difficult.

What I learned

The hard part was not just “spawn another agent”.

The hard part was the layering:

1. Is the user talking to the main agent, an existing worker, or starting a new task?
2. Is “what are you doing?” a new task, a status query, or steering?
3. Should “also do X” attach to the current worker, create a new worker, or remain in the main chat?
4. How should worker progress be displayed so it feels live but not noisy?
5. How do CLI/TUI/Telegram all reflect the same durable task state?
6. How do we avoid the router becoming too clever and accidentally hijacking normal conversation?

I came away feeling that an always-on “smart concierge” may be too high-level as the first UX layer.

It is powerful, but also risky: if it misclassifies user intent, the whole system feels less predictable.

Suggestion

My current suggestion would be to prioritize an explicit worker/thread cockpit before a fully automatic concierge.

Something like:

• main chat always answers by default,
• workers are created explicitly,
• /workers or a dashboard shows active/done/blocked tasks,
• each worker has a title, status, last event, result, logs, stop/retry controls,
• worker output is visually distinct from main-agent output,
• reopening the UI restores the same task view,
• natural-language routing can be added later as a convenience layer, not the foundation.

In short:

“Main agent by default; explicit worker cockpit first; smart concierge later.”

This would still support the larger vision of Hermes as a multi-agent operating surface, but with a more predictable UX foundation.

Why I’m sharing this

I had originally hoped to carry a local branch/fork for this, but I realized the upstream implementation may eventually solve this more cleanly. If so, I would rather share the experience and lessons than maintain a long-lived divergent branch.

The main takeaway from my experiment is:

• multi-agent worker execution is a backend capability,
• but making it feel trustworthy requires a durable, visible, user-controllable cockpit layer,
• and automatic intent routing should probably come after that cockpit is solid.

Happy to share more details from my local experiment if useful.

If there is already an issue/discussion tracking this direction, feel free to point me there and I can move this as a comment.