Cómo correr un agente de IA gratis en tu VPS con Hermes

Tengo un agente de IA corriendo 24/7 en un VPS que ya estaba pagando y casi no usaba. Me manda un resumen de noticias de IA y software todas las mañanas por Telegram. Busca en Reddit gente que tiene el problema que yo resuelvo. Y me cuesta cero dólares por mes además del servidor. No es un trial, no es un saldo de créditos que se acaba la semana que viene. Cero, porque el modelo corre en el tier gratuito de OpenRouter y Telegram es gratis.

Este post es el setup, y después los dos lugares donde se rompió en producción, que es la parte que casi todos los write ups se saltean.

Por qué self hosted, y cuándo es la decisión equivocada

La mayoría de las plataformas de agentes autónomos hoy cobran una suscripción mensual y después te limitan dos veces: ventanas de ejecución y consumo de tokens. Estás comprando algo descripto como always on y estás recibiendo un turno. Si tu caso de uso es un cron diario y un monitor de leads, esos dos límites son exactamente los que duelen.

Hermes es open source, se distribuye como imagen de Docker y corre en tu propia máquina. El detalle de arquitectura importante es que el modelo en sí no corre en tu servidor. La inferencia queda en la infraestructura de OpenRouter, así que un VPS chico alcanza. Estás hosteando la orquestación, la memoria y las tools, no los pesos.

El contraargumento honesto: esto no es gratis, es no facturado. Cuando el bot dejó de responder no hubo soporte, hubo un gateway para reiniciar. Cuando la búsqueda se rompió no hubo ticket, hubo un script para abrir. Si nadie de tu lado administra un servidor, la suscripción con límites es la decisión correcta.

La arquitectura en un párrafo

Varios canales (Telegram, Slack, Discord, email) entran por un único gateway. Detrás del gateway hay un agente principal que actúa como orquestador: lee la intención y despacha a sub agentes, cada uno con una responsabilidad acotada y su propio toolset. En mi instancia el sub agente relevante se llama Radar, y su único trabajo es encontrar clientes potenciales. La memoria es persistente entre canales, así que la sesión es sobre vos, no sobre la app que abriste.

Dos reglas que aplicaría en cualquier instancia, y sobre la segunda vuelvo más adelante:

• El orquestador decide, los sub agentes ejecutan. Una responsabilidad cada uno.
• Un sub agente con acceso a internet no debería tener acceso a la terminal.

Setup

El despliegue en sí no es la parte interesante, así que versión corta:

1. Aprovisioná un VPS (yo uso Hostinger y su catálogo de templates tiene una imagen de Hermes, así que es un contenedor de un click). Definí el usuario y la contraseña del dashboard al momento de crearlo.
2. Creá una API key de OpenRouter. Si estás en Windows, fijate que no queden espacios al final cuando la pegás, esto me costó diez minutos de confusión.
3. Corré el wizard de setup completo, elegí OpenRouter como proveedor y seleccioná un modelo NVIDIA Nemotron gratuito como modelo principal. Configurá un fallback para cuando el tier gratuito está bajo carga.
4. Mantené la ejecución de terminal local. No hay razón para rutearla a otro lado.
5. Conectá Telegram por BotFather en vez del flujo con QR. El flujo con QR usa tu cuenta personal, que está bien para un asistente personal y mal para cualquier cosa con la que van a hablar otras personas.
6. Restringí el canal a tu user id de Telegram. En un modelo gratuito esto protege tu instancia, en un modelo pago protege tu billetera.
7. Reiniciá el gateway. Los canales no se activan hasta que lo hacés.

De ahí en adelante le hablás. Pedirle un reporte diario en lenguaje natural alcanza para que escriba el cron solo:

me: generate a daily cron at 9am that runs this lead search
agent: created. runs 09:00 UTC daily, writes results to the board and
       sends the digest through telegram

Esa es la parte genuinamente nueva. No escribí un scheduler, describí un resultado.

El perfil de Radar

El sub agente se crea de la misma manera, describiéndolo. Lo que importa es qué va en la descripción, y no es el tono, son las restricciones:

• El ICP en términos específicos. El mío: gente integrando Twilio, WhatsApp Business API, IA de voz, IVR, A2P 10DLC. Los ICP vagos son los que generan ruido.
• Una allowlist de subreddits. Nueve, en mi caso.
• Un board (kanban) con estados explícitos: New, Qualified, Contacted, In conversation, Won, Discarded. Así es como los sub agentes devuelven resultados al orquestador en vez de tirar texto suelto.
• Un score mínimo para calificar, para que el filtrado sea una regla y no una sensación.
• Reglas de fechas. Esta es la que hice mal, así que tiene su propia sección.

Una nota de infraestructura antes de eso: Reddit ahora exige registrar la app en una plataforma nueva, y para este caso de uso es paga. En su lugar apunté el agente a Arctic Shift, que expone los posts casi en tiempo real sin autenticación. Si estás copiando esto, ese cambio es la diferencia entre un perfil que funciona y un perfil que te pide credenciales que no puede conseguir.

Dónde se rompió, parte uno: el agente inventó fechas

El resumen de leads volvió con un post que describía como de hace 30 días. Abrí el link. El post tenía tres años.

Le mandé la evidencia y le pregunté de dónde salió la fecha. Me dijo que la fecha había sido inventada y que era un error de su lado. Entonces hice una pregunta mejor: ¿qué fecha tenés registrada como hoy? El agente sabía. El script de búsqueda que se había escrito para sí mismo, no.

Esa es la falla real. El modelo no estaba alucinando un hecho que debería saber: estaba razonando sobre un script cuyos defaults de fecha nunca se setearon. Y su instinto cuando falta un valor es completar en vez de frenar. Una ventana relativa (últimos 7 días) calculada contra una referencia equivocada produce disparates con confianza.

El fix es una línea, y deliberadamente no es algo sobre lo que el agente pueda razonar:

from datetime import datetime, timedelta, timezone

now = datetime.now(timezone.utc)          # system time, at runtime
window_start = now - timedelta(days=7)    # never hardcode a date

params = {
    "subreddit": subreddit,
    "after": int(window_start.timestamp()),
    "before": int(now.timestamp()),
    "limit": 100,
}

Regla que ahora aplico a todo agente que toca una ventana relativa: la fecha de referencia entra en runtime desde el sistema, en cada corrida. Y el filtrado pasa por código. El modelo escribe la justificación de un lead, no calcula si el lead es reciente.

Después de esa corrección la corrida produjo un lead calificado en siete días. Un thread de hace dos días de un founder SaaS lidiando con el onboarding de 10DLC para sus clientes, que es precisamente lo que vendo. Un lead es un número bajo, y prefiero uno en el que confío antes que la versión anterior de este sistema, armada con scraping de keywords a secas. Ahí más o menos el 90% del output era ruido de keywords ambiguas disparando en todos los subreddits a la vez.

Dónde se rompió, parte dos: la interfaz de chat es una shell

Para un solo usuario, darle al agente acceso a la terminal es la razón por la que es útil. Instala sus propias dependencias y escribe sus propias integraciones.

En el momento en que dejás que otras personas le hablen, esa misma interfaz es una shell en lenguaje natural sobre tu servidor, con un modelo decidiendo qué es legítimo. Y el riesgo no es solo el mensaje que tenés adelante. Un comando no necesita correr en la conversación para correr. Le alcanza con quedar escrito en un job programado que se ejecuta en el próximo cron, cuando ya nadie está leyendo el chat.

Mitigaciones concretas, en el orden en que las aplicaría:

• Allowlist de user ids mientras la instancia es tuya.
• Agentes separados: lo que navega no toca la terminal.
• Congelá el toolset antes de dar acceso a terceros. Armá el agente con las tools que necesita, y después abrilo. Un agente que todavía puede escribirse capacidades nuevas en runtime no es un producto, es un servidor compartido con una interfaz de chat.

Para qué lo usaría realmente

Resúmenes diarios y monitoreo, sí. Es muy bueno vigilando algo aburrido con un cronograma y avisándote cuando importa. Prospección, sí, pero con el humano en el paso de decidir, no en el de buscar: el agente califica y llena el board, el primer mensaje lo escribo yo.

Lo que todavía no haría es dejarlo actuar sobre el mundo exterior sin revisión. No porque no sea capaz, sino porque su modo de falla es completar con confianza. Y todo sistema que construyo sobre canales de comunicación tiene un costo asociado a equivocarse con confianza frente a un cliente.

-Gonza