Prueba frameworks de agentes de IA en un flujo de trabajo real de escalación

La forma más rápida de poner a prueba un framework de agentes no es una demostración. Es una escalación de un cliente que comienza con un ticket, usa una herramienta, espera una aprobación, deja una pista de auditoría y sobrevive a un paso fallido. Si el framework no puede mostrar ese ticket moviéndose por el sistema sin evasivas, no está listo para escalaciones. Es un chatbot con pasos de más.

Un ranking de 2026 de StartupHub.ai sitúa a los frameworks de código abierto y a las plataformas gestionadas en el mismo campo. Ordena las herramientas según una puntuación de plataforma construida a partir de la calidad de la documentación, la profundidad del ecosistema y la preparación empresarial. Eso es una advertencia útil: una plataforma puede estar bien documentada y aun así fallar cuando un ticket necesita una aprobación humana, una llamada a una herramienta y un error recuperable. La pregunta no es si puede hacer automatización de flujos de trabajo en una demostración; es si el flujo de trabajo sobrevive a una escalación en producción.

El Agents SDK de OpenAI se describe como un entorno de ejecución para agentes de varios pasos. Mastra se describe como un framework de agentes nativo de TypeScript de los creadores de Gatsby. Harmony se describe como una solución para gestionar tickets empresariales, aprobaciones y solicitudes. Esas descripciones no son la prueba. Son la línea de salida. La prueba es un ticket que pasa de la recepción a la resolución mientras el framework demuestra qué hizo, quién lo aprobó y qué pasó cuando algo falló.

Cuando evalúas un framework, estás eligiendo un sistema operativo para decisiones que pueden costar dinero, confianza o cumplimiento. El modelo puede ser inteligente. El framework puede ser flexible. Pero si no puede mostrar el estado del ticket, el estado de la aprobación y el estado del registro de auditoría, no estás ejecutando un agente. Estás ejecutando un rumor. Aquí es donde la evaluación de agentes deja de ser una simple impresión.

La ficha de puntuación de preparación para escalaciones

Usa cinco etapas. No dejes pasar a un framework si no puede mostrar evidencia para cada una. La ficha no es una lista de funciones. Es un requisito de prueba.

1. Acceso a herramientas. El agente debe llamar a las herramientas que necesita la escalación: gestión de tickets, registros de clientes, facturación, base de conocimiento o sistemas internos. Más importante que la lista de integraciones es la forma de la llamada. ¿Puedes ver la entrada, la salida, el alcance de permisos y el error? Si una llamada a una herramienta es una caja negra, el agente no está listo para una escalación en producción.
2. Estado de aprobación. Algunas acciones necesitan a una persona. El framework debe representar la aprobación como estado, no como un mensaje. Debe mostrar si la aprobación está pendiente, concedida, denegada o expirada. También debe mostrar quién puede aprobar, qué se aprobó y qué puede hacer el agente después de la decisión. Si la aprobación existe solo en una transcripción de chat, no es una aprobación. Es una nota.
3. Registro de auditoría. Cada paso significativo debe registrarse: ticket leído, herramienta llamada, acción en borrador creada, aprobación solicitada, acción ejecutada, error generado, traspaso realizado. El registro debe ser consultable, no solo visible en una consola. Si no puedes reconstruir la secuencia después de los hechos, no puedes defenderla en una revisión de soporte, una revisión de seguridad o una disputa con un cliente.
4. Recuperación ante fallos. Las escalaciones se rompen. Una herramienta agota el tiempo de espera, un servicio devuelve una carga incorrecta, una verificación de política falla o el modelo produce un borrador inseguro. El framework debe tener una ruta definida: reintentar, recurrir a un respaldo, pausar, escalar o traspasar. No debe continuar en silencio. No debe fingir que el paso tuvo éxito. Debe hacer que el fallo sea visible y recuperable.
5. Evidencia de traspaso. Cuando una persona toma el control, debe recibir un paquete, no un misterio. El paquete debe incluir el contexto del ticket, las acciones ya realizadas, las aprobaciones ya recibidas, los errores encontrados y el siguiente paso recomendado. Si la persona tiene que desplazarse por registros crudos para entender qué pasó, el traspaso no está listo.

Puntúa cada etapa de la misma manera: aprobado, parcial o no aprobado. Un aprobado significa que el framework puede mostrar la evidencia en un flujo de trabajo real. Un parcial significa que puede mostrar parte de ella, pero necesitarías trabajo personalizado para hacerlo confiable. Un no aprobado significa que el framework te está vendiendo una historia en lugar de un sistema.

Cómo ejecutar la prueba

Construye un escenario de escalación antes de comparar frameworks. Mantenlo lo suficientemente pequeño para ejecutarlo rápidamente, pero lo suficientemente real para forzar las partes difíciles. Un buen escenario tiene una solicitud de un cliente, una llamada a una herramienta, una verificación de política, una aprobación, un fallo y un traspaso. No uses un ejemplo trivial. Usa un ticket que se parezca al trabajo que tu equipo maneja realmente.

Ejecuta el mismo escenario en cada framework. Haz las mismas preguntas después de cada ejecución:

• ¿Dónde está el estado del ticket en cada paso?
• ¿Qué herramientas se llamaron y qué devolvieron?
• ¿Dónde está la solicitud de aprobación y en qué estado se encuentra?
• ¿Qué muestra el registro de auditoría después de un fallo?
• ¿Qué recibe la persona cuando el agente traspasa?

No dejes que el proveedor responda con un diagrama. Pide el artefacto: la entrada del registro, el objeto de estado, el registro de aprobación, la carga de traspaso. Si el artefacto falta, la capacidad falta. Si existe pero es difícil de inspeccionar, el framework puede ser utilizable, pero necesitará trabajo operativo.

Luego compara los frameworks con la misma evidencia. Un framework que puede ejecutar el camino feliz pero no puede mostrar el estado de la aprobación no es más seguro que un modelo más débil con un mejor plano de control. Un framework que puede recuperarse de una llamada fallida a una herramienta y preservar la pista de auditoría es más valioso que uno con más integraciones. Elige el framework que pueda demostrar que la escalación ocurrió de la manera en que tu equipo necesita que ocurra.

Antes de comprometerte, vuelve a ejecutar el ticket. No la demostración. El ticket. Si el framework puede mostrar la escalación de varios pasos moviéndose por herramientas, aprobaciones y registros de auditoría sin evasivas, está listo para producción. Si no, déjalo en el laboratorio. Tus clientes necesitan un sistema que pueda explicarse a sí mismo.