Hermes Cloud suma upgrades on-demand de CPU, RAM y disco

En pocas palabras: Hermes Cloud, la plataforma de agentes de Nous Research, ahora permite ampliar disco, CPU y RAM on-demand desde el portal en portal.nousresearch.com/cloud. Sigue en preview, sin SLA público, con escalado a cero: pagás solo el tiempo que el agente trabaja.

Nous Research mantiene Hermes Cloud, su plataforma de agentes IA, en preview. La propuesta es que puedas correr un agente sin migrar nada, sin tocar YAML y sin levantar un servidor: el agente sigue vivo, con su memoria intacta, y vos pagás solo el tiempo que trabaja.

Hermes Cloud es la plataforma de Nous Research para desplegar y correr agentes de IA autónomos en la nube, sin administrar infraestructura. Cada agente vive en su propio contenedor endurecido, funciona 24/7, escala a cero cuando está inactivo y conserva memoria persistente asociada al agente (no al dispositivo). Está en preview y se administra desde el portal en portal.nousresearch.com/cloud.

¿Por qué importa que el agente no dependa de la máquina?

Porque en un esquema tradicional, cuando un agente se te quedaba corto de RAM o de disco, la salida típica era rearmarlo en una instancia más grande y rezar para que el estado sobreviviera la mudanza. Con una plataforma administrada, el agente sigue siendo el mismo: mismo contenedor, misma identidad, misma memoria acumulada.

Y acá está lo que me parece más interesante de la propuesta, que no es una capacidad puntual sino la combinación: Hermes Cloud junta agentes IA en la nube con memoria que vive del lado del agente, y eso significa que el estado deja de estar atado a la instancia que lo atendió.

Ponele que armaste un agente que te resume tickets de soporte y te los manda por Slack a la mañana. Funciona bárbaro tres semanas, hasta que el equipo empieza a adjuntar PDFs de 40 páginas, el agente empieza a quedarse sin disco temporal, los jobs fallan en silencio, vos te enterás recién cuando alguien pregunta por qué no llegó el resumen y terminás debuggeando un problema que era, en el fondo, de capacidad. Ese es el tipo de escenario que una plataforma administrada busca sacarte de encima.

¿Qué define la capacidad de un agente y cómo se gestiona?

Todo se gestiona desde el portal de Hermes Cloud. La lógica de la plataforma es que no tocás infraestructura: elegís nombre y modelo, el agente queda online en segundos y a partir de ahí lo administrás desde la misma interfaz donde lo creaste. Sobre eso hablamos en gestión segura de secretos en infraestructura.

Ojo con un punto: la página oficial de Hermes Cloud no publica una grilla de tiers con números exactos de cores, GB de RAM y GB de disco por nivel. Prefiero decírtelo antes que inventarte una tabla de precios que después no coincide con lo que ves en el portal. Si necesitás la configuración exacta para dimensionar un proyecto, la fuente es tu propia cuenta o el mail de soporte que ellos mismos publican.

Lo que sí está confirmado por la documentación oficial, y es lo que define el comportamiento real de la plataforma:

• Contenedor aislado por agente: cada agente corre en su propio contenedor endurecido, así que lo que pase en uno no afecta a los demás.
• Subagentes en paralelo: podés levantar subagentes sin quemar el contexto del agente principal.
• Escala a cero: el agente vive 24/7 pero baja a cero cuando está ocioso, así que no te cobra mientras no lo usás.
• Memoria persistente: la memoria vive con el agente, no con el dispositivo.

¿Cómo funciona todo esto sin DevOps de por medio?

Funciona porque vos nunca ves la máquina. Nous Research describe el flujo así: “Pick a name and model, your agent is online in seconds. No servers, no DevOps, no YAML”, según el texto del portal oficial. Todo es una decisión de producto sobre un agente existente, no una operación de infraestructura sobre una VM.

El contraste con un VPS tradicional es directo. En un VPS, escalar significa apagar, redimensionar, verificar que el filesystem creció, reiniciar servicios y revisar que nada quedó apuntando al tamaño viejo. Acá no hay ninguno de esos pasos.

¿Es mejor eso siempre? No. Es mejor cuando tu problema es “quiero un agente corriendo ya”; es peor cuando necesitás control fino sobre el sistema operativo, versiones de librerías o compliance sobre dónde se guarda cada byte. Si tu caso es el segundo, un servidor administrado (por ejemplo en donweb.com) te sigue dando algo que una plataforma cerrada no: acceso real a la máquina.

¿La memoria del agente sobrevive entre sesiones y dispositivos?

Sí, y es la diferencia central con las arquitecturas serverless clásicas. La documentación de Nous Research dice que “la memoria vive con el agente, no con el dispositivo, y nunca olvida cómo resolvió un problema, desde donde sea que te loguees”. Eso implica que el estado no está atado a la sesión ni a la instancia que lo atendió.

El corolario práctico es lo multi-superficie. Un agente, una memoria, y las superficies que ya usás: Telegram, Discord, Slack, email y CLI. Si el agente aprendió algo resolviendo un ticket por Slack, ese aprendizaje está disponible cuando le escribís por Telegram. Para más detalles técnicos, mirá opciones de cloud hosting disponibles.

Sumale el scheduling en lenguaje natural, que según el portal corre “desatendido a través del gateway” para reportes, backups y briefings. Ahí es donde la capacidad se vuelve una necesidad concreta y no un lujo: un briefing diario que procesa mucha data necesita más músculo que un bot que responde preguntas sueltas.

¿Cómo se compara Hermes Cloud con las plataformas cloud generalistas?

La diferencia es de alcance: Hermes Cloud es una plataforma específica para agentes, mientras que las nubes generalistas te dan primitivas (funciones, contenedores, colas) con las que vos construís el agente. Esa especialización explica el “online en segundos” y también explica las limitaciones.

Dimensión	Hermes Cloud	Nube generalista (contenedores/serverless)
Unidad que desplegás	Un agente (nombre + modelo)	Una función, contenedor o servicio
Configuración necesaria	Ninguna: sin servidores, sin YAML	Manifiestos, IAM, redes, build pipeline
Memoria del agente	Persistente, atada al agente	La implementás vos (DB, vector store, cache)
Escalado a cero	Nativo, mientras está ocioso	Disponible en serverless, manual en VMs
Aislamiento	Un contenedor endurecido por agente	Lo configurás vos
Superficies de chat listas	Telegram, Discord, Slack, email, CLI	Las integrás vos
Madurez	Preview, sin SLA público	GA, con SLA contractual

Leela así: si tu proyecto es un agente y querés que funcione hoy, la plataforma especializada te ahorra semanas. Si tu proyecto es una arquitectura completa donde el agente es una pieza entre varias, las primitivas generalistas te van a dar más margen.

¿Cuándo el problema es de capacidad y cuándo no?

El cuello de botella es de capacidad cuando el agente se queda sin margen procesando adjuntos grandes, o cuando los subagentes en paralelo saturan la máquina. Si el agente es lento porque le pedís algo mal definido, más recursos no arreglan nada.

• Disco: agentes que descargan, generan o cachean archivos (reportes, backups, exports). Es el recurso que más rápido se agota y el más fácil de subestimar.
• CPU: cuando levantás subagentes en paralelo. La documentación oficial señala que cada agente puede spawnear subagentes en su contenedor, y eso compite por los mismos cores.
• RAM: workloads con contexto grande o muchos elementos en memoria a la vez. Si ves comportamiento errático bajo carga, mirá acá antes que a la CPU.

Un caso concreto: un agente de briefing diario que corre a las 7 AM, procesa fuentes, arma un resumen y lo manda por email. Ese perfil es picos cortos de mucha demanda y 23 horas de nada. Con escalado a cero, la ventana de trabajo es lo único que te sale caro. Otro caso, un bot de Discord que responde consultas todo el día: ahí el patrón es constante y de baja intensidad. Relacionado: estrategia multi-cloud para tus cargas de trabajo.

¿Cuánto cuesta Hermes Cloud y cómo se factura?

El modelo declarado por Nous Research es de consumo: el agente escala a cero cuando está ocioso y vos pagás mientras trabaja. Es la lógica opuesta a un servidor dedicado, donde pagás la capacidad reservada esté usándose o no.

Lo que no puedo darte, porque no está publicado en las fuentes oficiales que revisé: la tarifa por hora, por core o por GB. El portal describe el modelo, no la lista de precios. Cualquier número que veas dando vueltas en artículos de terceros, tomalo con pinzas hasta que salga de preview y publiquen pricing formal.

Y sí, “preview” también aplica al costo. Los precios de una plataforma en preview suelen cambiar cuando llega el GA.

Errores comunes al correr agentes en la nube

• Tapar un problema de prompt con más recursos: si el agente entra en loops o pide contexto de más, el gasto sube y el resultado no mejora. Medí primero dónde se va el tiempo.
• Asumir que “escala a cero” significa “gratis”: escala a cero aplica al cómputo ocioso. El almacenamiento persistente y la memoria del agente son otra cosa. Revisá qué se te factura mientras el agente duerme.
• Diseñar para preview como si fuera producción: el portal aclara que Hermes Cloud está en preview y pide reportar problemas a soporte. Meter un agente crítico de negocio ahí, sin plan B, es apostar a algo que no tiene SLA público.
• Ignorar el aislamiento entre agentes: como cada agente tiene su contenedor, lo que resuelvas en uno no se propaga a los otros. Si tenés cinco agentes chicos, cada uno se administra por separado.
• No aprovechar los subagentes: mucha gente infla el agente principal cuando la documentación sugiere spawnear subagentes en paralelo para no quemar contexto. A veces la solución es arquitectónica, no de hardware.

Preguntas Frecuentes

¿Qué es Hermes Cloud?

Hermes Cloud es la plataforma de Nous Research para desplegar agentes de IA autónomos en la nube sin gestionar servidores. Cada agente corre en un contenedor aislado, tiene memoria persistente y funciona 24/7, escalando a cero cuando está inactivo. Se administra desde portal.nousresearch.com/cloud y está en preview.

¿Dónde se consulta la configuración de un agente?

Desde el portal de la cuenta. Nous Research no publica una grilla de tiers en su página pública, así que las configuraciones exactas disponibles se ven ahí o se consultan al mail de soporte que ellos mismos publican. En prácticas DevOps en infraestructura en la nube profundizamos sobre esto.

¿Se pierde la memoria del agente entre sesiones?

No. La memoria está asociada al agente y no al dispositivo ni a la sesión, según la documentación oficial de Nous Research. El agente conserva cómo resolvió problemas anteriores independientemente de desde dónde te conectes.

¿Con qué plataformas de mensajería se integra?

Telegram, Discord, Slack, email y CLI. Es un mismo agente con una única memoria respondiendo en todas esas superficies, así que no necesitás desplegar una instancia por canal ni sincronizar estado entre ellas.

¿Hermes Cloud sirve para producción hoy?

Con reservas: la plataforma está en preview y el propio portal invita a reportar problemas a [email protected], sin publicar un SLA de disponibilidad. Para prototipos, automatizaciones internas y agentes no críticos anda bien; para cargas de negocio críticas conviene tener una alternativa lista.

Conclusión

Lo que propone Hermes Cloud es concreto: correr un agente sin redeploys ni infraestructura propia, con la memoria intacta. Para quien arma automatizaciones con agentes, eso saca de encima buena parte del trabajo de plomería.

Ahora, seamos honestos con el estado real: sigue en preview, no hay tabla de tiers pública, no hay pricing formal y no hay SLA. Mi recomendación práctica es entrar al portal, crear un agente con la configuración mínima, medir durante una semana con carga real y recién ahí decidir cómo seguir. Decidir sobre datos propios va a ser más barato que decidir por las dudas.

Fuentes

• Hermes Cloud – Portal oficial de Nous Research con las características y el estado de preview
• Documentación de Hermes Agent – Guía técnica oficial del agente
• Tencent Cloud Techpedia – Contexto técnico sobre plataformas cloud para agentes
• Infobae – Agentes autónomos y procesamiento avanzado en plataformas cloud