Streaming Agents: agentes que ejecutan dentro del flujo de datos

La forma habitual de construir un agente es como un servicio: recibe una petición, consulta lo que necesita, razona y responde. Es el modelo que heredamos de las aplicaciones web y funciona bien cuando alguien pregunta algo.

Hay una segunda forma, menos conocida, que cambia dónde vive el agente: en lugar de ser un servicio al que se le pregunta, el agente es un proceso que ejecuta dentro del flujo de eventos. Nadie lo invoca. Se activa cuando ocurre el evento que le corresponde atender.

La diferencia no es de infraestructura

A primera vista parece una decisión de despliegue. En la práctica cambia tres cosas de fondo.

El agente deja de pedir contexto. Un agente-servicio, cuando necesita saber el historial de un cliente, hace una consulta y espera. Un agente que corre dentro del flujo ya tiene ese estado a mano, porque el motor de procesamiento lo viene manteniendo con cada evento que pasó. La diferencia entre consultar y tener suele ser de cientos de milisegundos por decisión, que a volumen de producción no es un detalle.

El agente reacciona en lugar de esperar. Un servicio no hace nada hasta que alguien lo llama. Eso significa que el proceso solo empieza cuando un humano o un sistema decide iniciarlo. Cuando el agente vive en el flujo, el disparador es el hecho mismo. La degradación de red no espera a que el cliente llame para que alguien la mire.

El agente escala como escala el flujo. El motor ya sabe repartir el trabajo por partición y garantizar que los eventos de una misma entidad los procese la misma tarea. Ese es exactamente el reparto que un agente con estado necesita, y viene resuelto.

Qué se gana en trazabilidad

Hay un beneficio menos obvio que en sectores regulados suele ser el decisivo.

Cuando el agente ejecuta dentro del flujo, tanto los datos que vio como la decisión que tomó son eventos en el mismo registro. Eso permite algo que con un agente-servicio es muy difícil: reproducir el caso. Se puede volver a la posición exacta del flujo, correr la versión del agente que estaba vigente ese día y ver por qué decidió lo que decidió.

Con un agente-servicio esa reconstrucción exige haber registrado por separado la petición, la respuesta de cada sistema consultado y la versión del modelo, y confiar en que los tres registros cuadren. Casi nunca cuadran.

Cuándo no conviene

Este patrón no reemplaza al agente conversacional, y forzarlo donde no corresponde es un error caro.

No conviene cuando la interacción la inicia una persona. Si el caso de uso es alguien escribiendo en un chat, el agente-servicio es la forma correcta.

No conviene cuando el razonamiento es largo y de muchos pasos. Un flujo de eventos está optimizado para procesar mucho con baja latencia. Un agente que va a hacer quince llamadas a herramientas y tardar cuarenta segundos no encaja en ese modelo, y meterlo ahí genera contrapresión aguas arriba.

No conviene cuando el volumen es bajo. Si son cien eventos al día, la complejidad operativa no se justifica.

El criterio práctico: si el disparador es un hecho del negocio, el volumen es alto y la decisión tiene que salir rápido, el agente va en el flujo. Si el disparador es una persona y el razonamiento es abierto, va como servicio.

Los dos conviviendo

En la mayoría de las implementaciones reales terminan operando los dos, y esa es la arquitectura sana.

El agente en el flujo hace el trabajo continuo: evalúa cada transacción, mantiene el contexto actualizado, detecta lo que se sale de lo normal y dispara la acción cuando corresponde. El agente conversacional atiende a la persona, y cuando necesita saber el estado del negocio consulta el contexto que el primero viene manteniendo.

Puesto de otro modo: uno construye la verdad sobre el presente, el otro la explica. Es una división de trabajo bastante más limpia que pedirle a un solo agente que haga ambas.

Por dónde empezar

Si ya tienes una plataforma de eventos operando, el primer caso suele ser el más aburrido a propósito: tomar una regla que hoy corre por lotes y moverla al flujo, sin agentes de por medio. Eso valida el modelo de estado, el dimensionamiento y la operación.

Con eso funcionando, agregar razonamiento sobre ese mismo flujo es un paso incremental y no un salto. El error más común que vemos es el inverso: empezar por el agente y descubrir después que la plataforma de datos que necesitaba no estaba lista.