Lanza una función de IA, no solo una demo, con agentes de código
Evalúa el agente terminado con tareas end-to-end que no ha visto, luego audita la construcción por investigación superficial, pocas preguntas al cliente y restricciones sin gestionar.
| Autor | Prompt & Product — Redacción |
|---|---|
| Publicado | 17 septiembre 2026 |
| Lectura | 3 MIN |

Estás mirando una demo de agente pulida que parece lista para producción. La mejor configuración independiente de Sierra, que usa Claude Opus 5 con razonamiento máximo en Claude Code, superó el 23,9 % de las tareas de atención al cliente reservadas. La misma clase de modelo alcanzó el 82,2 % en esas tareas con un ingeniero que tenía contexto profundo. La brecha apunta al contexto, y el contexto es una superficie de diseño. Evalúa el agente terminado con tareas end-to-end que no ha visto, luego audita la construcción por investigación superficial, pocas preguntas al cliente y restricciones sin gestionar.
La demo no es el artefacto correcto
Los agentes de código son buenos para hacer que el camino feliz parezca terminado. Generan una transcripción limpia, una respuesta plausible y una interfaz que parece lista. El artefacto es el agente de atención al cliente, no la historia que la construcción cuenta sobre sí misma.
En el benchmark, un agente de código construye dentro de un kit aislado, puede hacer preguntas a un cliente simulado y devuelve un agente de atención al cliente terminado y ejecutable. El agente terminado se evalúa luego con tareas de atención al cliente que no ha visto, y la recompensa del desarrollador equivale a la tasa de éxito de ese agente. El artículo de arXiv, τ^τ-Bench, lista a Quan Shi y a otros tres autores. La primera versión en arXiv se envió el 4 de septiembre de 2026. El repositorio público hyper-τ-bench incluye 53 tareas de lanzamiento: seis airline_plus, seis retail_plus, seis telecom y 35 banking_knowledge.
Evalúa el agente terminado antes de confiar en el proceso
Una demo puede ocultar una máquina de estados frágil. Una tarea end-to-end reservada la expone. La tarea debe ser realista, de extremo a extremo y ausente del contexto de construcción. Debe requerir que el agente entienda la solicitud, llame a las herramientas correctas, gestione un fallo y devuelva una respuesta útil. También necesita una llamada a herramienta, un cambio de estado y un resultado visible para el usuario.
Si tu equipo usa agentes de código para ensamblar funciones de IA, haz que el agente terminado sea la unidad de evaluación del agente. No evalúes la transcripción. No evalúes el primer ejemplo funcional. Evalúa el artefacto ejecutable con tareas que no ha visto.
Construye un pequeño arnés de evaluación alrededor del artefacto. Mantén las tareas ocultas para el agente durante la construcción. Reutiliza las mismas tareas entre versiones para que una nueva construcción pueda compararse con la anterior. Esto convierte una demo puntual en un bucle de evaluación repetible.
Audita la construcción por los modos de fallo que hacen que las demos parezcan listas
La trayectoria de la construcción es evidencia. Una construcción superficial aún puede producir una demo. Normalmente muestra las mismas señales: el agente omitió la investigación, no hizo preguntas al cliente, lanzó el primer diseño e ignoró las restricciones de API o de coste. Una demo puede pasar porque el usuario es indulgente. Una función de producción no.
La lista de verificación siguiente es el rediseño. Convierte la auditoría en una comprobación repetible. Nombra el modo de fallo al devolverla, para que la siguiente construcción corrija la causa, no el síntoma. Cada elemento apunta a una señal y puede verificarse rápidamente.
- Ejecuta una tarea reservada rápida: elige una solicitud de cliente que el agente no vio durante la construcción y registra si pasa o falla.
- Cuenta las preguntas al cliente: abre la transcripción y marca una construcción sin preguntas sobre usuarios, restricciones o casos límite.
- Busca investigación superficial: busca cualquier fuente, especificación o caso previo más allá del primer ejemplo funcional.
- Revisa el primer diseño: compara la implementación inicial con la final y anota si se lanzó sin cambios.
- Prueba un fallo de API: inyecta un timeout o un error y confirma que el agente tiene un plan de respaldo.
- Prueba una restricción de coste: establece un límite de tasa o un tope de presupuesto y confirma que el agente degrada su rendimiento de forma elegante.
- Verifica el arranque limpio: inicia el agente final en un entorno nuevo y confirma que funciona sin ayuda externa.