IBM CUGA: el motor de agentes que sube del 30% al 81%

El mismo modelo, dos resultados opuestos

El mismo modelo abierto completó el 30% de las tareas en un benchmark y el 81% en otro experimento. Lo único que cambió fue el motor de agentes que lo ejecutaba. Un motor de agentes (en inglés, harness) es la capa de software que decide cómo el modelo usa herramientas, gestiona contexto, verifica pasos y reintenta cuando algo falla. No es el modelo: es todo lo que lo rodea.

IBM Research publicó CUGA (ConfigUrable Generalist Agent), un motor de agentes open source pensado para trabajo empresarial, y lo comparó contra Hermes de Nous Research y Deep Agents de LangChain usando el mismo modelo open-weight GLM-5.3-flash en 90 tareas de AppWorld. Para un founder que está armando agentes que tocan CRM, pagos o datos de clientes, la conclusión es incómoda: elegir el modelo es la mitad de la decisión.

¿Qué es un harness de agentes y por qué define el resultado?

Las listas comunitarias como awesome-agent-harness y best-of-Agent-Harnesses rastrean cerca de 200 motores de agentes distintos. La propia documentación de CUGA cita un análisis recogido por best-of-Agent-Harnesses donde el mismo modelo GLM-5.2 pasó del 23% al 52% en SWE-bench Pro cuando solo se cambió el motor.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Eso reordena la pregunta. No es «¿cuál es el mejor motor?», sino «¿cuál encaja con mi carga de trabajo y mi modelo?». Hermes está diseñado para asistentes personales siempre activos. Deep Agents, para tareas largas de varios pasos como investigación. El trabajo empresarial es un tercer tipo de tarea: agentes que actúan sobre sistemas de negocio y que deben respetar reglas que se sostengan sin importar lo que decida el modelo.

El experimento: mismo modelo, tres motores, 90 tareas

AppWorld es un benchmark de tareas multi-paso sobre 9 aplicaciones y 457 APIs (email, pagos, almacenamiento de archivos). Como son apps de consumo, funciona como proxy: prueba capacidades que la automatización empresarial también necesita, como iniciar sesión, leer documentación de APIs, paginar resultados y cambiar estado entre varias aplicaciones.

Cada motor corrió las mismas 90 tareas en 30 escenarios, con un intento por tarea, sobre el framework de evaluación Harbor. Los setups no fueron idénticos: CUGA usó su propia configuración de AppWorld (instrucciones, descomposición de tareas, verificación antes de ejecutar y reflexión automática), Hermes corrió con el setup por defecto de Harbor y las herramientas de AppWorld sobre MCP, y Deep Agents sumó el middleware de LangChain configurado para 469 herramientas.

El número más útil no es el porcentaje de tareas, sino el SGC: escenarios donde las tres variantes pasaron. Eso premia la consistencia y no una corrida con suerte. Ahí la brecha se agranda: 20 escenarios para CUGA, 8 para Hermes y 2 para Deep Agents.

Tres límites que la propia IBM reconoce: es una muestra de 90 tareas en un solo benchmark, los setups no fueron idénticos y las corridas no usaron políticas, así que no miden su cumplimiento.

CUGA y las políticas: reglas que el runtime hace cumplir

La parte que más le importa a un equipo con compliance es esta. La mayoría de los equipos escribe reglas de negocio —aprobación de pagos, manejo de PII— dentro del system prompt. Un prompt es una instrucción, no una imposición: el modelo puede malinterpretarla, un usuario puede convencerlo de saltarla y un mensaje inyectado puede cambiarla a mitad de tarea.

CUGA mueve esas reglas fuera del prompt y las mete en el motor. Su capa de políticas, descrita en el paper Governance by Construction for Generalist Agents (ACM CAIS 2026), actúa en cuatro puntos de cada corrida:

Intención del usuario — el Intent Guard bloquea o responde solicitudes antes de que el agente actúe.
Guía del agente — el Playbook le da un procedimiento estándar a seguir.
Ejecución de herramientas — el Tool Approval pausa la corrida y pide aprobación humana mostrando el código propuesto; el Tool Guide con ToolGuard corre código de guardia antes de la herramienta y, si bloquea, la herramienta nunca se llama.
Respuesta final — el Output Formatter ajusta la respuesta a una plantilla aprobada.

El ejemplo del Policy Playground lo muestra en concreto: ante el mensaje «Pay everything I owe», el agente sin políticas pagó 90 dólares, incluido un reclamo denegado que estaba en cobranza. El agente con políticas retuvo el pago para aprobación y luego pagó solo los 10 dólares que correspondían.

La distinción clave: la guía orienta al modelo, pero las aprobaciones y los ToolGuards los impone el runtime. Las reglas como aprobación de pagos y tratamiento de PII van en ese segundo grupo.

¿Qué significa esto para tu startup?

Si estás desplegando agentes que tocan dinero, datos de clientes o sistemas de terceros, el motor dejó de ser un detalle de implementación. Es la capa donde puedes demostrar control.

El mercado ya se está moviendo en esa dirección. LangChain y NVIDIA anunciaron el blueprint NemoClaw for LangChain Deep Agents, que combina el motor Deep Agents con el modelo Nemotron 3 Ultra y el runtime OpenShell para despliegue gobernado. Según el comunicado de LangChain, en su suite de evaluación de agentes ese stack logró un puntaje agregado de 0.86 a un costo de 4,48 dólares, frente a 43,48 dólares del siguiente modelo más cercano, lo que representa un costo de inferencia unas 10 veces menor. El mensaje de fondo es el mismo que el de IBM: el rendimiento mejora cuando se ajustan modelo y motor juntos.

Dos acciones concretas:

Mide tu motor, no solo tu modelo. Corre tu propio set de tareas con dos o tres motores sobre el mismo modelo y registra escenarios completos, no solo tareas sueltas. Un agente que acierta el 80% de las tareas pero falla sistemáticamente en un flujo crítico es peor que uno con menos aciertos y consistencia.
Saca las reglas duras del prompt. Si una regla no puede fallar —aprobación de pagos, no enviar PII afuera—, no la dejes como instrucción de texto. Busca un motor que la imponga en el runtime, con puntos de control antes de ejecutar la herramienta.

Cómo elegir un motor sin equivocarte

La comparación la corrió el propio equipo de CUGA y CUGA usó una configuración de AppWorld que los otros motores no tuvieron. IBM lo dice abiertamente y ofrece rerun público: quien tenga una configuración mejor para Hermes o Deep Agents puede enviarla a harbor-eval y se republicarán los resultados, gane quien gane. Eso es una señal de transparencia, pero también un recordatorio de que ningún benchmark decide por ti.

Para un founder en LATAM o España, la variable extra es el despliegue. CUGA está pensado para correr con modelos open-weight o alojados dentro de tu propio entorno, incluidos clouds soberanos y despliegues air-gapped. Si tu cliente es un banco, una aseguradora o una entidad pública, esa capacidad de quedarse dentro del perímetro pesa más que un par de puntos de benchmark.

La conclusión práctica: el modelo es commodity, el motor es donde construyes tu ventaja y tu defensa ante compliance. Trata la elección del motor con el mismo rigor con el que eliges el modelo.