El harness importa: por qué el mismo modelo de IA rinde muy distinto en tu pyme
Un mismo modelo de lenguaje puede pasar de completar el 30% al 81% de tareas solo cambiando el harness que lo orquesta. Para una pyme, elegir bien esa capa es tan decisivo como elegir el modelo.
Foto: Vitaly Gariev · unsplash
La noticia en una línea
IBM Research publicó un análisis comparando tres harnesses de agentes —CUGA, Hermes y Deep Agents— usando exactamente el mismo modelo abierto y las mismas 90 tareas de un benchmark llamado AppWorld. El resultado fue contundente: al cambiar solo la capa que orquesta al modelo, la tasa de tareas completadas pasó del 30% al 81%. La conclusión que dejan es simple y potente: el harness importa, no solo el modelo.
El artículo también cita que existen cerca de 200 harnesses disponibles en listas comunitarias, y que en otro análisis el mismo modelo saltó del 23% al 52% en SWE-bench Pro solo cambiando esa capa. La pregunta correcta, dicen, no es cuál es el mejor harness en abstracto, sino cuál encaja con tu carga de trabajo y tu modelo.
Qué es un harness y por qué debería importarte
Un harness es la capa de software que envuelve al modelo de lenguaje y decide cómo se usa: qué herramientas tiene disponibles, cómo descompone una tarea, cuándo verifica antes de ejecutar, cómo maneja errores y cuánto contexto conserva. El modelo es el motor; el harness es el chasis, la dirección y los frenos.
Para una pyme esto tiene una consecuencia inmediata. Muchas veces se prueba un asistente de IA y se concluye que "no funciona" o que "el modelo es malo", cuando en realidad el problema está en la capa de orquestación. La diferencia entre un agente que consulta tu sistema de facturación y otro que se pierde en el segundo paso no suele estar en el modelo, sino en cómo el harness estructura la ejecución.
El benchmark usado, AppWorld, prueba tareas de varios pasos sobre nueve aplicaciones y más de 450 APIs: iniciar sesión, leer documentación, paginar resultados y cambiar estado entre sistemas. Es un proxy razonable de lo que una pyme necesita cuando conecta su CRM, su facturación y su almacenamiento de archivos en un mismo flujo automatizado.
Por qué la consistencia vale más que un buen día
Más allá del porcentaje global, el dato más revelador del análisis es el de escenarios donde las tres variantes de una tarea se completaron correctamente. Ahí la brecha se amplía: 20 escenarios para CUGA, 8 para Hermes y 2 para Deep Agents. Ese indicador premia la consistencia y castiga la suerte.
Para una pyme, la consistencia es la métrica que realmente importa. Un agente que acierta el 80% de las veces pero falla de forma impredecible es más peligroso que uno que acierta menos pero siempre igual, porque no se puede delegar en él un proceso que toca clientes o dinero. La automatización seria necesita previsibilidad, no demostraciones brillantes.
El propio artículo aclara sus límites con honestidad: es una muestra de 90 tareas en un solo benchmark, las configuraciones no fueron idénticas y las ejecuciones no usaron políticas. Es decir, no es un veredicto sobre Hermes o Deep Agents, que están diseñados para otros trabajos —asistentes personales siempre activos o investigación de varios pasos—. Es una invitación a elegir el harness según el trabajo.
El punto que más le importa a una pyme: reglas que se cumplen de verdad
Aquí está, a mi juicio, la parte más valiosa del artículo para el mundo pyme. Muchos equipos escriben sus reglas de negocio en el prompt: "no pagues más de mil", "no compartas datos personales de clientes". Pero un prompt es una instrucción, no una barrera. El modelo puede malinterpretarla, un usuario puede convencerlo de lo contrario o un mensaje inyectado puede alterarla a mitad de la tarea.
CUGA propone mover esas reglas del prompt al harness, con políticas que actúan en cuatro momentos: la intención del usuario, la guía del agente, la ejecución de herramientas y la respuesta final. Algunas orientan al modelo, pero las aprobaciones y los ToolGuards los aplica el propio runtime: si una llamada a la herramienta de pago supera el límite, se bloquea y la herramienta ni siquiera se ejecuta.
El ejemplo del Policy Playground es muy gráfico: ante la instrucción "paga todo lo que debo", el agente sin políticas pagó también un cargo que estaba en disputa, mientras que el agente con políticas retuvo el pago para aprobación y solo abonó lo que correspondía. Esa diferencia entre "el modelo decidió bien" y "el sistema no permitió que decidiera mal" es exactamente la que separa un experimento de un proceso de negocio.
Lectura práctica para tu pyme
- No elijas solo por modelo. Antes de comparar proveedores de IA, define qué trabajo hará el agente y evalúa el harness que lo orquesta.
- Separa orientación de cumplimiento. Las reglas críticas —pagos, datos personales, acciones destructivas— deben vivir en la capa de ejecución, no en un prompt.
- Mide consistencia, no picos. Prueba tus flujos con tareas repetidas y mira cuántas se completan siempre bien, no cuántas acertaron una vez.
- Piensa en el despliegue. Si tus datos no pueden salir de tu entorno, necesitas un harness que corra dentro de tu propia infraestructura.
- Empieza acotado. Un flujo con pocas herramientas y reglas claras enseña más que un agente generalista sin límites.
En Altya trabajamos con pymes que quieren automatizar procesos reales sobre Odoo y otras herramientas, y esta discusión nos interesa porque define cómo diseñamos cada agente: con reglas aplicadas por el sistema y no solo sugeridas al modelo. Si estás evaluando por dónde empezar, conversemos sobre qué procesos conviene automatizar primero y con qué nivel de control.
Fuente: huggingface.co