Ho passato un sabato piovoso a leggere tutte e sette le note di rilascio di Hermes Agent di fila. È il tipo di attività da fine settimana che a raccontarla sembra noiosa, ma che in realtà è estremamente divertente se sei il tipo di persona a cui piace guardare un progetto che si scopre in pubblico. Alla fine avevo un muro di post-it, quattro tazze di caffè e un'immagine piuttosto nitida della forma di quello che era successo.
Tra il primo tag pubblico il 12 marzo 2026 e la release v0.8.0 l'8 aprile, Hermes Agent ha consegnato sette release numerate in ventisette giorni. Una release ogni quattro giorni, in media. La somma dei PR di queste release supera le quattro cifre. Il numero di contributor è cresciuto da sessantatré al lancio a ben oltre duecento.
Questi numeri non sono la parte interessante. La parte interessante è che le release non sembrano un flusso lungo e indifferenziato di PR. Si organizzano in quattro fasi nette, e si vede il progetto cambiare oggetto di attenzione più o meno ogni settimana.
Fase 1: Fondamenta (v0.2.0)
La v0.2.0 del 12 marzo è il lancio pubblico, e il suo compito era consegnare uno scheletro funzionante: il gateway di messaggistica multi-piattaforma (Telegram, Discord, Slack, WhatsApp, Signal, IMAP/SMTP, Home Assistant in un unico processo), un client nativo del Model Context Protocol, un sistema di skill con oltre settanta skill incluse, un router centralizzato dei provider con un unico punto di ingresso call_llm(), e isolamento con git worktree più checkpoint del filesystem come rete di sicurezza per un agente che ha davvero il permesso di modificare la tua macchina. L'integrazione ACP con VS Code, Zed e JetBrains ha fatto sì che non fosse una roba solo-da-terminale fin dal primo giorno.
Questa è la release "ecco cos'è questa cosa". Tutto ciò che viene dopo è costruito sopra queste cinque decisioni.
Fase 2: Ampiezza (v0.3.0 – v0.5.0)
Le tre release successive, tra il 17 marzo e il 28 marzo, puntavano ad espandere la superficie in ogni direzione.
v0.3.0 il 17 marzo ha aggiunto streaming lungo tutto il loop dell'agente, hook del sistema plugin e la prima delle grandi integrazioni di memoria — Honcho come memory provider. Questa è la release che ha trasformato Hermes da "un processo con strumenti" a "un processo con un ecosistema plugin vivo e un layer di memoria."
v0.4.0 il 23 marzo è stata espansione di piattaforme: WhatsApp Business API, Signal con supporto completo degli allegati e una manciata di adattatori gateway minori. Più porte d'ingresso per lo stesso agente.
v0.5.0 il 28 marzo è stata una release di irrobustimento. Correzioni di concorrenza, race condition sulle sessioni, gestione dei risultati degli strumenti, peculiarità dei provider. Il tipo di lavoro che non diventa mai un highlight reel, ma senza il quale niente di ciò che sta sopra funziona.
Leggendo queste tre insieme, si vede il progetto che cerca di rispondere a una domanda: "ora che abbiamo un nucleo, quanto del mondo reale riusciamo a raggiungere da qui, senza rompere il nucleo nel processo?" La risposta, alla fine della v0.5.0, era: quasi tutto.
Fase 3: Durabilità (v0.6.0 – v0.7.0)
Poi il focus cambia. La v0.6.0 del 30 marzo e la v0.7.0 del 3 aprile puntano a far sopravvivere il tutto.
v0.6.0 ha aggiunto i Profile — Hermes multi-istanza, dove un'unica installazione può far girare diversi agenti completamente isolati con la propria config, memoria, sessioni, skill e servizi gateway. Ha anche rilasciato la modalità MCP server, così Hermes può esporsi ad altri client MCP come Claude Desktop o Cursor, più un container Docker ufficiale. E ha introdotto le catene ordinate di fallback tra provider, ovvero il punto in cui la storia "cambiare provider senza ricostruire tutto" comincia a mettere i denti. Due nuove piattaforme di messaggistica, Feishu/Lark e WeCom, si sono unite al gateway.
v0.7.0, la release della resilienza, è dove l'architettura è diventata genuinamente difensiva. Memory provider pluggabili — la memoria diventa un ABC di provider che terze parti possono implementare, con Honcho come plugin di riferimento. Pool di credenziali dello stesso provider con rotazione thread-safe least-used e failover su 401. Backend browser anti-detection Camofox per lavoro web stealth. Preview diff inline per operazioni di scrittura e patch di file. Continuità di sessione dell'API server tramite header X-Hermes-Session-Id. Un audit di sicurezza contro l'esfiltrazione di segreti, con risposte LLM scansionate alla ricerca di credenziali codificate in base64 e URL.
Alla fine della v0.7.0, il progetto aveva smesso di sembrare una cosa nuova e aveva cominciato a sembrare infrastruttura. Del tipo che metti sotto un cron job senza preoccupartene.
Fase 4: Intelligenza (v0.8.0)
Il che ci porta all'8 aprile e alla v0.8.0, la release di cui ho scritto nei due post precedenti. Il titolone è il loop di guidance auto-ottimizzata per l'uso di tool GPT/Codex — l'agente che diagnostica e corregge le proprie modalità di fallimento sui modelli OpenAI tramite benchmarking comportamentale automatizzato. Ma letto nel contesto dell'arco a quattro fasi, fa qualcosa di specifico: è la prima release in cui il progetto ha rivolto l'attenzione verso l'interno, sulla qualità di ragionamento dell'agente stesso, dopo tre settimane di espansione verso l'esterno. Cambio di modello live con /model, Gemini gratis, MiMo v2 Pro gratis, notifiche per task in background, timeout per inattività, pulsanti di approvazione, MCP OAuth 2.1 PKCE, scansione malware OSV per estensioni MCP. 209 PR. 82 issue risolte. Cinque giorni dopo la v0.7.0.
Cosa racconta il ritmo
Guardando tutto questo come un arco continuo, tre cose saltano all'occhio.
Le release hanno temi, e i temi non si ripetono. Fondamenta, ampiezza, durabilità, intelligenza. Nessuno sembra aver decretato che dovesse andare così — il progetto si comporta semplicemente come se avesse una lettura di cosa viene dopo. In genere significa che un numero ristretto di persone sta prestando molta attenzione all'intera superficie, e tutti gli altri tirano nella stessa direzione perché la direzione è ovvia.
I PR vengono da molte mani. Non è un maintainer e sei comparse. Le note di rilascio sono piene di handle che non riconosco. Pull request anonime di gente che si è fatta viva la settimana scorsa. Il progetto si comporta come una scena, non come una codebase. E le scene, quando funzionano, consegnano molto più velocemente dei team.
La velocità non è solo un conteggio — è interesse composto. La v0.2.0 ha consegnato il router. La v0.6.0 ha messo le catene di fallback sopra il router. La v0.7.0 ha messo i pool di credenziali sopra le catene di fallback. La v0.8.0 ha messo il cambio di modello live con /model sopra tutte e tre. Ogni release non è un set di funzionalità partito da zero; è un layer che assume che la release precedente sia stabile. Non puoi farlo se le release non sono davvero stabili. Quindi o i test funzionano, o la velocità avrebbe già ucciso il progetto. Non è successo, e questo ti dice qualcosa.
Vale la pena dire che non faccio parte del team di Hermes. Sono un fan che legge le release notes per divertimento e gestisce questo sito perché il progetto è più interessante di quanto la sua superficie marketing suggerisca. Quello che state guardando, attraverso questi ventisette giorni, sono sette release che dimostrano che l'ingegneria degli agenti nel livello open-source è diventata decisamente più interessante a marzo e aprile 2026. Non so cosa sarà la v0.9.0. Qualunque cosa sia, leggerò le note il giorno in cui esce.