Elegir harness: Hermes Agent, n8n o Claude Code

La pregunta que más me hacen desde que dejé de presentarme como desarrolladora RPA es siempre la misma: ¿con qué construyes tus agentes? Y responder “depende” suena a evasiva hasta que uno explica de qué factores depende.

Llevo meses construyendo agentes con tres harnesses distintos en paralelo. Uso los tres porque cada herramienta responde a una arquitectura y complejidad distinta. Esta nota resume el criterio técnico que me habría gustado tener hace un año.

Primero: qué es un harness y por qué importa

Un harness es la infraestructura que rodea al modelo: el bucle que decide cuándo llamarlo, qué herramientas puede usar, dónde guarda su memoria, qué pasa cuando algo falla y cómo se detiene. El modelo es el motor; el harness es el auto completo.

Confundir ambas cosas es el error más caro que vi este año. Un equipo cambió de modelo tres veces buscando mejores resultados cuando el problema real era que su bucle no tenía criterio de detención y el agente daba vueltas hasta agotar el presupuesto de tokens.

El modelo casi nunca es el cuello de botella. El harness sí.

n8n: cuando el proceso tiene forma de flujo

n8n es mi punto de partida cuando el proceso ya tiene una forma clara y lo que necesito del modelo es criterio en uno o dos puntos específicos.

Su gran virtud es que el flujo es visible. Cuando el área de negocio pregunta “¿y qué pasa si el correo viene sin adjunto?”, puedo girar la pantalla y mostrar la rama. Eso vale mucho más de lo que parece: la mitad del trabajo de automatizar es conseguir que la gente confíe en lo que construiste.

Dónde brilla:

• Integraciones que ya existen y no quiero programar (Gmail, Sheets, bases de datos, webhooks).
• Procesos con pasos determinísticos donde el LLM interviene en momentos puntuales.
• Cuando necesito que alguien que no programa pueda leer (y eventualmente mantener) el flujo.

Dónde se rompe: cuando el proceso deja de ser un flujo. Si el agente necesita decidir el orden de sus propias acciones según lo que va encontrando, forzar eso en un canvas de nodos se vuelve un laberinto de ramas. Ahí n8n deja de ayudar y empieza a estorbar.

Hermes Agent: cuando el objetivo importa más que los pasos

Uso Hermes cuando le puedo describir al agente qué resultado quiero en lugar de cómo llegar. La diferencia se nota rápido: en un flujo n8n yo defino la secuencia; acá defino el objetivo, las herramientas disponibles y los límites, y el agente arma su propia secuencia.

Un caso real: la conciliación de un set de documentos donde no sabíamos de antemano cuántas consultas haría falta ni en qué orden, porque dependía de lo que apareciera en cada documento. En un flujo eso son quince ramas; en un agente son tres herramientas bien descritas y un buen prompt de sistema.

Lo que aprendí a la mala:

• Las descripciones de las herramientas son el 80% del resultado. Un agente que se equivoca de herramienta casi nunca tiene un problema de modelo: tiene una descripción ambigua. Escríbelas como si fueran documentación para alguien nuevo.
• Sin criterio de detención explícito, el agente no se detiene. Máximo de iteraciones, presupuesto de tokens y una condición de éxito verificable. Siempre.
• La observabilidad no es opcional. Si no es posible reconstruir la traza de decisiones del agente, el sistema no está listo para operar en producción.

Claude Code: entorno de desarrollo y prototipado técnico

Este es el que más me cuesta explicar, porque no lo uso para automatizar procesos de negocio: lo uso para construir las automatizaciones.

Migrar componentes, escribir los tests que nunca alcanzo a escribir, refactorizar librerías que quedaron con tres estilos distintos, generar la documentación técnica a partir del código real. Tareas donde el contexto es un repositorio completo y el resultado se verifica corriendo algo.

También lo uso como banco de pruebas: cuando quiero saber si una idea de agente tiene sentido, la prototipo ahí antes de montar la infraestructura. Si el prototipo no funciona con acceso total al contexto, no va a funcionar mejor dentro de un harness más restringido.

El criterio, en una tabla

Si el proceso…	Entonces
Tiene pasos fijos y conocidos	Automatización clásica o n8n, sin agente
Tiene pasos fijos pero necesita criterio en 1–2 puntos	n8n + llamada a LLM en esos nodos
Requiere decidir el orden según lo que encuentre	Agente con Hermes
Necesita explicarse a un área no técnica	n8n, por la visibilidad del flujo
Es una tarea sobre código o repositorios	Claude Code
Tiene consecuencias irreversibles (pagos, envíos)	Lo que sea, pero con humano aprobando

Lo que no cambia entre harnesses

Después de varios meses, mi conclusión es poco épica: el harness importa menos que las decisiones de diseño que uno toma dentro de él.

Estas cuatro cosas las tuve que resolver en los tres, sin excepción:

1. Definir qué es “terminó bien” de forma verificable por código, no por intuición.
2. Decidir qué pasa cuando el agente no está seguro. Un agente que adivina en silencio es peor que un proceso manual.
3. Registrar cada decisión con su contexto. Cuando algo falla en producción a las 3 de la mañana, el log es lo único que tienes.
4. Definir el límite de daño. Qué puede tocar el agente sin supervisión y qué requiere una firma humana.

Si tienes resueltas esas cuatro, cualquiera de los tres harnesses te va a funcionar. Si no las tienes resueltas, ninguno te va a salvar.

Por dónde empezar

Para comenzar, recomiendo elegir un proceso conocido, de bajo riesgo y volumen moderado. Permite dominar el harness, calibrar los guardrails y resolver excepciones antes de pasar a flujos con mayor impacto o incertidumbre técnica.