まとめ

Hermes Agentの2026年6月中旬から8月上旬までの更新は、単なる機能追加として読むより、設計対象が広がったと見るほうが分かりやすい。
以前の中心は、CLIやメッセンジャーから呼び出せる個人向けAgentだった。
直近の流れでは、非同期worker、永続delivery、外部Agent連携、webhook、検証、音声、Desktop workbenchまでを含む、常駐Agent runtimeへ近づいている。

特に重要なのはSubagent周辺である。
v0.17でbackground実行、v0.18でfan-out、v0.19でlive transcriptとdurable completionが入り、v0.20ではA2A、webhook、mid-turn redirect、context compression、tool self-recoveryが重なった。
これは「別のLLMに仕事を振る」から、長時間動くjob systemに近いものへ寄っている。

一方で、機能の存在と実運用品質は分けて考えたほうがよい。
A2A、Smart Approval、grounded citations、multi-profile routing、Voiceなどは、実装されたこと自体は大きい。
ただし、実際の運用でどこまで安定し、どのfailure modeが残るかは、別途小さく検証する価値が高い。

Subagentはworker modelへ寄っている

直近2か月の更新で最も筋が通っているのは、Subagentの進化である。
流れだけを抜き出すと、かなり段階的だ。

この積み上げは、単なるmulti-agent機能とは少し違う。
LLMが別LLMを呼ぶだけなら、失敗時の結果消失、途中状態の不透明さ、親会話のblock、restart時の消失がすぐ問題になる。
Hermesはそこに対して、background実行、並列化、transcript、ledger、deliveryというruntime側の部品を足している。

この方向は、長めの調査や実装ではかなり効く。
たとえば複数案の比較、独立したコードレビュー、広めのリサーチをSubagentへ分け、親Agentはユーザーとの対話や統合判断を続けられる。
完了後に結果が戻り、しかもprocess restartをまたいでも失われにくいなら、Agentを短い同期会話だけで使う必要が薄くなる。

ただし、長く走れることは常に良いことではない。
default tool iteration limitが90から500へ増えたことも含め、成功率と同時にtoken cost、外部API cost、破壊的操作、失敗loopのリスクも大きくなる。
Subagentの強化は、Smart Approvalやcompletion verificationとセットで評価すべきだ。

Gatewayは「届いたか」と「外とつながるか」を扱い始めた

Discord、Slack、Telegramのようなメッセージング環境でAgentを常駐させる場合、重要なのはモデルが答えを生成したかだけではない。
その返答が本当にユーザーへ届いたかが別の問題になる。

v0.19のdelivery-obligation ledgerは、この差を明示的に扱う変更だ。
最終応答を生成したあと、platform deliveryが確認される前にGatewayが落ちると、従来は「生成済みだが未配送」という嫌な状態が起きうる。
ledgerに配送義務を残しておけば、restart後に再配送できる。

この変更は、Hermesを単なるchat botではなくサービスとして運用する場合に本質的である。
常駐Agentでは、LLMの品質よりも先に、restart、network fault、platform API失敗、重複送信、未配送のような運用上のfailure modeが問題になる。
Hermesはその層へかなり踏み込んできた。

さらにv0.19では、一つのGatewayで複数profileをroutingできるようになった。
同じbot tokenを使いながら、guild、channel、threadごとにconfig、memory、skills、secretsを分ける方向である。
個人用、検証用、作業用を一つのGatewayに載せたい場合、この分離はかなり重要になる。

A2AとWebhookで外部システムへ開いた

v0.20のA2A v1.0とsigned outbound webhookは、Hermesの位置付けを変える更新である。
A2Aは外部Agentと話すための層で、Webhookは通常の外部システムへイベントを送るための層だ。

この二つは似ているようで、かなり違う。
A2Aは異なるAgent runtimeとの相互運用であり、Hermes内部のSubagentとは別物である。
WebhookはCI、監視、dashboard、社内automationのような通常システムに、Hermesの活動をeventとして流すための仕組みである。

ここまで来ると、Hermesは一つのアプリというより、既存の開発環境やメッセージング環境に差し込むAgent componentに近い。
MCPでtoolを増やし、Gatewayで人間の入口を持ち、A2Aで他Agentとつながり、Webhookで外部システムへ通知する。
この組み合わせは、個人利用よりも少し大きいAgent運用を考えると面白い。

CodingとResearchは「検証」に寄っている

v0.18以降のCoding Agent強化で重要なのは、完了条件をモデルの自己申告にしない方向である。
/goal のcompletion contract、verification evidence、pre-verify hookは、Agentが「できました」と言っただけで終わらせないための仕組みだ。
これはCoding Agentでは特に重要で、実際にtestやlintや確認commandを走らせたかが成果物の信頼性を左右する。

v0.20では、CLI側にも実務的な改善が入っている。
!command、/init、/diff、/context、/focus、mid-turn redirect、tool self-recoveryなどは、派手な新機能というより、長い作業で人間が観測し、介入し、失敗から戻るための道具である。
Coding Agentの使いやすさは、モデル性能だけでなく、こうした操作面でかなり決まる。

Research側ではgrounded citationsとfact-checkingが同じ思想に見える。
URLを添えるだけではなく、claimとsourceを対応させ、quoteが実際のpage textにあるかを確認し、verified、disproved、unverifiedを分ける。
Codingでtestを回すのと同じように、Researchでもevidenceを出力後に検証する方向へ寄っている。

まず実機で見るべきポイント

今回の更新は大きいが、全部を一度に試す必要はない。
価値が大きく、不確実性も大きいところから小さく見るのがよい。

特にSubagent durabilityとGateway delivery ledgerは、HermesをDiscordなどで常駐させるなら先に見る価値が高い。
ここが安定しているかどうかで、Hermesを「たまに呼ぶCLI」ではなく「任せておける常駐Agent」として扱えるかが変わる。

現時点の評価として、Hermes Agentの直近更新は、Coding Agentだけを強くする流れではない。
Personal Agent、Coding Agent、Research Agent、Messenger Bot、Automation Agentを、一つの永続runtimeへ寄せていく流れである。
その意味で、v0.17からv0.20までの本質は、機能の数ではなく、Agentが長く動き、外とつながり、検証され、届くところまで面倒を見る設計へ進んだことにある。

主要参照先

• Hermes Agent repository
• Hermes Agent releases
• v0.17.0 Reach Release
• v0.18.0 Judgment Release
• v0.19.0 Quicksilver Release
• v0.20.0 Herald Release