La programación inicia el agente.
¿Quién responde por el resultado?

En su anuncio del 24 de septiembre de 2026, Microsoft describe Routines como un servicio que reúne disparadores, acciones de agentes, identidad, conexiones e historial de ejecuciones en un proyecto de Foundry. La invocación y el uso de herramientas pueden realizarse con la identidad de quien crea la rutina o con la del agente. Un resumen posterior de novedades de Foundry muestra qué debe hacer una aplicación después de ese inicio. Su título hace referencia a septiembre, pero los metadatos indican que se publicó el 16 de octubre de 2026. Conviene leer ambos textos conjuntamente: el anuncio describe el servicio de ejecución; el resumen sigue el recorrido de un informe dentro de una aplicación.

Routines figura como disponible con carácter general; la herramienta de recordatorios que permite al agente programar una continuación sigue en versión preliminar. Ninguno de esos estados demuestra la fiabilidad de la entrega de principio a fin. El resumen señala expresamente que Routines no sustituye la coordinación de varios agentes ni los flujos de aprobación. Un disparador gestionado puede evitar mantener un programador independiente, pero la aplicación sigue siendo responsable de seguir las tareas aceptadas, conservar los resultados y gestionar los envíos de estado incierto.

El flujo de informes de cambios del resumen reparte el trabajo entre un agente que recopila pruebas de fuentes públicas y otro que prepara y entrega el informe. La aplicación guarda la tarea antes de confirmar su aceptación y ofrece vías separadas para consultar el estado y recuperar el resultado. Quien hace la llamada puede dejar de esperar sin perder la identificación de la tarea aceptada. En el traspaso, el receptor se hace cargo de su copia del informe y de su registro de entrega, sin suponer que puede acceder al almacenamiento privado del productor. Según el autor, la demostración del 13 de octubre entregó un informe guardado y permitió navegar dentro de la misma tarjeta. Después, el productor incorporó el comprobante de mensaje del receptor sin volver a enviarlo. Es un ejemplo útil de aplicación, pero se inició manualmente. Aunque el autor afirma que la programación del lunes está activada, la demostración completada no acredita una ejecución del lunes activada por calendario ni la fiabilidad sin supervisión en producción.

Microsoft describe la identidad del creador como un acceso delegado dentro de sus permisos, adecuado para herramientas con autenticación de usuario. La identidad del agente utiliza permisos configurados por separado en Microsoft Entra ID, y las herramientas se autentican mediante claves o identidad administrada. Compruebe esa elección en cada conexión real: una programación no concede acceso por sí misma. Registre quién aprueba el alcance de los permisos y quién puede desactivar la ejecución. Si se utiliza la identidad del creador, pregunte qué ocurre cuando esa persona deja la organización o cambian sus permisos. Si se utiliza la del agente, determine quién revisa los permisos y mantiene las conexiones. Son comprobaciones recomendadas de responsabilidad, no comportamientos del ciclo de vida demostrados en los artículos. Designe también a una persona responsable de la entrega para aprobar el destino y resolver los envíos ambiguos. De lo contrario, cada componente puede declarar que ha tenido éxito sin que nadie responda por el informe que falta.

Empiece por un informe de alcance definido. Examine el historial de disparadores e invocaciones para identificar qué inició el trabajo, cuándo y con qué identidad configurada; distinga los inicios manuales, por calendario y por eventos. Después, localice el registro persistente de aceptación, su identificador de tarea y un estado que pueda consultar más adelante. No basta con que una API responda que ha aceptado el trabajo si luego la aplicación no puede encontrarlo. Recupere a continuación el informe terminado y sus fuentes, manteniendo visibles las lagunas de cobertura. Una invocación completada no equivale necesariamente a un entregable terminado, y guardar un informe no demuestra que sea correcto. Por último, vincule el acuse de entrega con ese informe y el destino aprobado. Un comprobante de mensaje en un canal acredita la entrega, no la lectura ni la aprobación de una persona. Solicite pruebas independientes de la ejecución programada y ensaye casos de interrupción de tareas y pérdida del acuse. Son comprobaciones de aceptación propuestas, no pruebas realizadas para este análisis. Distinga un acuse de estado desconocido tanto de un fallo confirmado como de una entrega confirmada: reintentar un envío incierto puede generar un duplicado.