Ollama escucha en el puerto 11434 de tu máquina. Cualquier proceso con acceso a esa API puede pedirle al modelo que decida acciones: invocar funciones, consultar servicios, corregir el rumbo según el resultado. Esa es la frontera entre un chatbot local y un agente local. Aquí montamos un Hermes Agent, un agente impulsado por los modelos Hermes de Nous Research, sobre Docker Compose, y veremos qué automatización aguanta sin depender de la nube.
De chatbot a agente: qué cambia de verdad
El chatbot genera texto y espera tu siguiente mensaje. Un agente de IA planifica: recibe un objetivo, elige herramientas, las ejecuta y ajusta el siguiente paso si el resultado no encaja. La pieza que hace posible ese bucle es el function calling: el modelo responde con JSON estructurado que indica qué función invocar y con qué parámetros, tu código la ejecuta y devuelve el resultado al modelo para la siguiente decisión.
Sin function calling nativo, la alternativa es parsear texto libre con expresiones regulares, un enfoque que se rompe al añadir la tercera herramienta. Antes de montar nada, comprueba que tu modelo emite llamadas a funciones de forma consistente; ahí se decide si el proyecto avanza o se queda en demo.
Hay una tercera diferencia, menos visible: el contexto. Un chatbot arranca cada conversación casi en blanco. Un agente arranca con instrucciones de sistema, la lista de herramientas disponibles y, a menudo, el estado de tus sistemas. Ese prompt inicial es parte de tu infraestructura: se versiona, se revisa y se testea igual que el código que ejecuta las herramientas.
Los modelos Hermes: el motor del agente
El paso previo a cualquier agente es tener claro por qué local y no SaaS: control de datos, coste plano y latencia sin terceros. Si te lo estás planteando de cero, la comparativa IA local vs SaaS resume las decisiones que condicionan todo lo demás. Nous Research mantiene la familia Hermes, modelos de pesos abiertos publicados en Hugging Face. Hermes 3, lanzado en agosto de 2024, se construye sobre Llama 3.1 y existe en tamaños de 8B, 70B y 405B. Desde Hermes 2 Pro, la serie soporta function calling y salida JSON nativas, justo lo que un agente necesita para decidir acciones sin trucos frágiles de prompting.
El término Hermes Agent no designa una caja negra: hablamos de un orquestador (un script en Python, un flujo de n8n o un framework de agentes) que usa un Hermes como cerebro y conecta sus tool calls con tus sistemas. Para empezar, la variante de 8B en formato GGUF cuantizado a 4 bits ocupa en torno a 5 GB y cabe en GPUs domésticas de 8 GB de VRAM. Paso concreto: ejecuta ollama pull hermes3 y lanza desde la terminal una pregunta con una herramienta de prueba.
El stack mínimo con Docker Compose
Para un primer despliegue bastan dos servicios: Ollama como servidor de inferencia y Open WebUI como interfaz de prueba. Este docker-compose.yml sigue la configuración que publican ambos proyectos:
Fichero y arranque
services:
ollama:
image: ollama/ollama:latest
ports:
- "11434:11434"
volumes:
- ollama:/root/.ollama
open-webui:
image: ghcr.io/open-webui/open-webui:main
ports:
- "3000:8080"
environment:
- OLLAMA_BASE_URL=http://ollama:11434
volumes:
- open-webui:/app/backend/data
depends_on:
- ollama
volumes:
ollama:
open-webui:
Comprobación del servicio
Tras docker compose up -d, la API de inferencia queda en http://localhost:11434 y la interfaz en el puerto 3000. La API de chat de Ollama acepta tool calls, así que tu agente se registra como un cliente más. Si ya montaste tu chat privado con Open WebUI sobre Ollama, el compose te resultará familiar; si no, lo documentamos paso a paso en Open WebUI: monta tu chat de IA privada sobre Ollama en tu propio servidor.
El patrón escala por servicios: cada herramienta del agente (una API REST, un script, una base de datos) es una entrada más en el compose. Mantenerlas en contenedores separados te da aislamiento, logs centralizados y políticas de reinicio sin trabajo extra.
Automatización real: tres puntos de partida
Si dudas por dónde entrar, hay tres caminos que funcionan sin infraestructura exótica.
Triaje de logs con criterio
Apunta el agente a los registros de un contenedor con errores recurrentes, deja que agrupe patrones y que abra una incidencia solo cuando el fallo sea nuevo. El ahorro real no está en que lea los logs por ti: está en que no despierte a nadie por un fallo ya visto. Define antes qué cuenta como «nuevo» (mensaje de error inédito, frecuencia anómala) y escribe esa definición en la herramienta, no en el prompt del chat. Un agente de IA que decide con reglas explícitas es auditable; uno que improvisa cada noche, no.
Documentos a JSON sin revisión manual
Correos, facturas o notas convertidas a JSON con salida estructurada, listos para tu base de datos o CRM. Es el caso de uso más agradecido para un 8B: la salida JSON nativa de la serie Hermes encaja aquí de forma natural y un fallo se detecta con una validación de esquema, no con una lectura humana. Empieza por un tipo de documento, mide el porcentaje de validaciones superadas durante una semana y decide con ese número si amplías el alcance.
Orquestación con n8n
Un webhook dispara el flujo, un nodo consulta el modelo con una herramienta sobre tu API interna y las ramas del workflow ejecutan la acción decidida. n8n se autohospeda igual que Ollama, así que el circuito completo —entrada, decisión, acción— vive en tu servidor. La regla práctica: n8n manda en el flujo y el agente decide dentro de un nodo. Si el agente gobierna el workflow entero, pierdes el control visual sobre qué se ejecutó y por qué.
Si dudas por dónde entrar, elige la segunda: exige pocos permisos y revela rápido si el modelo de 8B da la altura para tu caso.
Herramientas: cómo decide el agente qué ejecutar
El modelo no ejecuta nada por sí mismo: propone. Tu código recibe la llamada, la valida y la ejecuta, y devuelve el resultado al modelo para que continúe. Ese reparto de responsabilidades define la arquitectura: el cerebro (el Hermes) puede vivir en la máquina más modesta, mientras que las herramientas exigen acceso a tus sistemas reales. Separar cerebro y manos es lo que permite auditar cada acción.
El esquema de la herramienta manda
Cada herramienta se declara con un esquema JSON: nombre, descripción y parámetros con tipos. La calidad de esa descripción pesa más que el tamaño del modelo. Un 8B con cinco herramientas bien documentadas acierta más que un 70B con una veintena de descripciones ambiguas. Escribe las descripciones como si se las explicaras a un becario listo: qué hace, cuándo usarla y cuándo no.
Valida antes de ejecutar
Convierte cada llamada en tres pasos: comprobar el esquema, comprobar permisos, ejecutar. Si la propuesta del modelo no pasa la validación, devuelve el error tal cual; el modelo corrige el rumbo en la siguiente iteración. Este bucle de corrección es gratis y evita la mayoría de las salidas disparatadas. Registra cada ejecución con entrada y salida: cuando el agente se equivoque —y se equivocará—, ese registro es la diferencia entre depurar y adivinar.
Este patrón no es exclusivo de los Hermes: cualquier modelo con function calling nativo encaja. Si tu caso pesa más hacia la recuperación de información que hacia la ejecución de acciones, el siguiente paso natural es montar RAG sobre tus documentos con bots de IA en Telegram con modelos locales o leer cómo preparamos la primera colección en Open WebUI: monta tu chat de IA privada sobre Ollama en tu propio servidor.
Límites que conviene conocer antes de desplegar
Antes de desplegar, conviene asumir que el function calling no es infalible: los modelos inventan parámetros o eligen la herramienta equivocada; por eso, seguridad primero.
Seguridad primero
El function calling no es infalible: los modelos inventan parámetros o eligen la herramienta equivocada, y los tamaños pequeños fallan más. Valida cada llamada contra un esquema y aplica permisos mínimos; no concedas a un agente acceso sin restricciones a la shell de la máquina donde viven tus datos. Y guarda un modo manual: si el agente se atasca en un bucle de llamadas, corta por ti, no por él.
Latencia y diseño asíncrono
En CPU los tiempos de respuesta se disparan, así que diseña la automatización como asíncrona (colas, tareas programadas) en lugar de conversación en tiempo real. Y cuantas más herramientas registras en el prompt del sistema, más se confunden: prefiere herramientas pequeñas y verificables a una sola con superpoderes.
Por dónde empezar
Para empezar, plantea un plan de una tarde para comprobar si el agente responde usando una sola herramienta.
Plan de una tarde
Plan de una tarde: levanta el compose, descarga hermes3, define una sola herramienta (por ejemplo, una función que consulte tu API de monitorización) y pide al agente una respuesta real usando esa herramienta. Mide dos cosas: si la llamada a la función es correcta a la primera y cuánto dura el ciclo completo. Si el 8B acierta y la latencia te sirve, tienes automatización local funcionando; si no, el salto a 70B depende del hardware, y para elegir entre VPS y equipo propio conviene repasar costes y opciones en Self-hosting de IA: VPS, costes y hardware para tu propio stack.
El valor de los agentes de IA locales no está en el chat: está en que tus automatizaciones, y los datos que las alimentan, no salen de tu red. Y si quieres que ese agente mueva Qdrant, WordPress o Git con un protocolo común en vez de conectores artesanales, el Model Context Protocol conecta tu stack local.
Para desplegarlo necesitas una máquina que no se apague cuando cierras el portátil: un VPS con suficiente memoria hace de hogar permanente del agente y de sus herramientas. Si estás comparando proveedores, tamaños y precios, la guía completa de Self-hosting de IA: VPS, costes y hardware para tu propio stack te evita pagar de más por VRAM que no vas a usar. Y cuando el modelo elija ejecutar algo contra el exterior, hazlo desde un servidor dedicado: puedes desplegar tu VPS y probar el agente hoy mismo con el compose de arriba, sin tocar tu máquina de trabajo.