Ingeniería de IA
Agentes proactivos: programar el aviso es la parte fácil
Cómo construir agentes proactivos con tareas programadas, identidad y memoria. Un ejemplo de CI para avisar ante cambios útiles sin repetir notificaciones.
El agente puede empezar sin que abras el chat
Un agente proactivo se activa por una programación o un evento, revisa una situación y decide si hay algo que hacer. El salto útil está en conservar el objetivo entre ejecuciones y comunicar solo lo que merece atención. Repetir una consulta cada diez minutos puede producir mucho texto y poca ayuda.
LangChain publicó el 28 de octubre una explicación de este patrón con tareas cron en Managed Deep Agents. El programador inicia una ejecución con un prompt; el agente puede revisar información, preparar un seguimiento o gestionar otras tareas mediante herramientas. Es una forma de organizar componentes conocidos, no una arquitectura que se haya convertido de pronto en estándar.
Managed Deep Agents está en beta pública en LangSmith Cloud. La posibilidad de ejecutar sin un mensaje nuevo no implica que el modelo piense continuamente ni que mantenga por sí solo todo el estado necesario.
Horario, identidad y memoria son decisiones distintas
Una tarea de las nueve de la mañana necesita una zona horaria. La guía de Managed Deep Agents admite una zona IANA para los cron y usa UTC cuando se omite. También distingue tareas que ejecutan como la persona autenticada de aquellas que usan la identidad de servicio del agente.
El hilo es otra elección. Las programaciones declaradas crean por defecto un hilo efímero por ejecución; conservar estado de conversación exige elegir un hilo persistente existente. Eso es distinto de guardar datos útiles entre hilos: en LangGraph, los checkpoints conservan el estado de un hilo y los stores permiten almacenar información con un ámbito más amplio.
Para un monitor de incidencias, el dato importante puede ser el último fallo revisado, el aviso ya enviado y la persona responsable. No hace falta arrastrar al modelo todas las conversaciones anteriores para recordar esas tres cosas.
Cuatro revisiones no tienen por qué generar cuatro avisos
En un seguimiento propuesto de CI, la tarea consulta el estado del pipeline y una firma estable del fallo. Si encuentra el mismo error que ya comunicó, guarda la revisión y permanece en silencio. Si aparece otro fallo o se recupera el pipeline, prepara una actualización.
La tabla aplica esa regla a cuatro revisiones ficticias. El modelo puede explicar un error nuevo a partir de sus logs; la comparación del estado y la detección de duplicados pueden resolverse antes con código. Así no necesitas pedir otra interpretación de la misma información en cada despertar.
| Revisión | Estado observado | Decisión propuesta |
|---|---|---|
| Primera | Fallo A, todavía sin comunicar | Analizar y avisar. |
| Segunda | Continúa el fallo A | Registrar la revisión, sin repetir el aviso. |
| Tercera | Aparece un fallo B | Explicar qué ha cambiado. |
| Cuarta | Pipeline recuperado | Cerrar el seguimiento con una actualización. |
Crear otra tarea también necesita límites
Managed Deep Agents permite exponer herramientas para crear, consultar, modificar o borrar programaciones. El agente solo accede a las operaciones que tú expones. Esto permite ofrecer un recordatorio puntual sin darle necesariamente capacidad para gestionar todas las tareas del sistema.
En el diseño de la aplicación conviene añadir también caducidad, responsables y un criterio de parada. «Vigila este despliegue hasta que termine» debería dejar de generar trabajo cuando ya terminó. Si desaparece el permiso para consultar sus datos, la ejecución necesita detenerse o pedir que se resuelva el acceso, en lugar de seguir con información antigua.
La entrega de resultados merece una comprobación separada. Si un aviso se envía pero se pierde la confirmación, reintentarlo a ciegas puede duplicarlo. Un identificador de la acción y un registro consistente permiten reconocer ese mismo envío cuando el sistema receptor admite un contrato idempotente.
Medir avisos útiles, además de ejecuciones
Al crecer el número de tareas, el horario se vuelve una decisión de capacidad. Concentrarlas todas al empezar la hora crea ráfagas de consultas y llamadas al modelo. Dispersarlas ligeramente con jitter ayuda a repartir esa carga cuando el plazo de la tarea lo permite; los reintentos también necesitan espera y límites.
Para el seguimiento de CI mediría cuánto tarda en detectar un cambio relevante, cuántos avisos repite y cuántos necesitan una corrección humana. También comprobaría qué sucede si llega otra ejecución mientras la anterior sigue activa. El contador de tareas completadas no revela por sí solo si el sistema está ayudando.
Hay trabajos que encajan mejor con un cron y otros con un evento que ya emite el sistema. Un análisis diario puede esperar al horario elegido; un cambio de estado de CI puede activar la revisión directamente. En ambos casos, la información nueva, los permisos y la condición de cierre deberían decidir el siguiente paso.