¿Es el agente el producto? Copilot Studio sugiere que el producto es todo el proceso

Cuando una empresa aprueba un agente de IA, ¿qué está aprobando exactamente?

La respuesta habitual trata al agente como la unidad. Recibe una revisión de diseño, un conjunto de evaluaciones, una aprobación de seguridad y un lanzamiento. La última actualización de Copilot Studio de Microsoft, publicada el 7 de octubre por Jason Moore, vicepresidente de producto, presiona esa suposición, porque lo que ayuda a los equipos a construir ya no es un agente. Es un proceso con un agente dentro.

Tres tipos de lógica en un solo lugar

La idea central de la actualización es que los creadores pueden “construir aplicaciones, flujos de trabajo y agentes en un solo lugar”. El propio ejemplo de Microsoft es el onboarding de empleados: una aplicación proporciona a los gerentes y empleados una interfaz estructurada, los flujos de trabajo ejecutan los pasos repetibles de incorporación, y un agente responde preguntas. En palabras del artículo, los equipos pueden reunir “la interfaz que las personas usan, los flujos de trabajo deterministas en los que el negocio puede confiar, y los agentes que razonan, se adaptan y actúan”.

Las piezas se lanzan con diferentes niveles de madurez:

• Aplicaciones, generadas a partir de una descripción y refinadas en conversación con acceso al código, están en versión preliminar pública.
• Copilot Managed Runtime, que analizamos cuando se anunció como la parte difícil de operar aplicaciones creadas con IA, sigue en versión preliminar pública. Ahora cubre aplicaciones de Copilot Studio, Copilot Cowork y Copilot Code, con alojamiento operado por Microsoft, identidad, acceso a datos gobernado, gestión del ciclo de vida y versionado respaldado por Git.
• Hooks para agentes, a través del harness de GitHub Copilot, están en versión preliminar. Ejecutan lógica determinista en puntos del ciclo de vida de un agente, como el inicio de sesión, las llamadas a herramientas y los errores. La redacción de Microsoft es precisa: “Mientras que un flujo de trabajo define la lógica a ejecutar, un hook determina cuándo se ejecuta esa lógica”.
• La integración con Foundry IQ, para bases de conocimiento reutilizadas entre agentes con redes privadas, está en disponibilidad general (GA).
• El panel de revisión, que muestra bloqueadores y advertencias, incluidas las advertencias de evaluación, antes de publicar, está en disponibilidad general (GA).

Donde se rompe la visión del agente como producto

Si la solución es una aplicación, un conjunto de flujos de trabajo y un agente, muchos fallos no vivirán dentro de ninguno de ellos. Vivirán en los puntos de unión. Un agente pasa el ID de empleado incorrecto a un flujo de trabajo. Un flujo de trabajo devuelve un error y el agente le dice al usuario que tuvo éxito. Una aplicación muestra el borrador del agente como si fuera el registro aprobado.

Una evaluación que solo mira la conversación del agente se pierde los tres. Por eso, la línea más trascendental de la actualización es una breve: las evaluaciones en Copilot Studio “se están expandiendo más allá de las conversaciones de agentes hacia la automatización”.

Los nuevos evaluadores se corresponden con esos puntos de unión. Task Completion verifica si se alcanzó el resultado previsto, no si la respuesta sonó bien. Tool Accuracy verifica si el agente eligió las herramientas esperadas y pasó las entradas esperadas, que es exactamente donde un agente hace el traspaso a un flujo de trabajo determinista. Safety y las verificaciones de latencia se sitúan junto a ellos, y una biblioteca de evaluadores personalizados se puede reutilizar entre agentes. Microsoft no indica un estado de lanzamiento para cada una de estas funciones de evaluación, así que verifíquelas en su tenant antes de planificar en torno a ellas.

Determinista donde el negocio confía en ello

La actualización también confirma una regla de diseño que extrajimos del sistema de cuentas por pagar de Snowflake: mantener las partes deterministas como deterministas. Los hooks son una forma de hacerlo cumplir desde dentro de la ejecución de un agente. Una verificación en cada llamada a herramienta puede validar parámetros contra la política antes de que se ejecute un flujo de trabajo. Un hook en errores puede enviar un fallo a una ruta definida en lugar de dejar que el agente improvise una explicación. Ambas son decisiones de diseño que los equipos tomarán, no valores predeterminados que Microsoft proporcione.

Un detalle más merece atención: un nuevo rol Evaluation Viewer permite a los revisores y otros stakeholders ver los resultados de la evaluación. Eso pone la evidencia frente a la persona que es dueña del proceso de negocio, no solo la persona que construyó el agente. Como argumentamos sobre la observabilidad de agentes más allá del uptime, un sistema que devuelve un código de éxito todavía puede estar equivocado, y las personas mejor situadas para detectarlo son las que saben cómo se ve lo correcto.

El cambio práctico está en lo que se aprueba. Los casos de prueba deben comenzar donde comienza una persona, en la aplicación, y terminar donde cambia el registro del negocio, en el sistema en el que escribe el flujo de trabajo. La precisión de las herramientas debe calificarse en cada flujo de trabajo que el agente puede llamar. Y los compromisos de producción deben basarse en las partes que están en disponibilidad general hoy, no en las versiones preliminares que las rodean. El agente es un componente. Lo que el negocio aprueba, y lo que un auditor eventualmente muestreará, es el proceso.