Hermes Desktop offre a Hermes una superficie operativa: chat, file, profili, cron, accesso ai gateway e backend remoti in un unico posto. Il runtime per agenti personali di Hermes Desktop dispone ora del layer di controllo che mancava agli agenti sempre attivi.
La domanda utile è più semplice: è possibile vedere cosa sta facendo l'agente, quale ruolo sta usando e come ripristinare il funzionamento quando si interrompe?
Per questo considero Hermes Desktop la vera novità, anche se gli screenshot sembrano un aggiornamento di prodotto. Le parti rilevanti sono i profili, una configurazione desktop adatta ai backend remoti, l'onboarding tramite Portal e le policy per gli agenti locali.
- Hermes Desktop è una superficie condivisa sullo stesso stato dell'agente. La documentazione ufficiale indica che Desktop, CLI, TUI, dashboard e gateway riutilizzano la stessa configurazione di base anziché creare agenti separati.
- I profili sono ora la sede dei ruoli agentivi ricorrenti. Separano configurazione, `.env`, `SOUL.md`, memoria, sessioni, skill, cron job e stato del gateway, mentre l'isolamento del filesystem richiede ancora espliciti confini di backend.
- Nous Portal elimina la proliferazione di account al primo avvio. Un singolo flusso OAuth configura l'accesso al modello e al Tool Gateway, invece di richiedere all'utente di collegare uno per uno strumenti di ricerca, browser, generazione immagini, TTS e sandbox.
- La gestione degli agenti locali sta diventando una questione di sicurezza. NVIDIA e Microsoft parlano ora di identità, contenimento, policy e OpenShell per gli agenti che operano sul computer principale.
Cosa è cambiato con Hermes Desktop
Hermes Desktop è importante perché è costruito attorno allo stesso core di Hermes Agent del terminale e del gateway. La documentazione è esplicita: l'app condivide configurazione, chiavi API, sessioni, skill e memoria con CLI, TUI e dashboard.
Questo conferisce a Hermes una forma diversa. Un agente da terminale può essere utile per chi vive già nelle shell. Un'app desktop con chat, esplorazione file, preview rail, profili, skill, cron, messaggistica e Command Center rende l'agente ispezionabile per lavori più lunghi.
Il dettaglio che conta è la continuità dello stato. È possibile avviare una sessione in una superficie Hermes e riprenderla altrove, perché le superfici comunicano con lo stesso stato dell'agente. È il momento in cui Hermes inizia a sembrare qualcosa che si può davvero usare attraverso più superfici.
Per chi trasforma un workflow agentivo ricorrente in un processo aziendale, il servizio di AI automation di webvise è la soluzione più adatta. Lo scope utile riguarda raramente l'interfaccia chat: sono il confine del workflow, le credenziali, il gate di revisione e il percorso di ripristino attorno all'agente.
| Layer | Cosa Hermes espone ora | Perché è rilevante |
|---|---|---|
| Desktop | Chat, file browser, preview rail, impostazioni, profili, skill, cron, messaggistica, Command Center | L'operatore può ispezionare e guidare il lavoro senza ricorrere a terminali sparsi. |
| Profili | Directory home separate con configurazione, `.env`, `SOUL.md`, memorie, sessioni, skill, cron job e database di stato | Un ruolo ricorrente può mantenere la propria cronologia, gli strumenti e lo stato del gateway. |
| Portal | Un unico flusso OAuth per l'accesso al modello e al Tool Gateway | La configurazione passa da molti account API a un unico punto di accesso gestito. |
| Direzione OpenShell | Identità, contenimento, policy, routing locale e mascheramento delle informazioni personali | Gli agenti personali necessitano di limiti prima di operare tutto il giorno sul computer principale. |
I profili sono i ruoli dell'agente
I profili di Hermes sono ora il punto di partenza più pulito per i ruoli agentivi ricorrenti. Un profilo è una directory home Hermes autonoma con configurazione, file dei segreti, file di personalità, memorie, sessioni, skill, cron job e database di stato.
Questa separazione è sufficiente per i ruoli ricorrenti. Un profilo di ricerca può mantenere abitudini di revisione delle fonti e strumenti di navigazione. Un profilo per la scrittura può conservare regole di bozza e vincoli di stile.
Un profilo per lo sviluppo può mantenere comandi di repository e abitudini di test. Ognuno può eseguire il proprio processo gateway e nome del servizio.
Questo ha cambiato le mie note di configurazione l'8 e il 9 giugno 2026. Stavo ragionando in termini di ambienti separati per agenti separati. Dopo che i profili sono entrati nell'architettura reale, il default più pulito è diventato una singola installazione Hermes, Desktop come superficie operativa e i profili come separazione dei ruoli.
La stessa documentazione indica anche il confine con chiarezza: i profili non isolano il filesystem. Un backend terminale locale continua a funzionare con lo stesso accesso al filesystem dell'account utente. Se serve una cartella di avvio prevedibile per il lavoro di gateway e cron, impostare `terminal.cwd` nella configurazione Hermes. Per un contenimento più robusto, usare un backend come Docker, SSH, Modal, Daytona o Singularity.
È qui che il primo articolo sui profili Hermes regge ancora. Nella guida ai profili Hermes, la regola era semplice: creare un profilo quando un ruolo si ripete e necessita di memoria separata, strumenti, stato del gateway o lavoro pianificato. Desktop rende quella regola più facile da applicare, perché il cambio di profilo è ora visibile.
La configurazione che ha senso oggi
La configurazione da adottare oggi è una singola installazione Hermes su una macchina remota, Hermes Desktop connesso tramite Remote Gateway e i profili come ruoli dell'agente. Telegram o un altro canale di messaggistica dovrebbe puntare di norma a un unico profilo assistente, che può delegare ai profili di ricercatore, sviluppatore, scrittore o revisore tramite comandi espliciti o task Kanban.
Questo mantiene il punto di ingresso umano pulito. Si invia un messaggio a un assistente. L'assistente instrada il lavoro al profilo con la memoria e gli strumenti giusti. Il lavoro più lungo diventa un task duraturo invece di scomparire in una singola chat compressa.
Conviene mantenere una superficie di riparazione esterna a Hermes: uno strumento di ripristino dedicato per log, riavvii del gateway, modifiche alla configurazione e problemi di cablaggio dei profili.
| Componente | Proprietario | Funzione |
|---|---|---|
| Desktop | Operatore umano | Ispezionare sessioni, file, stato dei profili, impostazioni, skill, cron e routing del gateway. |
| Profilo assistente | Ruolo Hermes rivolto alla chat | Ricevere richieste da Telegram o Desktop, chiarire l'obiettivo, instradare il lavoro. |
| Profilo ricercatore | Ruolo Hermes rivolto alle fonti | Leggere documentazione, pagine web, issue GitHub e restituire note supportate da fonti. |
| Profilo scrittore | Ruolo Hermes per la stesura | Trasformare le note approvate in bozze senza detenere segreti o accesso alla shell. |
| Profilo revisore | Ruolo Hermes per la sicurezza | Verificare affermazioni, permessi, credenziali e handoff rischiosi. |
| Superficie di amministrazione indipendente | Layer di riparazione | Correggere il runtime quando la configurazione dell'agente stessa si interrompe. |
| Scelta | Quando usarla | Da non usare per |
|---|---|---|
| Desktop su runtime locale | Si desidera un agente personale sulla macchina già in uso. | Operazioni sul filesystem rischiose senza sandbox. |
| Desktop più Remote Gateway | Si desidera l'interfaccia in locale e il runtime Hermes su una macchina remota. | Mascherare permessi di profilo deboli. |
| Profili | I ruoli necessitano di memoria, strumenti, cron, credenziali o stato del gateway separati. | Isolamento a livello di sistema operativo. |
| Backend Docker, SSH, Modal, Daytona o Singularity | Un profilo necessita di un confine di esecuzione più robusto. | Correggere un contratto di handoff vago. |
| Primitive OpenShell o degli agenti Windows | Gli agenti locali accedono a file, credenziali, app o routing del modello su un computer principale. | Saltare la revisione umana per azioni ad alto rischio. |
Se un team chiedesse a webvise di mappare questo, si partirebbe dalla tabella dei permessi prima di scrivere qualsiasi skill. Il lavoro di AI automation comincia a dare risultati quando proprietario, strumenti, credenziali e gate di revisione sono abbastanza chiari da rendere immediatamente visibile un'esecuzione sbagliata dell'agente.
Portal elimina il problema degli account
La documentazione ufficiale di Nous Portal indica `hermes setup --portal` come il percorso di configurazione più rapido. Un singolo flusso OAuth imposta Nous come provider di inferenza, permette all'utente di scegliere un modello e attiva il Tool Gateway.
Questo è rilevante perché la configurazione degli agenti fallisce di solito prima del primo workflow utile. La ricerca richiede un account. L'automazione del browser ne richiede un altro. Generazione di immagini, text-to-speech e sandboxing del terminale aggiungono altre chiavi, dashboard, saldi e punti di errore.
Portal raggruppa l'accesso a oltre 300 modelli e un Tool Gateway per ricerca ed estrazione, generazione di immagini, text-to-speech, sessioni browser cloud e un sandbox terminale opzionale. L'elenco esatto dei modelli cambierà. La direzione del prodotto è stabile: Hermes punta a far richiedere la prima configurazione utile un solo comando invece di cinque account vendor.
Portal cambia anche dove risiedono i segreti. La documentazione indica che OAuth lascia un token di aggiornamento in `~/.hermes/auth.json` e conia JWT a breve durata per ogni richiesta, invece di riempire `.env` con decine di chiavi API a lunga durata. Una migliore igiene di configurazione, che richiede comunque regole a livello di ruolo.
Il lavoro serio resta decidere quale profilo possiede quale credenziale, quale strumento può modificare i dati e quale azione necessita di revisione. Assegnare agli agenti account nominati e chiavi API nominate dove possibile. Conservare i segreti nella configurazione, in `.env` o nei percorsi di ambiente del container, mai nelle trascrizioni della chat.
Gli agenti locali necessitano di policy prima dell'autonomia
Hermes Desktop è arrivato nello stesso momento in cui la storia dell'hardware si è fatta più rumorosa. Nel post RTX AI Garage, NVIDIA ha scritto che Hermes aveva superato i 140.000 star su GitHub in meno di tre mesi ed era, nella settimana precedente, l'agente più usato su OpenRouter.
Il 31 maggio e il 2 giugno 2026, Microsoft e NVIDIA hanno pubblicato il lato Windows della stessa storia. Il post Windows di Microsoft menziona identità applicata dal sistema operativo, contenimento e gestibilità. Il post per sviluppatori di NVIDIA cita Microsoft eXecution Containers, OpenShell, creazione di policy, routing dell'inferenza e offuscamento PII.
È la direzione giusta per Hermes. Un agente personale con accesso a file, terminale, browser, memoria, voce, cron e route del gateway finisce per toccare la stessa macchina usata per banking, codice, documenti e account di lavoro. La capacità è già qui. La parte difficile è limitare chi può leggere file, spendere denaro, esporre segreti o modificare la produzione.
La documentazione di OpenShell espone la tabella dei rischi con chiarezza: esfiltrazione di dati, furto di credenziali, utilizzo non autorizzato di API e escalation dei privilegi. Già nell'articolo sul layer operativo Hermes al giorno 30 si sottolineava che contratti di handoff e gate di permessi contano dopo il primo demo. Desktop e profili rendono quei gate più visibili. OpenShell e le primitive di policy Windows indicano il confine successivo: il sistema operativo.
Come provare la configurazione questa settimana
Iniziare con un runtime e tre profili. Impostare il profilo assistente come percorso predefinito verso l'utente. Creare ricercatore e scrittore come worker separati. Tenere i segreti fuori dal profilo scrittore.
| Passo | Comando o azione | Verifica |
|---|---|---|
| Creare un profilo ricercatore | `hermes profile create researcher --description "Reads docs and returns source-backed notes."` | Il profilo ha il proprio `SOUL.md`, memoria, skill e sessioni. |
| Creare un profilo scrittore | `hermes profile create writer --description "Turns approved notes into drafts."` | Il profilo non ha shell o credenziali private non necessarie. |
| Impostare una cartella di progetto | `hermes config set terminal.cwd /absolute/path/to/project` | Le chiamate del gateway e dei tool cron partono da una directory prevedibile. |
| Connettere Desktop a un backend remoto | Eseguire `hermes dashboard` sul VPS e connettere Desktop tramite Remote Gateway. | Desktop può vedere sessioni e stato dei profili dal runtime remoto. |
| Mantenere un layer di riparazione | Usare una superficie di amministrazione esterna a Hermes. | È possibile risolvere problemi di dashboard, gateway e configurazione quando Hermes stesso è in errore. |
| Scrivere una regola di permesso | Elencare quale profilo può leggere file, chiamare API, scrivere bozze, eseguire comandi shell o spendere denaro. | Ogni azione ad alto rischio ha un proprietario e un gate di revisione. |
| Verificare i tempi della memoria | Trattare la memoria integrata come contesto di avvio sessione. | Le scritture di memoria a metà sessione diventano contesto affidabile alla sessione successiva, non immediatamente. |
La prima metrica di successo è semplice: si riesce a chiedere all'assistente un briefing supportato da fonti, osservare l'instradamento del task, ispezionare l'output e vedere quale profilo ha toccato quali file o strumenti? Se la risposta è sì, si dispone di una superficie operativa. Se la risposta è nascosta in una trascrizione di chat, si ha un demo.
In webvise, questo tipo di ricerca sulla configurazione degli agenti determina quali workflow meritano automazione e quali dovrebbero restare come strumenti revisionati. Una buona prima mappa è il processo ricorrente, gli strumenti che tocca e le azioni che farebbero danni se un agente le eseguisse in modo errato.
Le pratiche di webvise sono allineate agli standard ISO 27001 e ISO 42001.