Agentes basados en eventos
1. ¿Qué es un agente basado en eventos?
Un agente basado en eventos (event-sourced agent) es un agente cuya lógica de negocio se construye sobre un flujo de eventos inmutable. En lugar de almacenar el estado actual del agente, se almacena una secuencia completa de eventos que representan todo lo que ha ocurrido. El estado actual se obtiene reproduciendo (replaying) esa secuencia.
Jonas Tempelstein y Misha (Iterate) presentan este enfoque como una alternativa a los agentes tradicionales basados en estado mutable. La idea central: cada acción del agente, cada llamada a herramienta, cada decisión intermedia, cada cambio de estado se registra como un evento inmutable en un log. Si algo falla, se puede reproducir el flujo de eventos para entender exactamente qué ocurrió.
El concepto no es nuevo en ingeniería de software (patrón event sourcing), pero su aplicación a agentes de IA es relativamente reciente. La naturaleza no determinista de los LLMs hace que la capacidad de reproducir decisiones sea especialmente valiosa: sin event sourcing, dos ejecuciones del mismo prompt pueden producir resultados diferentes y es imposible saber por qué.
2. Arquitectura del event-sourced agent
La arquitectura típica de un agente basado en eventos incluye: un stream processor (procesador de flujo) que consume eventos y produce nuevas acciones, un event store (almacén de eventos) que persiste la secuencia completa, y un harness (arnés) que envuelve al agente y gestiona el flujo de eventos.
Cuando el agente recibe una solicitud, se genera un evento «SolicitudRecibida». El agente procesa la solicitud y genera eventos intermedios: «HerramientaSeleccionada», «HerramientaEjecutada», «ResultadoObtenido», «DecisiónTomada». Cada evento incluye metadatos: timestamp, modelo utilizado, temperatura, contexto, etc. Al final, se genera un evento «TareaCompletada» o «TareaFallida».
El estado actual del agente se reconstruye proyectando los eventos relevantes. Si el agente se reinicia, reproduce los eventos desde el último checkpoint. Esto proporciona tolerancia a fallos, auditabilidad total y capacidad de depuración forense.
3. Ventajas frente a agentes tradicionales
Los agentes basados en eventos ofrecen ventajas significativas frente a los agentes tradicionales con estado mutable:
Auditabilidad completa: cada decisión del agente está registrada con su contexto. Se puede responder a preguntas como «¿por qué el agente llamó a esa API?» o «¿qué datos vio cuando tomó esta decisión?».
Reproducibilidad: dado el mismo flujo de eventos, se puede reproducir la ejecución exacta. Esto es imposible en agentes tradicionales no deterministas.
Tolerancia a fallos: si el agente se cae a mitad de una tarea, al recuperarse reproduce los eventos y continúa desde donde lo dejó, sin perder trabajo.
Depuración forense: los eventos permiten inspeccionar cada paso del agente, identificar dónde se desvió del comportamiento esperado, y entender las causas raíz de los fallos.
Pruebas retrospectivas: se pueden inyectar flujos de eventos reales en nuevas versiones del agente para ver cómo se comportaría con datos históricos.
4. Implementación con stream processors
La implementación práctica utiliza tecnologías de procesamiento de flujos como Apache Kafka, Apache Flink, o soluciones más ligeras como RabbitMQ con almacenamiento persistente. El harness del agente se conecta al stream processor, que gestiona el flujo de eventos.
El workshop práctico de Jonas y Misha demuestra cómo construir un harness básico: un loop que consume eventos del stream, los pasa al LLM para su procesamiento, y publica nuevos eventos con las acciones resultantes. El harness incluye manejo de errores, reintentos y checkpointing.
Un detalle importante: los eventos deben diseñarse con un esquema claro que incluya no solo la acción, sino también el contexto completo en el momento de la decisión (estado del agente, herramientas disponibles, input del usuario). Sin este contexto, la reproducción no será fiel.
5. Casos de uso y el futuro
Los agentes basados en eventos son especialmente valiosos en dominios donde la auditabilidad es crítica: finanzas (cada decisión de trading debe ser justificable), salud (cada recomendación debe ser trazable), cumplimiento normativo (cada acción debe estar registrada).
También son útiles en sistemas multi-agente complejos, donde múltiples agentes interactúan y es necesario rastrear quién hizo qué y cuándo. El flujo de eventos compartido permite reconstruir la secuencia completa de interacciones.
La tendencia futura apunta hacia la combinación de event sourcing con observabilidad: los eventos no solo sirven para reproducción, sino que alimentan dashboards en tiempo real, sistemas de alertas y análisis de comportamiento. El flujo de eventos se convierte en la fuente única de verdad (single source of truth) para todo el sistema de agentes.
Fuentes
- Jonas Tempelstein & Misha, Iterate — «Make your own event-sourced agent harness using stream processors» (AI Engineer). Duración: 1:04:26. URL: https://youtu.be/vi-2nasppAg
Atribución: Este artículo adapta material del workshop de Jonas Tempelstein y Misha (Iterate) en el canal AI Engineer.
Artículos relacionados
Recursos en línea
Ver también: PARTE 3: La Habana 1762: cuando la logística falló | Viento en las velas: cómo la Royal Navy venció al escorbuto. Fuente: Agentes basados en eventos.
Deja una respuesta