Hermes Desktop rende operativi i personal agents

Hermes Desktop dà a Hermes una superficie operatore: chat, file, profili, cron, gateway access e remote backends in un unico posto. La Hermes Desktop personal agent runtime ora ha il layer di controllo che mancava agli agents sempre attivi.

La domanda utile è più semplice: può vedere cosa sta facendo l'agent, quale ruolo sta usando e come recuperare quando si rompe?

Per questo tratterei Hermes Desktop come la vera notizia, anche se gli screenshot sembrano un aggiornamento prodotto. Le parti utili sono i profili, un desktop setup adatto al remote, l'onboarding Portal e la policy intorno ai local agents.

• Hermes Desktop è una superficie condivisa sullo stesso agent state. I docs ufficiali dicono che Desktop, CLI, TUI, dashboard e gateway riutilizzano lo stesso core setup invece di creare agents separati.

• I profili sono il posto in cui ora vivono i ruoli agent ricorrenti. Separano config, `.env`, `SOUL.md`, memory, sessions, skills, cron jobs e gateway state, mentre la filesystem isolation richiede ancora confini backend espliciti.

• Nous Portal rimuove la dispersione di account nel primo setup. Un flusso OAuth può impostare model access e Tool Gateway access invece di chiedere agli utenti di collegare search, browser, image, TTS e sandbox tools uno per uno.

• La storia dei local agents sta diventando una storia di sicurezza. NVIDIA e Microsoft parlano ora di identity, containment, policy e OpenShell per agents che toccano il Suo computer principale.

Cosa è cambiato con Hermes Desktop

Hermes Desktop conta perché è costruito intorno allo stesso Hermes Agent core del terminale e del gateway. I docs sono espliciti: l'app condivide config, API keys, sessions, skills e memory con CLI, TUI e dashboard.

Questo dà a Hermes una forma diversa. Un terminal agent può essere utile per chi vive già nelle shell. Una desktop app con chat, file browser, preview rail, profili, skills, cron, messaging e Command Center rende l'agent ispezionabile per lavori più lunghi.

Il dettaglio che mi interessa è la continuità dello stato. Può iniziare una session in una superficie Hermes e riprenderla altrove perché le superfici parlano con lo stesso agent state. È lì che Hermes inizia a sembrare meno un terminal command e più qualcosa che può davvero gestire.

Se sta trasformando un agent workflow ricorrente in un processo aziendale, il servizio AI automation di webvise è il fit più vicino. Lo scope utile raramente è la chat UI. È il confine del workflow, le credentials, il review gate e il recovery path intorno all'agent.

I profili ora sono i ruoli agent

I profili Hermes sono ora il punto di partenza più pulito per ruoli agent ricorrenti. Un profilo è la propria Hermes home directory con propria config, file secrets, file personality, memories, sessions, skills, cron jobs e state database.

Questo separa lo state abbastanza bene per ruoli ricorrenti. Un profilo research può conservare abitudini di source review e browsing tools. Un profilo writer può conservare draft rules e voice constraints.

Un profilo engineer può conservare repo commands e abitudini di test. Ognuno può eseguire il proprio gateway process e service name.

Questo ha cambiato le mie note di setup l'8 e il 9 giugno 2026. Stavo pensando in scatole separate per agents separati. Dopo che i profili sono entrati nell'architettura reale, il default più pulito è diventato una installazione Hermes, Desktop come superficie operatore e profili come divisione dei ruoli.

Gli stessi docs nominano anche il confine chiaramente: i profili non sandboxano il filesystem. Un local terminal backend gira ancora con lo stesso filesystem access dell'account utente. Se Le serve una cartella iniziale prevedibile per il lavoro gateway e cron, imposti `terminal.cwd` nella Hermes config. Se Le serve containment più forte, usi un backend come Docker, SSH, Modal, Daytona o Singularity.

Qui il primo articolo sui profili Hermes regge ancora. Nella nostra guida ai profili Hermes, la regola era semplice: crei un profilo quando un ruolo si ripete e ha bisogno di memory, tools, gateway state o lavoro schedulato separati. Desktop rende quella regola più facile da vivere perché lo switch di profilo ora è visibile.

Il setup che ora ha senso

Il setup che userei oggi è una installazione Hermes su una macchina remota, Hermes Desktop collegato via Remote Gateway e profili come ruoli agent. Telegram o un altro canale di messaggi dovrebbe di solito puntare a un profilo assistant. Quell'assistant può delegare a profili researcher, engineer, writer o reviewer tramite commands espliciti o Kanban tasks.

Questo tiene pulito il punto di ingresso umano. Lei scrive a un assistant. L'assistant instrada il lavoro a un profilo con la memory e i tools corretti. Il lavoro più lungo diventa un task durevole invece di sparire in una chat compressa.

Terrei comunque una superficie di riparazione fuori da Hermes. Mantenga uno strumento di riparazione fuori da Hermes per logs, gateway restarts, config edits e profile wiring rotto.

Se un team chiedesse a webvise di mappare questo, inizierei dalla tabella delle permissions prima di scrivere skills. Il nostro lavoro di AI automation inizia a rendere quando owner, tools, credentials e review gates sono abbastanza chiari da rendere visibile subito un agent run sbagliato.

Portal rimuove il caos degli account

I docs ufficiali di Nous Portal chiamano `hermes setup --portal` il percorso di setup più rapido. Un flusso OAuth imposta Nous come inference provider, fa scegliere un model all'utente e attiva il Tool Gateway.

Questo conta perché l'agent setup spesso fallisce prima del primo workflow utile. Search richiede un account. Browser automation ne richiede un altro. Image generation, text-to-speech e terminal sandboxing aggiungono altre keys, dashboards, balances e failure points.

Portal raggruppa accesso a 300+ models e un Tool Gateway per search ed extract, image generation, text-to-speech, cloud browser sessions e una terminal sandbox opzionale. La lista esatta dei models cambierà. La direzione prodotto è stabile: Hermes sta provando a far richiedere al primo setup agent utile un command invece di cinque vendor accounts.

Portal cambia anche dove vivono i secrets. I docs dicono che OAuth lascia un refresh token in `~/.hermes/auth.json` e conia JWTs brevi per request, invece di riempire `.env` con una dozzina di API keys longeve. È una migliore igiene di setup, ma richiede comunque regole a livello di ruolo.

Il lavoro serio resta decidere quale profilo possiede quale credential, quale tool può modificare dati e quale azione richiede review. Dia agli agents account propri e API keys nominate quando può. Tenga secrets in config, `.env` o container environment paths, non nei chat transcripts.

I local agents hanno bisogno di policy prima dell'autonomia

Hermes Desktop è arrivato nello stesso momento in cui la storia hardware si è fatta più rumorosa. Nel suo post RTX AI Garage, NVIDIA ha scritto che Hermes aveva superato 140,000 GitHub stars in meno di tre mesi ed era, nella settimana precedente, l'agent 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 nomina identity, containment e manageability applicati dall'OS. Il post developer di NVIDIA nomina Microsoft eXecution Containers, OpenShell, policy creation, inference routing e PII obfuscation.

Questa è la direzione giusta per Hermes. Un personal agent con file access, terminal access, browser access, memory, voice, cron e gateway routes finisce per toccare la stessa macchina che Lei usa per banca, codice, documenti e account di lavoro. La capability è già qui. La parte dura è limitare chi può leggere file, spendere denaro, esporre secrets o cambiare production.

I docs OpenShell formulano chiaramente la risk table: data exfiltration, credential theft, unauthorized API usage e privilege escalation. Abbiamo già sostenuto nel day-30 Hermes operator layer che handoff contracts e permission gates contano dopo la prima demo. Desktop e profili rendono quei gates più visibili. OpenShell e Windows policy primitives indicano il prossimo confine: l'operating system.

Come provare il setup questa settimana

Inizi con una runtime e tre profili. Renda il profilo assistant la rotta umana di default. Renda researcher e writer worker separati. Tenga secrets fuori dal profilo writer.

La prima metrica di successo è noiosa: può chiedere all'assistant un brief source-backed, vedere come instrada il task, ispezionare l'output e vedere quale profilo ha toccato quali file o tools? Se sì, ha una superficie operatore. Se la risposta è nascosta in un chat transcript, ha una demo.

In webvise usiamo questo tipo di agent setup research per decidere quali workflows meritano automation e quali dovrebbero restare reviewed tools. Una buona prima mappa è il processo ricorrente, i tools che tocca e le azioni che farebbero male se un agent le eseguisse male.