Un agente empresarial debe sobrevivir a un reinicio sin pagar dos veces. El SDK de Go duradero de AWS ya es GA

Un agente de cuentas por pagar lee una factura, la empareja con una orden de compra, pide a un gerente que apruebe una excepción y, una vez aprobada, activa el pago. El gerente aprueba el lunes. El lunes por la noche, el proceso que aloja al agente se reinicia. Cuando vuelve, ¿qué recuerda el agente? Si la respuesta es “nada”, comienza de nuevo desde la factura. Si el paso de pago ya se había ejecutado, el proveedor cobra dos veces.

Ese fallo no tiene nada que ver con lo inteligente que sea el modelo. Es una propiedad del entorno de ejecución, y es la razón por la que el anuncio del 15 de octubre de AWS importa a cualquiera que ponga agentes en procesos de negocio: el SDK de ejecución duradera para Go de Lambda ya está en disponibilidad general.

Qué proporciona la ejecución duradera

Las funciones duraderas permiten que un flujo de trabajo conserve su progreso a través de interrupciones. El SDK de Go, ahora en GA, ofrece:

• Pasos con checkpoints automáticos, para que el trabajo completado se registre y no se repita tras un reinicio;
• Callbacks para flujos de trabajo con human-in-the-loop (aprobación humana) y agent-in-the-loop, para que un proceso pueda esperar una aprobación sin consumir cómputo;
• Invocación duradera para el encadenamiento fiable de funciones;
• Esperas que suspenden la ejecución hasta por un año mientras esperan un evento externo.

AWS también incluye un paquete durabletest para probar flujos de trabajo completos localmente, sin acceso a red ni credenciales, y un analizador durablelint que señala código que podría comportarse mal cuando un flujo de trabajo se reanuda. La disponibilidad regional y los precios siguen las propias páginas de Lambda. Esta disponibilidad general se aplica específicamente al SDK de Go, y una espera suspendida de hasta un año no significa cómputo en ejecución durante un año.

Por qué los agentes lo necesitan más que los flujos de trabajo ordinarios

Los motores de flujos de trabajo clásicos ofrecen durabilidad desde hace años. Los agentes lo hacen más urgente por tres razones:

1. Se ejecutan durante mucho tiempo. Las tareas de los agentes abarcan de minutos a días, lo cual es tiempo suficiente para que ocurran despliegues, reinicios y timeouts en medio. Escribimos sobre probar qué sucede en la hora tres de una ejecución larga de un agente; la durabilidad decide si la hora tres puede reanudarse.
2. Esperan a personas. Las puertas de aprobación son donde los agentes empresariales pasan la mayor parte de su tiempo de reloj. Un diseño que mantiene un proceso vivo mientras un gerente está de vacaciones es frágil y costoso. Un callback que reanuda el flujo de trabajo cuando llega la aprobación no es ni lo uno ni lo otro.
3. Sus pasos no son deterministas. Reproducir una llamada al modelo después de un reinicio puede producir una respuesta diferente a la que se aprobó. La ejecución duradera registra el resultado del paso con checkpoints, para que el flujo de trabajo continúe desde lo que realmente se decidió, no desde una suposición nueva.

Lo que el SDK no hace por usted

La durabilidad es necesaria y no suficiente. Tres responsabilidades de diseño permanecen en el equipo:

• Acciones idempotentes. Un checkpoint registra que un paso finalizó. Si el proceso muere después de que la API de pago aceptó la solicitud pero antes de que se guardara el checkpoint, el paso puede ejecutarse de nuevo. Use claves de idempotencia en cada llamada consecuente, para que una repetición sea reconocida e ignorada por el sistema de registro.
• Autorización al reanudar. Una aprobación concedida el lunes puede no ser válida el viernes: el aprobador puede haberse ido, el monto puede haber cambiado, los permisos del agente pueden haber sido revocados. Vuelva a verificar la autoridad cuando termina una espera larga. Este es el problema de la autorización temporal en otra forma.
• Compensación. Algunos pasos no se pueden deshacer, solo revertir con otra acción. Defina el paso compensatorio para cada acción consecuente antes de que el flujo de trabajo se despliegue, que es también lo que convierte un freno de emergencia en un plan de incidentes.

Dónde encaja en una arquitectura de agentes

El patrón que vale la pena adoptar es una división: el modelo decide dentro de un paso, y el flujo de trabajo duradero decide qué sucede entre pasos. Las llamadas al modelo se envuelven como pasos con checkpoints; las aprobaciones son callbacks; las acciones consecuentes son llamadas idempotentes al sistema de registro; y el flujo de trabajo, no el modelo, mantiene el estado del proceso.

El SDK de AWS es una implementación, y no es una plataforma de agentes general. Temporal, Step Functions y otros motores de flujos de trabajo ofrecen garantías similares. La elección del motor importa menos que la decisión de tener uno. Un agente que mantiene su progreso en la ventana de contexto del modelo pagará la factura dos veces, tarde o temprano.