Construyendo un pipeline de entrega seguro para agentes
La mayoría de las demostraciones de agentes omiten una pregunta vital. ¿Cómo permites que un sistema autónomo envíe cosas en tu nombre sin duplicar envíos o entregar trabajo no aprobado?
Un envío duplicado no es un error poco común. Es el comportamiento predeterminado de una cola simple cuando un trabajador falla a mitad de una tarea. Un trabajador envía un mensaje y luego falla antes de registrar el éxito. El sistema piensa que la tarea falló y le indica a un nuevo trabajador que lo intente de nuevo. El cliente recibe dos correos electrónicos y tú recibes un ticket de soporte.
No puedes prevenir cada fallo. Debes diseñar pensando en un fallo que ocurra en el intervalo entre la acción y el registro.
Utiliza este pipeline de seis etapas para cualquier salida de agente con consecuencias reales:
• Producir: El agente genera el artefacto completo. Aún no envía nada. • Persistir: Primero, escribe la intención y el artefacto en un almacenamiento duradero. • Calificar: Adjunta una puntuación de confianza a la salida. • Revisar: Dirige los elementos de baja confianza a un humano. • Aprobar: Utiliza una compuerta de fallo cerrado (fail-closed). El sistema bloquea todos los envíos a menos que un humano dé una autorización explícita. • Enviar y dar fe: Envía el elemento bajo un arrendamiento (lease), luego escribe un recibo de evidencia.
Cada etapa debe ser una transición duradera independiente. El estado reside en tu base de datos, no en la memoria de un trabajador.
Para evitar duplicados, utiliza el arrendamiento a nivel de fila (row-level leasing). En Postgres, usa SELECT ... FOR UPDATE SKIP LOCKED. Esto garantiza que solo un trabajador sea el dueño de una tarea a la vez.
La regla más importante es cómo manejas los arrendamientos expirados. Si un trabajador falla mientras envía un mensaje externo, no lo reintentes automáticamente. En su lugar, deja la tarea varada para revisión humana. Una tarea bloqueada visible es mejor que un envío duplicado invisible.
También debes seguir los principios de fallo cerrado (fail-closed):
- El envío está desactivado por defecto. Una única bandera (flag) debe habilitar todo el tráfico de salida.
- La identidad se verifica. El sistema debe verificar la dirección del remitente y la seguridad del transporte en el momento del envío.
- Todo deja un recibo. Un envío no registrado es un fallo.
No construyas esto para tareas de bajo riesgo como registros internos. Utilízalo cuando un error cueste dinero, cree un problema legal o requiera un ticket de soporte.
Comunidad de aprendizaje opcional: https://t.me/GyaanSetuAi