Por fin un benchmark que intenta medir a los agentes donde duele: haciendo trabajo de verdad
La novedad no es que exista otro benchmark, sino que intenta sacar a los agentes del teatro del prompt y meterlos en flujos científicos largos, con terminal y con fricción real. Eso importa porque el mercado está lleno de marketing de “agentes autónomos” y muy poca evidencia sobre si aguantan una tarea sin descomponerse a mitad de camino.
📰 Qué ha pasado
Han sacado Terminal-Bench-Science, un benchmark para evaluar agentes de IA en flujos de trabajo científicos desde terminal. La propuesta no se centra solo en si el agente contesta bien, sino en si es capaz de sostener una tarea larga sin romperse ni empezar a inventar soluciones absurdas. El propio planteamiento apunta a una evaluación más cercana al trabajo real que a una demo de laboratorio. En la práctica, busca medir algo que muchas empresas venden pero pocas prueban con rigor.
🧭 El contexto: por qué ahora
Llevamos meses, si no años, viendo cómo se empaqueta cualquier automatización con LLM como “agente”, aunque luego el sistema sea poco más que un wrapper con cinco llamadas a herramientas. El problema de fondo es que los benchmarks clásicos suelen premiar respuestas puntuales, no la ejecución sostenida, la recuperación ante errores ni la disciplina operativa. En entornos científicos y técnicos, el valor no está en una respuesta brillante, sino en completar una secuencia de pasos sin desviar el proceso. Por eso un benchmark en terminal tiene sentido: obliga a tocar el barro, no solo a hablar de él. Ahora bien, como cualquier benchmark, mide una parte de la realidad y deja fuera muchas otras.
🎯 A quién le afecta y cómo
- Si construyes agentes en producción: te da una referencia más seria para comparar sistemas que prometen autonomía.
- Si trabajas en data science o investigación: puedes usarlo para detectar si un asistente sirve de verdad o solo impresiona en una demo.
- Si lideras producto con IA: te obliga a separar “feature bonita” de automatización útil y medible.
- Si montas infraestructura para LLMs: te ayuda a pensar en persistencia, recuperación de errores y observabilidad, no solo en latencia y coste.
⚖️ Nuestra opinión
Criterio propio, sin nota de prensa: lo bueno, lo malo y lo que haríamos nosotros.
Esto es una buena dirección porque devuelve la conversación al terreno de la operativa real. La industria lleva demasiado tiempo premiando la capacidad de impresionar en una interacción corta, cuando el valor de un agente está en sostener contexto, manejar fallos y no degradarse con el paso de los pasos. Un benchmark así no resuelve el problema, pero sí cambia la vara de medir. Y eso ya es bastante, porque sin métricas serias todo acaba siendo fe ciega en el vendor de turno.
La pega es la de siempre: un benchmark útil no es una verdad universal. Si el entorno está demasiado acotado, puedes acabar optimizando para el examen y no para el mundo real; si está demasiado abierto, deja de ser reproducible. Aun así, prefiero mil veces un benchmark imperfecto que intente medir ejecución larga a seguir comprando humo de “agentes autónomos” basados en una demo de tres minutos. Lo importante aquí no es que el benchmark sea perfecto, sino que castiga justo las promesas que más se exageran.
Lo que haríamos nosotros es usarlo como filtro, no como oráculo: probaríamos agentes con tareas largas, registraríamos fallos y compararíamos contra flujos manuales antes de meterlos en producción. También revisaríamos si nuestras propias pruebas internas miden persistencia, recuperación y errores encadenados, porque ahí es donde se rompen estos sistemas. Si estás evaluando proveedores o frameworks, pide evidencia de tareas completas, no capturas de pantalla bonitas. Y si un agente no aguanta una cadena larga en terminal, no lo vendas como autónomo: véndelo como asistente, que ya es bastante.
✅ Qué hacer con esto
Acciones concretas si esto te toca de cerca.
- Probar el benchmark en local o en un entorno controlado y comparar resultados con tus casos de uso reales.
- Revisar si tus evals actuales miden tareas completas o solo respuestas puntuales.
- Añadir pruebas de recuperación ante errores, timeouts y cambios de estado en tus agentes.
- Exigir a proveedores y demos evidencia de ejecución sostenida, no solo de conversación.
- Documentar qué tareas de tu organización sí merecen automatización y cuáles siguen necesitando supervisión humana.