ToolTurns muestra que los agentes de IA aciertan 7 de cada 10 peticiones sueltas, pero solo 4 de cada 10 conversaciones
El mejor agente de inteligencia artificial resuelve el 69,6 % de las peticiones sueltas, pero solo el 39,8 % de los diálogos completos, según ToolTurns.

Qué se sabe y qué no. Este artículo distingue lo anunciado oficialmente de lo filtrado, especulado o todavía no confirmado. Las afirmaciones dudosas se marcan como tales en el texto.
Qué se ha presentado
Un equipo de la Universidad de California en Santa Cruz ha presentado ToolTurns, un banco de pruebas que evalúa a los agentes de inteligencia artificial en conversaciones de varios turnos con herramientas. La mayoría de los bancos de pruebas de uso de herramientas plantean una petición aislada; ToolTurns arranca con una petición deliberadamente incompleta y la sigue con dos peticiones de seguimiento que dependen del contexto, de modo que el agente tiene que pedir aclaraciones, usar las APIs disponibles y conservar el hilo de la conversación.
El conjunto tiene 2.620 problemas, 1.827 herramientas y 11.004 endpoints de API repartidos en 47 categorías de RapidAPI. Cada problema expone una media de 26,5 endpoints y genera 7.860 subtareas puntuables por agente. Los autores evaluaron nueve modelos: cuatro propietarios (GPT-4o-mini, GPT-4.1-mini, GPT-5.4-mini y Claude Opus 4.8) y cinco de pesos abiertos (Qwen3.5-397B-A17B, Qwen3.6-27B, Gemma 4-31B-IT, GPT-OSS-120B y GLM-5.2-744B).
El resultado central es una caída de unos 30 puntos entre la petición suelta y la conversación completa. El mejor agente, Opus 4.8, resuelve el 69,6 % de las peticiones individuales, pero solo completa el 39,8 % de los diálogos en los que las tres peticiones salen bien. Ningún modelo alcanza el 70 % en subtareas, y todos obtienen peores resultados en las peticiones de seguimiento que en la primera.
Por qué importa
El hallazgo apunta a un desajuste entre cómo se mide a los agentes y cómo se usan. Gran parte de la evidencia sobre uso de herramientas se ha construido con peticiones únicas, y los agentes se despliegan en conversaciones donde el usuario corrige, matiza y encadena. ToolTurns evalúa al agente a lo largo de su propia trayectoria, con un usuario simulado que revela información retenida a medida que le preguntan, de modo que el diálogo que se puntúa es el que el propio agente ha provocado.
La consecuencia práctica es que una cifra alta en peticiones aisladas no dice mucho sobre si un agente aguanta una conversación real. Los autores lo expresan con dos criterios: el porcentaje de subtareas resueltas y el porcentaje de diálogos en los que se resuelven las tres. La diferencia entre ambos es donde aparece el problema.
Cómo está construido
El usuario lo simula un modelo, Qwen3-32B-AWQ servido con vLLM, que responde a las aclaraciones del agente revelando el contexto retenido y genera las dos peticiones de seguimiento a partir de lo que se ha dicho en la conversación. El agente trabaja con un bucle de búsqueda limitado a 15 mensajes y dos herramientas de control: finish, para dar la respuesta, y message_user, para pedir información. Las respuestas de las APIs provienen de la caché de StableToolBench o, si falta, de una simulación con el mismo modelo; no se hicieron llamadas reales a los proveedores. El catálogo es la colección de RapidAPI que publicó ToolBench en 2023, y el entorno de ejecución es StableToolBench, la versión cacheada y simulada de ese mismo catálogo.
Los autores ilustran el formato con el problema 2610, cuya petición inicial es «me he enterado de que hay un partido importante pronto, ¿me dices cuándo es?» y cuyo contexto retenido es NBA, Los Ángeles, Lakers y octubre, con 48 endpoints a elegir. El agente tiene que preguntar por el deporte, el equipo y el marco temporal antes de saber qué herramienta invocar.
Sobre el usuario simulado, los autores añaden un circuito de revisión: un verificador detecta once tipos de defectos y un corrector reescribe el mensaje. Entre los mensajes reescritos (536 de 1.272 candidatos), el circuito reduce los defectos detectados por regla un 41,2 %, y en una anotación humana a ciegas la versión revisada se prefiere en el 63,3 % de 120 pares.
Lo que revelan los datos
- Todos caen en los seguimientos. Los nueve modelos puntúan más alto en la petición inicial y más bajo en las dos siguientes. La magnitud varía: GPT-OSS y GPT-4o-mini pierden 16,2 y 14,9 puntos entre la primera y la segunda petición de seguimiento; GPT-5.4-mini solo 2,1. Opus 4.8 pasa del 74,7 % al 68,6 %.
- La calidad del diálogo y el éxito en la tarea no se corresponden. El rubro ponderado y el éxito en la tarea se ordenan con una correlación de 0,23. GPT-5.4-mini lidera el agregado (0,817) y es el segundo peor en éxito (56,3 %). GLM-5.2 es segundo en éxito (67,9 % de subtareas y 37,7 % de diálogos completos) y séptimo en el agregado (0,685). Un agente que hace pocas llamadas coherentes y escribe una respuesta fluida puede puntuar bien sin resolver lo que se le pide.
- Los modelos abiertos compiten. GLM-5.2 (67,9 %) y Gemma 4 (67,5 %) se acercan a Opus 4.8 (69,6 %) y superan a los tres modelos de OpenAI. Gemma 4, con 31.000 millones de parámetros, está a 0,4 puntos de GLM-5.2, con 744.000 millones. Qwen3.6-27B iguala a Qwen3.5-397B en éxito (61,0 % frente a 60,9 %) con un coste de servicio muy inferior. El tamaño, entre 27.000 y 744.000 millones, predice poco.
- El juez importa. La calidad del diálogo y el éxito en la tarea los puntúan jueces de lenguaje (gpt-oss, temperatura 0,2). GPT-OSS es a la vez agente y juez, así que sus puntuaciones no son independientes del evaluador. Los autores separan ambos criterios justamente para no confundirlos.
Limitaciones
El trabajo es un preprint enviado a ICLR 2027, no un artículo revisado por pares. Las APIs no responden de verdad: se usan respuestas cacheadas o simuladas, y los propios autores comprueban que esto no explica los resultados (un control determinista afecta a 20 de 70.740 subtareas, un 0,03 %). También advierten de que el juez de subtareas no ve las pruebas de herramientas de subtareas anteriores, de modo que la caída en los seguimientos no aísla el coste de depender de la conversación. Parte del descenso de GPT-OSS se debe a un incumplimiento del protocolo: en el 56,1 % de los diálogos responde con texto plano en lugar de llamar a finish.
Qué sigue
El banco de pruebas, el código y las puntuaciones están publicados en github.com/milad621/ToolTurns (release v1.0.0), y el repositorio afirma que las 72 celdas de las tablas principales se reproducen con las reglas de agregación originales. La pregunta que deja abierta es la que importa a quienes despliegan agentes: si la garantía de una petición no se sostiene al segundo y al tercer turno, la evaluación de estos sistemas tiene que medir la conversación completa y no la primera respuesta.
Fuentes consultadas
Se conservan las referencias para poder reconstruir cómo se verificó esta información.
- arXiv — ToolTurns, Benchmarking LLM Agents in Multi-Turn Dialogue (11 de noviembre de 2026)preprint · https://arxiv.org/abs/2611.14925
- GitHub — milad621/ToolTurns, banco de pruebas, código y puntuaciones (release v1.0.0)codigo · https://github.com/milad621/ToolTurns
- arXiv — ToolLLM y ToolBench, el catálogo de APIs de RapidAPI que reutiliza ToolTurns (2023)antecedente · https://arxiv.org/abs/2307.16789
- ACL Anthology — StableToolBench, el entorno de ejecución que sirve las respuestas de las APIs (2024)antecedente · https://aclanthology.org/2024.findings-acl.664/
Publicación de origen: https://arxiv.org/abs/2611.14925
¿Ves un error? Escríbenos indicando el dato concreto y la fuente que lo contradice. Las correcciones se aplican en la propia página y se reflejan en la fecha de actualización. Contactar con la redacción.