Hermes Kanban agents need progress and resource guardrails before long autonomous runs
The freshest Hermes operator pain is not a release note; it is a pair of live reports about autonomous coding control loops. Issue #22397 says CLI agents assigned clear Kanban tasks can spend 30 minutes to 2+ hours cycling through read/grep/read inspection with no edits, tests, or deliverables. Issue #22406 reports the opposite failure mode: when the agent does reach a build, CPU can stay at 100% and make the macOS host unusable. PR #22467 is adjacent infrastructure for safer background skill evolution: a pending queue that isolates proposed skill changes, deduplicates entries, caps queue size, detects conflicts, and keeps `.pending/` out of active skill enumeration.
Autonomy is only useful if it can move from understanding to doing, and if doing does not starve the host. These reports matter because they hit the two ends of the same reliability problem: a task loop that never commits work, and a build loop that consumes too much machine capacity once work finally starts.
- Hermes issue #22397 reports repeated read/search cycles for 30 minutes to more than two hours on clear Kanban coding tasks, with no file edits, no test runs, and manual intervention required
- The same report names Kimi K2.6 via kimi-for-coding and MiniMax M2.7 as observed models, suggesting the failure is at least partly in task-control and stopping rules rather than one provider transport
- Hermes issue #22406 reports current-main CLI builds on macOS sustaining 100% CPU and making the machine unresponsive, with the reporter asking for nice/cpulimit-style guards or bounded subprocess behavior
- Hermes PR #22467 adds a file-based pending queue under `~/.hermes/skills/.pending/` with isolation, deduplication, max 100 entries, TTL, conflict detection, and exclusion from active skill listing
- The two bug reports are fresh and may be environment/model-specific until more reproductions arrive
- PR #22467 does not yet wire the pending queue into runtime skill-update behavior, CLI review UI, gateway integration, or notifications
- Resource limits can change build behavior, so teams should validate test/build reproducibility after adding sandbox or CPU constraints