LAS IDEAS CLAVE
- 01
Una respuesta perdida puede ocultar una operación ya completada.
- 02
La misma operación debe conservar su identidad y contar con deduplicación efectiva en el destino.
- 03
Los resultados inciertos necesitan conciliación; la demostración debe incluir interrupciones y solicitudes repetidas.
El trabajo continúa; la conexión puede interrumpirse
Un agente que registra pedidos necesita distinguir entre una operación rechazada y una operación cuyo resultado desconoce. Repetir automáticamente ambas puede crear duplicados. Esta guía propone evaluar la recuperación de una tarea antes de delegarla: conservar su identidad, comprobar qué ocurrió en el sistema de destino y resolver las situaciones inciertas.
El 25 de septiembre de 2026, Microsoft presentó nuevas capacidades de Copilot, entre ellas Autopilot, descrito como un agente persistente que puede realizar trabajo recurrente y retomar proyectos. La compañía indicó que ampliará su vista previa privada al final de septiembre. El anuncio muestra la dirección de su oferta, pero no implica disponibilidad general para empresas chilenas ni prueba cómo funcionaría una integración particular. Microsoft, presentación de Home, Code y Autopilot.
El pedido que existe aunque nadie haya recibido respuesta
Imaginemos un distribuidor chileno con un agente que registra solicitudes aprobadas en su ERP. Es un ejemplo hipotético, sin relación con un cliente ni con una función específica de Copilot. El ERP acepta un pedido, pero la conexión se interrumpe antes de devolver su número. Si el agente interpreta el silencio como rechazo y envía otra creación, la bodega podría recibir dos instrucciones.
La documentación de Temporal describe este tipo de riesgo: una actividad puede completar su efecto externo y repetirse si el proceso cae antes de comunicar el resultado. Su modelo de ejecución admite al menos un intento y posibles repeticiones. Guardar el progreso de un flujo, por sí solo, no demuestra que una acción externa haya ocurrido una única vez. Temporal, manejo de errores e idempotencia.
Una identidad estable para la misma operación
La idempotencia permite repetir una solicitud sin repetir su efecto. AWS documenta un patrón para servicios que aceptan claves de idempotencia: mantener la misma clave entre intentos y apoyarse en la deduplicación del destino. La condición importa: agregar un identificador al mensaje no protege una operación si el receptor no lo reconoce y aplica. AWS, idempotencia y reintentos.
En el ejemplo del distribuidor, proponemos asignar una referencia a la solicitud aprobada y conservarla durante su recuperación. Un segundo pedido legítimo necesita otra identidad, aunque incluya los mismos productos. Antes de contratar la integración, conviene pedir que se documenten la vigencia de esa referencia y la respuesta ante dos solicitudes simultáneas o ante una misma clave con contenido diferente.
El estado incierto necesita una salida visible
Nuestra recomendación es que la interfaz distinga pedido confirmado, rechazo confirmado y resultado pendiente de comprobar. En el tercer caso, el agente debería conservar la referencia y buscar evidencia en el sistema de destino según las capacidades de la integración. Una consulta vacía no siempre basta para autorizar otra creación: la primera solicitud podría seguir procesándose.
Si el ERP no ofrece una forma confiable de deduplicar o confirmar el resultado, proponemos detener la repetición automática de esa acción y abrir un caso de conciliación. El operador necesita ver qué se intentó, cuándo y con qué datos. Esta restricción debe aparecer en el alcance del proyecto, junto con el responsable de resolverla. El mensaje al usuario también debe reconocer que la confirmación sigue pendiente.
Decidir qué errores admiten un nuevo intento
Temporal diferencia fallas transitorias, límites de consumo y errores permanentes, como entradas inválidas. Esa distinción permite configurar esperas y decidir cuándo un reintento no resolverá el problema. Temporal, políticas según el tipo de falla.
Como criterio de compra, sugerimos pedir una política por acción: condición para repetir, límite de espera y destino de los casos que exceden ese límite. Un producto inexistente requiere corregir la solicitud; repetirlo no agrega información. Una interrupción de red exige además comprobar si la escritura pudo completarse. La respuesta debe depender del estado verificable del proceso, no de que el agente redacte una explicación convincente.
La prueba que debería incluir la demostración
Proponemos probar en un entorno controlado tres situaciones: interrumpir la respuesta después de aceptar el pedido, reiniciar el proceso mientras espera y entregar dos veces la misma solicitud aprobada. Para cada escenario, el equipo debería mostrar los registros del destino y explicar si terminó con un pedido confirmado o con un caso pendiente de conciliación. Contar mensajes exitosos en el chat no sustituye esa comprobación.
La aceptación también debe incluir un pedido nuevo y legítimo, para verificar que la protección no bloquee operaciones distintas. Sugerimos registrar duplicados, resultados inciertos y tiempo de resolución, sin convertir una prueba pequeña en garantía universal. Estas comprobaciones complementan la guía sobre evaluar cambios de modelo de IA: aquí se evalúa la integración cuando la comunicación falla.
Qué pedir antes de conectar un agente al negocio
Una empresa puede comenzar con una acción concreta, como registrar un pedido aprobado, y exigir cuatro entregables: definición de identidad, estados posibles, política de recuperación y evidencia de las pruebas. Recomendamos acordarlos entre operaciones y tecnología antes de ampliar el alcance. Así se puede discutir qué parte del proceso quedará automatizada y qué excepciones seguirán necesitando atención.
Para un proyecto de automatización con IA, proponemos incluir la recuperación dentro del diseño inicial y del soporte. La decisión de delegar trabajo será más sólida cuando el equipo pueda reconstruir una operación interrumpida y explicar cómo evita repetir sus efectos.
CON TEXTO Y CONTEXTO
Fuentes y referencias
- Introducing the new Copilot with Home, Code and AutopilotMicrosoft · 2026-09-25
- Error handling — Python SDKTemporal
- Idempotency and retries — AWS Durable Execution SDK Developer GuideAmazon Web Services
Contenido elaborado con asistencia de IA a partir de las fuentes enlazadas. Las recomendaciones corresponden al análisis editorial de Digital Dev. Cómo elaboramos y corregimos nuestros artículos.