Hermes Desktop hace operables los personal agents

Hermes Desktop da a Hermes una superficie de operador: chat, archivos, perfiles, cron, acceso gateway y remote backends en un solo lugar. La Hermes Desktop personal agent runtime ya tiene la capa de control que faltaba a los agents siempre activos.

La pregunta útil es más simple: ¿puede ver qué está haciendo el agent, qué rol está usando y cómo recuperarse cuando se rompe?

Por eso trataría Hermes Desktop como la noticia real, aunque las capturas parezcan una actualización de producto. Las partes útiles son los perfiles, un setup desktop apto para remote, el onboarding de Portal y la policy alrededor de local agents.

• Hermes Desktop es una superficie compartida sobre el mismo estado de agent. La documentación oficial dice que Desktop, CLI, TUI, dashboard y gateway reutilizan el mismo core setup en lugar de crear agents separados.

• Los perfiles son donde viven ahora los roles agent recurrentes. Separan config, `.env`, `SOUL.md`, memory, sessions, skills, cron jobs y gateway state, mientras que la aislamiento de filesystem aún necesita límites backend explícitos.

• Nous Portal elimina la dispersión de cuentas en el primer setup. Un flujo OAuth puede configurar model access y Tool Gateway access en lugar de pedir a los usuarios que conecten search, browser, image, TTS y sandbox tools uno por uno.

• La historia de local agents se está convirtiendo en una historia de seguridad. NVIDIA y Microsoft ya hablan de identity, containment, policy y OpenShell para agents que tocan su ordenador principal.

Qué cambió con Hermes Desktop

Hermes Desktop importa porque está construido alrededor del mismo Hermes Agent core que el terminal y el gateway. La documentación es explícita: la app comparte config, API keys, sessions, skills y memory con CLI, TUI y dashboard.

Eso da a Hermes otra forma. Un terminal agent puede ser útil para quienes ya viven en shells. Una app desktop con chat, file browser, preview rail, perfiles, skills, cron, messaging y Command Center hace que el agent sea inspeccionable para trabajo largo.

El detalle que me importa es la continuidad de estado. Puede empezar una session en una superficie Hermes y retomarla en otra porque las superficies hablan con el mismo agent state. Ahí Hermes empieza a sentirse menos como un comando de terminal y más como algo que realmente puede operar.

Si está convirtiendo un workflow agent recurrente en un proceso de negocio, el servicio AI automation de webvise es el encaje más cercano. El scope útil rara vez es la interfaz de chat. Es el límite del workflow, las credenciales, el review gate y el recovery path alrededor del agent.

Los perfiles son ahora los roles agent

Los perfiles Hermes son ahora el punto de partida más limpio para roles agent recurrentes. Un perfil es su propio Hermes home directory con su propia config, archivo de secrets, archivo de personality, memories, sessions, skills, cron jobs y state database.

Eso separa el estado lo suficiente para roles recurrentes. Un perfil research puede conservar hábitos de source review y browsing tools. Un perfil writer puede conservar reglas de draft y voice constraints.

Un perfil engineer puede conservar comandos de repo y hábitos de test. Cada uno puede ejecutar su propio gateway process y service name.

Esto cambió mis propias notas de setup el 8 y 9 de junio de 2026. Yo estaba pensando en cajas separadas para agents separados. Después de que los perfiles encajaran en la arquitectura real, el default más limpio pasó a ser una instalación Hermes, Desktop como superficie de operador y perfiles como división de roles.

La misma documentación también nombra el límite con claridad: los perfiles no aíslan el filesystem. Un local terminal backend sigue corriendo con el mismo acceso al filesystem que la cuenta de usuario. Si necesita una carpeta inicial predecible para trabajo de gateway y cron, configure `terminal.cwd` en Hermes config. Si necesita containment más fuerte, use un backend como Docker, SSH, Modal, Daytona o Singularity.

Aquí el primer artículo sobre perfiles Hermes sigue siendo válido. En nuestra guía de perfiles Hermes, la regla era simple: cree un perfil cuando un rol se repite y necesita memory, tools, gateway state o trabajo programado separados. Desktop hace esa regla más fácil de vivir porque el cambio de perfil ya es visible.

El setup que ahora tiene sentido

El setup que usaría hoy es una instalación Hermes en una máquina remota, Hermes Desktop conectado mediante Remote Gateway y perfiles como roles agent. Telegram u otro canal de mensajes debería apuntar normalmente a un perfil assistant. Ese assistant puede delegar a perfiles researcher, engineer, writer o reviewer mediante comandos explícitos o Kanban tasks.

Eso mantiene limpio el punto de entrada humano. Usted escribe a un assistant. El assistant enruta el trabajo a un perfil con la memory y los tools correctos. El trabajo largo se convierte en una tarea durable en lugar de desaparecer en un chat comprimido.

Yo mantendría una superficie de reparación fuera de Hermes. Mantenga una herramienta de reparación fuera de Hermes para logs, gateway restarts, config edits y profile wiring roto.

Si un equipo pidiera a webvise mapear esto, empezaría por la tabla de permisos antes de escribir skills. Nuestro trabajo de AI automation empieza a rendir cuando el owner, los tools, las credenciales y los review gates están lo bastante claros como para que una mala ejecución del agent sea visible de inmediato.

Portal elimina el caos de cuentas

La documentación oficial de Nous Portal llama a `hermes setup --portal` el camino de setup más rápido. Un flujo OAuth establece Nous como inference provider, deja que el usuario elija un model y activa el Tool Gateway.

Eso importa porque el setup agent suele fallar antes del primer workflow útil. Search necesita una cuenta. Browser automation necesita otra. Image generation, text-to-speech y terminal sandboxing añaden más keys, dashboards, saldos y failure points.

Portal agrupa acceso a 300+ models y un Tool Gateway para search y extract, image generation, text-to-speech, cloud browser sessions y un terminal sandbox opcional. La lista exacta de models cambiará. La dirección del producto es estable: Hermes intenta que el primer setup agent útil tome un comando en lugar de cinco cuentas de proveedores.

Portal también cambia dónde viven los secrets. La documentación dice que OAuth deja un refresh token en `~/.hermes/auth.json` y emite JWTs de corta vida por request, en lugar de llenar `.env` con una docena de API keys longevas. Es mejor higiene de setup, pero todavía necesita reglas por rol.

El trabajo serio sigue siendo decidir qué perfil posee qué credential, qué tool puede modificar datos y qué acción necesita review. Dé a los agents cuentas propias y API keys nombradas cuando pueda. Mantenga los secrets en config, `.env` o rutas de entorno de container, no en chat transcripts.

Los local agents necesitan policy antes que autonomía

Hermes Desktop llegó al mismo tiempo que la historia de hardware se volvió más ruidosa. En su post de RTX AI Garage, NVIDIA escribió que Hermes había superado 140,000 GitHub stars en menos de tres meses y que, en la semana previa, era el agent más usado en OpenRouter.

El 31 de mayo y el 2 de junio de 2026, Microsoft y NVIDIA publicaron el lado Windows de la misma historia. El post de Windows de Microsoft nombra identity, containment y manageability aplicados por el OS. El post developer de NVIDIA nombra Microsoft eXecution Containers, OpenShell, policy creation, inference routing y PII obfuscation.

Esa es la dirección correcta para Hermes. Un personal agent con file access, terminal access, browser access, memory, voice, cron y gateway routes termina tocando la misma máquina que usted usa para banca, código, documentos y cuentas de trabajo. La capability ya está aquí. Lo difícil es limitar quién puede leer archivos, gastar dinero, exponer secrets o cambiar producción.

La documentación de OpenShell formula la risk table con claridad: data exfiltration, credential theft, unauthorized API usage y privilege escalation. Ya argumentamos en el day-30 Hermes operator layer que handoff contracts y permission gates importan después de la primera demo. Desktop y los perfiles hacen esos gates más visibles. OpenShell y Windows policy primitives apuntan al siguiente límite: el operating system.

Cómo probar el setup esta semana

Empiece con una runtime y tres perfiles. Haga del perfil assistant la ruta humana por defecto. Haga que researcher y writer sean workers separados. Mantenga los secrets fuera del perfil writer.

La primera métrica de éxito es aburrida: ¿puede pedir al assistant un brief con fuentes, ver cómo enruta la tarea, inspeccionar el output y ver qué perfil tocó qué archivos o tools? Si sí, tiene una superficie de operador. Si la respuesta está escondida en un chat transcript, tiene una demo.

En webvise usamos este tipo de investigación de agent setup para decidir qué workflows merecen automation y cuáles deberían quedarse como reviewed tools. Un buen primer mapa es el proceso recurrente, los tools que toca y las acciones que dolerían si un agent las hiciera mal.