Un agente que completa una demostración no necesariamente está preparado para sobrevivir a una interrupción. Cuando el proceso se reinicia, interesa recuperar el trabajo pendiente y comprobar que una acción externa no se haya ejecutado dos veces.
La guía de Dan Taylor publicada por Microsoft el 24 de septiembre de 2026 reúne ejemplos de ejecución resiliente en Agent Framework. Este artículo se centra en una distinción práctica: recuperar el flujo y evitar efectos duplicados son responsabilidades relacionadas, pero diferentes.
Qué aporta un checkpoint
Un checkpoint conserva un punto de avance desde el cual continuar. El alojamiento mediante el protocolo Responses permite ejecutar workflows en segundo plano con estado persistido. La recuperación necesita reconstruir el workflow y mantener identidades de ejecutores compatibles. No convierte automáticamente cada operación externa en una transacción ejecutada una sola vez.
Dos ejemplos oficiales para comenzar
El ejemplo Python utiliza una cuenta regresiva para hacer visible el progreso. Incluye verify_resiliency.py: inicia el servidor, provoca una caída, reinicia y verifica el resultado recuperado. El script limpia estado anterior; debe ejecutarse con almacenamiento dedicado a la prueba. El README también documenta una particularidad de los archivos de bloqueo en Windows.
El ejemplo .NET incorpora un servicio HTTP independiente con SQLite. Una clave formada por ámbito e identificador de operación permite recuperar el resultado almacenado de una solicitud repetida. El README lo limita expresamente a una demostración local: no está pensado para producción ni para desplegar ese ejemplo en Foundry.
Repetir un paso no debe duplicar su efecto
Una caída puede ocurrir después de que un servicio complete una operación y antes de confirmar el avance del workflow. Al recuperar, el paso puede repetirse. El ejemplo .NET protege el registro mediante su clave; eso no hace atómica una llamada a otro sistema colocada junto a la escritura SQLite. La protección equivalente debe existir en el servicio que realiza la acción.
También conviene separar lo que ve el usuario de lo que ocurrió realmente: texto repetido en un stream recuperado no demuestra por sí solo una operación duplicada, ni una pantalla correcta demuestra que no exista.
Una prueba útil para equipos de desarrollo
Como propuesta de evaluación, preparar un entorno aislado y seguir esta secuencia:
- Fijar un commit y registrar las versiones de las dependencias.
- Ejecutar el ejemplo sin interrupciones para establecer el resultado esperado.
- Provocar una caída antes y después de una operación simulada.
- Reiniciar y comparar el estado final con los registros del servicio externo.
- Ejecutar dos trabajos independientes y comprobar que sus claves no se mezclan.
- Probar denegación de permisos, indisponibilidad del servicio y recuperación posterior.
El criterio de aceptación debería incluir trabajo completo, ausencia de efectos duplicados, aislamiento y trazabilidad. Estas pruebas propuestas complementan la demostración oficial.
Aplicación posible a Dynamics 365 Finance and Operations
Un primer caso podría ser un asistente que reúna evidencias de diagnóstico o prepare documentación mediante consultas de solo lectura. Posteriormente podría evaluarse la recuperación de validaciones prolongadas. Se trata de posibilidades de adaptación: los ejemplos no entregan una integración con D365FO ni autorizan operaciones sobre sus datos.
Requisitos y límites antes de adoptar
La guía de preparación Python requiere un proyecto Foundry, un modelo desplegado, autenticación Azure y las dependencias del ejemplo. Deben comprobarse los requisitos efectivos del commit elegido. El código tiene licencia MIT; conservar sus avisos no sustituye las licencias y costos de los servicios utilizados.
Para una solución empresarial hace falta definir permisos mínimos, protección y retención de checkpoints, tratamiento de datos sensibles, observabilidad y compatibilidad de versiones. No se debe asumir una garantía de soporte productivo por la existencia del ejemplo.
Recomendación editorial: probar. La documentación permite iniciar una evaluación reproducible. La adopción debe depender de los resultados de recuperación, seguridad e idempotencia sobre el proceso concreto. Este análisis es documental; no presenta resultados de una prueba propia en producción.
Fuente principal
Dan Taylor, Microsoft, 24 de septiembre de 2026: What’s new in Microsoft Agent Framework: Interactive experiences, memory, and resilient execution.