Despliega un agente de IA resiliente ante Outlook: detecta fallos, preserva el contexto y conmuta a canales alternativos

Microsoft reconoció problemas generalizados que afectaban a Exchange Online y otros servicios empresariales de Microsoft 365 el lunes por la tarde. Los informes de usuarios se centraron inicialmente en Outlook, pero el problema era más amplio que el cliente de Outlook. La página de estado de Microsoft informó de degradación del servicio para Microsoft 365 Business o Enterprise. Microsoft atribuyó la interrupción a un problema en una configuración central de autenticación utilizada por varios servicios de Microsoft 365. Microsoft advirtió de que la recuperación sería gradual y de que los escenarios aguas abajo, incluida la búsqueda, podrían seguir afectados. Downdetector registró miles de informes de usuarios sobre problemas de Outlook durante el incidente. Los mensajes de error compartidos sugerían un certificado interno caducado, aunque se planteó como una posible explicación.

Por qué el caso feliz no es suficiente

Un agente de IA que lee, redacta y envía correos puede parecer fiable en un entorno limpio. La ruta de fallo es donde se rompe. Si la Microsoft Graph API devuelve errores 401, 403, 429 o 5xx, el agente debe dejar de hacer suposiciones. Si la autenticación está degradada, el agente puede no poder demostrar su identidad, leer buzones, crear eventos de calendario o enviar mensajes. Si la búsqueda está afectada, el agente puede recuperar contexto obsoleto o perder mensajes anteriores. El operador necesita una respuesta determinista, no una suposición del modelo.

La preparación ante interrupciones es un control de ingeniería. Debe probarse antes del próximo incidente. El objetivo es evitar que el agente corrompa conversaciones con clientes, envíe mensajes dos veces, reserve reuniones en conflicto o escale a humanos sin un estado útil.

Lista de verificación de preparación ante interrupciones en cinco pasos

1. Detecta pronto los fallos de API y autenticación. Instrumenta todas las llamadas a Microsoft 365. Registra el punto final, el inquilino, el registro de aplicación, el estado HTTP, el número de reintentos, la latencia y el código de error. Trata 401 y 403 como fallos de autenticación o permisos. Trata 429 como limitación de velocidad. Trata 5xx como degradación del servicio. Usa un disyuntor después de fallos repetidos. Emite alertas por una tasa de errores en aumento, no por una sola solicitud incorrecta. Para flujos de trabajo de correo, supervisa por separado las operaciones de envío, lectura, búsqueda y calendario.
2. Clasifica la gravedad antes de actuar. Un 401 aislado puede ser un problema de actualización de token. Un 401 repetido en varios inquilinos o registros de aplicación puede ser un problema de configuración de autenticación. Un pico de 5xx en Exchange Online puede indicar degradación del servicio. Un fallo de búsqueda puede ser aguas abajo. Asigna niveles de gravedad: bajo para un usuario o un buzón, medio para un equipo o un flujo de trabajo, alto para impacto en todo el inquilino o entre servicios. El nivel de gravedad debe controlar si el agente se pausa, se degrada o conmuta.
3. Preserva el contexto de la conversación y la tarea. Antes de detener las acciones autónomas, persiste el estado del agente. Almacena la tarea actual, los mensajes ya leídos, el borrador ya compuesto, los elementos de calendario ya revisados, los destinatarios previstos y el último paso exitoso. Usa un almacén duradero fuera del proceso del agente. Si el agente no puede escribir en Microsoft 365, escribe en una base de datos interna, una cola o un almacén de objetos. Incluye una marca de tiempo y un código de motivo. Esto evita el reprocesamiento y ofrece a los operadores una transición limpia.
4. Enruta a canales de respaldo. Si el correo no está disponible, el agente no debe quedarse inactivo. Debe pasar a un canal alternativo que siga disponible. Las opciones incluyen un sistema de tickets interno, una página de estado, un webhook a un panel de operaciones, un mensaje seguro a un operador humano o una cola de reintentos diferidos. El respaldo debe llevar el contexto preservado. No debe pedir al cliente que repita información. Si el respaldo también está degradado, el agente debe detenerse y crear un registro mínimo del incidente.
5. Verifica la recuperación antes de reanudar las acciones autónomas. No reanudes basándote en una sola llamada exitosa. Ejecuta una sonda de recuperación. Confirma la autenticación, la lectura del buzón, la búsqueda, el envío y las operaciones de calendario. Revisa los efectos diferidos. Microsoft advirtió de que la recuperación puede ser gradual y de que los escenarios aguas abajo, incluida la búsqueda, pueden seguir afectados. Solo reanuda cuando la sonda supera la prueba y la tasa de errores sea estable. Luego, reproduce las acciones en cola en orden, con claves de idempotencia, para evitar duplicados.

Diseña el respaldo como un sistema de producción

El canal de respaldo es parte del producto. Necesita los mismos controles que la ruta principal. Usa claves de idempotencia para envíos y cambios de calendario. Usa registros transaccionales para transiciones de estado. Usa colas de mensajes muertos para acciones que no pueden reintentarse. Usa puertas de aprobación humana para acciones de alto riesgo, como envíos externos, mensajes relacionados con contratos o cambios de calendario que afectan a varias personas.

Para agentes de correo y calendario de Microsoft 365, la ruta de fallo mínima viable incluye: un punto final de salud, una taxonomía de errores, un almacén de estado, una cola de respaldo y una sonda de recuperación. El punto final de salud debe informar la última llamada exitosa, la tasa de errores actual y el estado activo del disyuntor. La taxonomía de errores debe mapear los fallos comunes a acciones del operador. El almacén de estado debe sobrevivir a reinicios del proceso. La cola de respaldo debe preservar el orden. La sonda de recuperación debe probar las mismas operaciones que el agente usa en producción.

Los operadores también deben probar la ruta de fallo. Simula tokens caducados, denegaciones de permisos, limitación de velocidad y degradación del servicio. Simula un fallo de búsqueda después de una lectura parcial. Simula un fallo de envío después de crear un borrador. Verifica que el agente se pausa, preserva el contexto, enruta al respaldo y reanuda limpiamente. La prueba debe ser repetible. Debe ejecutarse en un inquilino no de producción o en un entorno de pruebas con datos realistas.

Cuando ocurre una interrupción, el trabajo del operador es reducir la incertidumbre. El agente debe responder rápidamente a tres preguntas: ¿Qué falló? ¿Qué estado es seguro? ¿Cuál es la siguiente acción segura? Si el agente no puede responder a esas preguntas, debe detenerse. La próxima interrupción de Microsoft 365 no será un problema aislado de Outlook. Puede afectar a la autenticación, la búsqueda, el calendario o varios servicios a la vez. El agente que sobrevive es el cuya ruta de fallo se diseñó antes del incidente, no después.