Hermes Agent
Hermes packaging proposal assigns updates to the installation owner
Hermes' evolving bundle proposal unifies tool provisioning and distinguishes source checkouts from sealed desktop, Docker, Nix and APT installs. The current review still lists final-head CI, native update acceptance and maintainer approval as open gates; older passing jobs are not proof for the latest integration.
The current revision of Hermes' broad packaging proposal tries to answer a deceptively basic support question: which component is allowed to update this installation? Its unified package machinery spans the CLI, gateway, desktop, installers and container builds, while installation stamps distinguish mutable source checkouts from sealed packages. The proposal opened earlier in September and was updated again by September 16; this is a watchlist analysis of its present design and acceptance limits, not a newly announced release or a claim that every listed change arrived overnight.
The facts
- PR #102765 centralizes package definitions, pinned artifacts and installed runtime facts under pm/ for multiple Hermes entry points. - It proposes preparing replacement environments before publication and retaining the previous environment when preparation fails. - Core and enabled native-plugin dependencies are resolved together, with incompatible candidates refused rather than disabling working plugins. - Installation ownership distinguishes source checkouts from sealed desktop, Docker, Nix and APT packages and routes update guidance to their owning systems. - The current proposal says sealed Docker images no longer support the writable lazy-install overlay for absent optional SDKs. - Its evidence section explicitly leaves final-head full CI, signed native update/relaunch acceptance and renewed Store acceptance outstanding.
Why it matters
Agent installations are becoming collections of runtimes rather than a single Python environment. Browsers, terminal tools, multimedia helpers and plugin dependencies can each introduce their own provisioning logic. A shared owner can reduce contradictory repair paths, but the proposal's breadth raises the bar for evidence. A successful bundle build on an earlier commit does not verify a later updater merge, and a local source repair is not necessarily appropriate for a sealed application. The distinction is especially important for support systems that might otherwise respond to any missing dependency by modifying the active environment.
Current
Inspected on 2026-09-16. The Hermes Agent stable-channel baseline is v2026.9.14 published 2026-09-14T16:04:14Z. The primary source was open (not merged) when captured. Mainline merges, open proposals and packaged releases are distinct availability states; the release baseline does not establish that a proposal has shipped.
Evidence
Primary evidence: NousResearch/hermes-agent PR #102765 (https://github.com/NousResearch/hermes-agent/pull/102765). Supporting context: Hermes Agent — official product README (https://raw.githubusercontent.com/NousResearch/hermes-agent/main/README.md); Nous Research — Hermes product documentation (https://hermes-agent.nousresearch.com/docs/). The source bodies and linked context were inspected. Test results quoted from contributors remain attributed reports, not independently reproduced experiments.
Operator take
Watch for acceptance evidence tied to the actual candidate revision and installation method, not a wall of historic green jobs. For each proposed deployment route, require installation identity, failed-update recovery and successful relaunch to be demonstrated together. Review plugin preservation separately from core startup because a working application that silently loses an integration is not a successful upgrade. Existing installations should continue following their current supported update path; this report neither recommends applying the open branch nor changes any Hermes configuration. The proposal is valuable design evidence precisely because its unresolved gates are visible.
Caveat
The PR is open and reports conflicts with upstream, incomplete final-head acceptance and some documentation inconsistency. Earlier six-target bundle and full-CI successes are explicitly bound to an older commit. This watchlist does not treat those results as certification for current code or imply that proposed Termux and desktop paths are already released.
The PR is open and reports conflicts with upstream, incomplete final-head acceptance and some documentation inconsistency. Earlier six-target bundle and full-CI successes are explicitly bound to an older commit. This watchlist does not treat those results as certification for current code or imply that proposed Termux and desktop paths are already released.