hermes - 💡(How to fix) Fix Feature request: native idle maintenance queue for agent-requested restarts and updates [1 participants]

Summary

Add a native idle-maintenance queue so Hermes agents, managers, cron jobs, and operators can request a gateway restart or update without interrupting active chats. The gateway would accept inspectable maintenance requests, wait until the profile is idle and drained, then execute the existing safe restart/update path.

Problem

Today, when agents install new capabilities, update tools, change config, or discover that a gateway reload is needed, there is no first-class handoff from "this needs a restart/update" to "do it safely when nobody is actively using the profile."

That creates an awkward choice:

• tell the user to remember to run /restart later
• restart immediately and risk interrupting an active conversation
• build local scripts outside Hermes that only work on one machine
• leave new capabilities installed but inactive until someone notices

Hermes is becoming more agentic: agents can discover, sandbox-test, install, and configure useful capabilities. The missing piece is a native, conservative control plane for the final disruptive step.

Proposal

Introduce a native gateway idle-maintenance queue.

Agents and humans should be able to submit requests like:

• queue restart after 20 minutes of gateway idle time
• queue update after idle, then restart if needed
• inspect pending maintenance
• cancel a queued request

The gateway should be the only component that executes the maintenance. Tools, slash commands, and CLI commands should only submit or inspect requests.

Suggested UX

Agent tool:

{"action":"queue_restart","reason":"new tools installed","idle_seconds":1200}

CLI:

hermes gateway maintenance status
hermes gateway maintenance restart --reason "new tools installed" --idle-seconds 1200
hermes gateway maintenance update --reason "new version available"
hermes gateway maintenance cancel <request-id>

Gateway slash command:

/maintenance status
/maintenance restart
/maintenance update
/maintenance cancel <request-id>

Safety model

The maintenance queue should be conservative by default:

• no immediate restart/update from agent tools
• no execution while active agent runs exist
• no execution while the gateway is draining
• configurable idle window, default around 20 minutes
• durable queue state so requests survive process exits
• inspectable status and cancellation
• dedupe compatible queued requests to avoid restart storms
• use the existing graceful restart/update paths rather than a separate process killer
• preserve current hard gates around secrets, auth, spend, sends, account changes, and destructive actions

Why this belongs in Hermes core

This would make Hermes feel more like an autonomous operating layer instead of a chat bot with manual maintenance steps.

The product behavior becomes:

1. Agent discovers or installs something useful.
2. Agent sandbox-tests it.
3. Agent queues a safe idle reload/update if runtime activation needs it.
4. Gateway waits until the profile is idle and drained.
5. User later finds the new capability active without being interrupted.

That is the right default for multi-profile Hermes deployments, cron agents, delegated workers, and long-running Telegram/Discord/Slack gateways.

Implementation shape

One possible implementation:

• gateway/maintenance.py: small file-backed queue and request state machine
• agent tool: gateway_maintenance
• CLI: hermes gateway maintenance ...
• gateway watcher: consumes queued work only after idle/drain checks pass
• config: gateway.maintenance_idle_seconds plus env override
• tests around queue persistence, dedupe, active-agent deferral, CLI/tool behavior, and integration with existing restart drain behavior

Acceptance criteria

• agents can request a restart/update without executing it immediately
• humans can inspect and cancel queued maintenance
• gateway executes only after an idle window and no active agents
• restart/update reuses existing Hermes paths
• works across profiles via Hermes home/profile state
• focused tests cover queue behavior and active-session safety
• docs explain the feature and operational semantics

Non-goals

• no new privileged daemon
• no broad process killing
• no automatic secret/auth/account changes
• no forced restart of active chats
• no dependency on local user scripts outside Hermes