Hermes Agent v0.17 pushes agent work beyond the terminal

Hermes Agent v0.17.0 is not a small release-note bump. Nous Research published the update on June 19, 2026, with the project describing it as “The Reach Release”: a two-week jump from v0.16.0 that adds new messaging surfaces, background subagents, image editing, profile management, automation templates, and a heavier security pass.

The important change is not any single integration. Hermes has been moving from a terminal agent into a multi-surface work system: CLI, desktop app, dashboard, messaging platforms, cron jobs, skills, memory, MCP servers, and profile-specific deployments. v0.17.0 makes that direction clearer. The agent can now show up in more channels, hand work to background workers, manage more of its own setup from the dashboard, and operate under tighter rules when teams run it across profiles or gateways.

New places to talk to the agent

The headline channel addition is iMessage through Photon Spectrum. The release adds a Photon platform plugin with device-code login, a gRPC-native channel, markdown rendering, emoji reactions, and outbound media support. The practical point is that Hermes can now send and receive iMessage without a Mac relay or a BlueBubbles bridge sitting somewhere as infrastructure.

That matters because Hermes is already designed to run through messaging gateways. A terminal agent is useful while the operator is at the machine. A gateway agent is useful when the work starts from the place the operator already communicates. The iMessage path expands that idea into Apple’s blue-bubble world without asking users to self-host the relay layer.

v0.17.0 also adds Raft as a bundled platform adapter. The release notes describe a wake-channel bridge where Raft can wake Hermes as an external agent while passing metadata such as event IDs and timestamps rather than message bodies. That is a sensible boundary for agent networks: the external system can route work, but Hermes still treats the actual content as something to fetch and handle inside its own trust model.

WhatsApp also gets a more official route. Alongside the existing bridge-based setup, Hermes now supports Meta’s WhatsApp Business Cloud API adapter. For teams, that is less about novelty and more about removing another long-running bridge process from the reliability story.

Background subagents change the work pattern

The most agent-native feature in v0.17.0 is async delegation. delegate_task(background=true) now starts a subagent, returns a handle immediately, and lets the parent conversation keep moving while the delegated work continues. When the subagent finishes, the result re-enters the conversation as a new turn.

That sounds like a small API flag, but it changes how long jobs feel. A user can ask Hermes to start a research pass, build check, code review, or multi-step investigation, then keep using the main chat instead of waiting on the child run. For real operator workflows, this is closer to how teams already work: assign a thread of work, keep context in motion, and consume the result when it is ready.

The desktop app now reflects that direction too. v0.17.0 adds live subagent watch windows, so delegated activity can stream into its own pane. The release also adds rebindable shortcuts, native OS notifications with per-type toggles, a composer model selector with presets, a resizable VS Code-themed terminal pane, automatic right-to-left and bidirectional text direction, per-thread drafts, and support for installing VS Code Marketplace themes.

That combination makes the desktop app more than a wrapper around chat. It is becoming the place where an operator can watch several agent tasks, switch models, handle terminal work, and keep profile-specific state visible.

The dashboard becomes a control plane

The web dashboard gets one of the larger operational upgrades in the release: a full profile builder. Users can create a Hermes profile from the browser, choose a model, attach skills, and connect MCP servers without manually editing config.yaml. Multi-profile management is also unified into a machine-wide view with a global profile switcher.

This is where v0.17.0 starts to look less like a personal CLI tool and more like something a power user or small team can administer. Profiles are one of Hermes’ stronger ideas because they let different agents carry different memories, skills, tools, models, and operating rules. Moving profile creation into the dashboard lowers the cost of setting up specialized agents without flattening them into one generic assistant.

The dashboard’s Skills Hub browser was also rebuilt with connected hubs, featured skills, previews before install, and a security scan on each skill. That is the right direction for a system that treats skills as durable procedural memory. If skills are going to shape agent behavior across sessions, users need a better way to inspect them before installation.

Secure dashboard login also gets attention. The release fixes token-required endpoints so they return 401 behind the OAuth gate, routes websocket auth through the served dashboard token, and warns when a public_url override is rejected. Those are not flashy features, but they matter if a dashboard moves from localhost convenience to something exposed on a network.

Image editing, automation, memory, and models

The image_generate tool now supports image-to-image editing, not just new image generation. A user can pass an existing image and a prompt, then route the request through the configured provider’s edit endpoint. For article work, design iteration, screenshots, and branded media cleanup, that is more useful than another text-to-image button.

Automation Blueprints are another quality-of-life change with deeper implications. Instead of learning cron syntax or filling awkward key-value commands, a user can pick an automation template and answer the parameters Hermes needs. The same blueprint definition can render across dashboard forms, CLI/TUI commands, messaging surfaces, documentation, and agent conversations. That makes scheduled agent work easier to set up without hiding the fact that it still needs a schedule, prompt, and delivery target.

The memory tool also gets an atomic batch operation mode. The model can add, replace, and remove memory entries in one operation while checking the final character budget. That removes a brittle failure case: previously, freeing space and adding a better memory could require multiple calls, and an add could fail before the cleanup happened.

On the provider side, the release adds grok-composer-2.5-fast to the xAI OAuth model picker and reconciles its context window to 200,000 tokens. The release frames it as access to Cursor’s Composer model through an xAI Grok subscription. Hermes also adds or updates model support for GLM-5.2, Claude Fable 5, Laguna M.1, Nemotron 3 Ultra, OpenRouter credential detection, Codex OAuth account separation, Bedrock fallback behavior, and several provider-specific routing fixes.

Fleet controls and security are part of the story

v0.17.0 includes features that only matter once Hermes is running in more than one place. Managed scope lets administrators pin user-immutable config and secrets from a root-owned /etc/hermes. Gateway multiplexing can run all profiles through one gateway process when enabled. A pluggable CronScheduler interface and Chronos managed-cron provider point toward scale-to-zero scheduling. Gateway-to-gateway relay work adds signed inbound paths and managed bootstrapping for connected Hermes deployments.

Those are not beginner features. They are signs that Hermes is preparing for managed deployments where one person or team operates multiple profiles and message surfaces with policy boundaries.

The security section is worth reading alongside those fleet features. The release closes a shell-escape denylist bypass, redacts secrets in request debug dumps, withholds host metadata from public status, blocks suspicious MCP stdio configs before probing them, sanitizes environment variables for cron job-script subprocesses, and fails closed on several approval and gateway policy paths. MCP also gains an elicitation handler so servers can ask for mid-tool-call confirmation on the surface that owns the session, whether that is CLI, TUI, Telegram, or Slack.

This is the less glamorous half of an agent runtime. The more channels and tools an agent can touch, the more important the refusal, approval, secret-handling, and configuration boundaries become.

What users should take from v0.17.0

Hermes Agent v0.17.0 is best understood as a reach release in the literal sense. It reaches into more messaging platforms, gives desktop users better visibility into delegated work, moves profile and skill setup into the dashboard, lets agents run subwork in the background, and adds controls that matter when Hermes is no longer just a terminal process on one machine.

The caveat is scope. The release notes are enormous: Nous reports roughly 1,475 commits, about 800 merged PRs, 1,693 changed files, more than 300 closed issues, and 245 contributors since v0.16.0. Those larger totals should be read as project-reported figures, since GitHub compare responses can be paged and release-note accounting may count merged PRs, generated files, co-author trailers, and contributor activity differently from a single compare view.

For operators already using Hermes as a daily agent, v0.17.0 is the release to inspect for workflow changes rather than a single feature to try. Background subagents reduce waiting. Photon and WhatsApp Cloud reduce bridge maintenance. The dashboard reduces config-file work. Managed scope and security fixes make multi-profile deployments less ad hoc. The release moves Hermes further away from “chat with tools” and closer to an agent runtime that can live where the work arrives.