Diseño de agentes de IA ambientales: canales de activación, modo de inactividad económico y despertares seguros.
Cómo crear agentes de IA basados en eventos que permanezcan inactivos de forma económica: triaje por capas antes de cada llamada al modelo, reconstrucción segura del estado activo, manejo de situaciones críticas y asignación eficiente de recursos.
Fuentes: The Idle Agent: Designing Ambient, Event-Driven Systems That Wait Well
La mayoría de los escritos sobre agentes de IA parten del momento en que llega una solicitud y comienza a funcionar el bucle. Un agente ambiental, aquel que monitorea por sí mismo bandejas de entrada, colas y paneles de control, pasa casi todo su tiempo en un estado opuesto: no está ocurriendo nada, y el sistema debe decidir una y otra vez si acaba de comenzar algo. Esta guía trata sobre ese tiempo ocioso. Al final, podrás diseñar la capa que decide cuándo se activa un agente, mantener el costo de su inactividad casi en cero, garantizar que cada activación esté libre de duplicados, obsolescencia e inyecciones, y medir si todo este sistema realmente ayuda a las personas a quienes interrumpe.
Un escenario de advertencia: pagar por cada “no”
Imagínese un equipo que crea un agente para monitorear su bandeja de entrada de soporte y su canal de atención prioritaria. El objetivo es sencillo: identificar cualquier cosa que requiera intervención humana antes de que alguien se dé cuenta. El prototipo resulta impresionante en las demostraciones. Luego llega la primera factura mensual, y su monto supera el costo combinado de las licencias de IDE del equipo, los minutos de CI y las herramientas de observabilidad, para un agente que realizó aproximadamente once acciones útiles en treinta días.
La razón es una arquitectura que nadie anotó por escrito. Para “vigilar” la bandeja de entrada, se ejecutaba una tarea programada cada dos minutos que recopilaba los mensajes recientes y consultaba a un modelo especial si alguno requería atención. Durante ese mes, esto ocurrió unas veintidós mil veces. Casi todas las respuestas fueron un “no” bien razonado. Las once respuestas “sí” fueron excelentes, pero la situación general estaba dominada por los negativos. Lo más costoso que hacía el sistema, con una diferencia de unas tres órdenes de magnitud, era confirmar que nada había cambiado.
En otra parte de la misma infraestructura existía una antigua tarea cron que verificaba un umbral en el disco cada minuto. A lo largo de su existencia, prácticamente no costó nada. La diferencia es la lección de todo este tema: esperar es algo que se diseña, no algo que ocurre por defecto.
La idea clave es la siguiente: un agente ambiental se define mucho más por lo que lo activa que por lo que hace una vez activado. La verdadera complejidad técnica radica en un mecanismo que decide, de la manera más económica posible, cuál de los miles de eventos entrantes merece la atención de un modelo, combinado con un estado inactivo que no cuesta nada hasta que se activa. Los agentes de chat nunca enfrentan este problema, porque una persona ya ha decidido si el mensaje vale la pena enviarlo antes de escribirlo. Si se elimina a esa persona del proceso de activación, la clasificación pasa a ser tu tarea. Si lo resuelves con el propio modelo grande, en esencia estarás contratando a tu especialista más caro para organizar los mensajes.
Esto se basa en algunas ideas que merecen un tratamiento aparte: la ejecución duradera (un proceso que puede permanecer activo durante días sin consumir recursos de cómputo), el anclaje temporal (lo que un agente debe volver a aprender sobre el “ahora” al despertar) y la deriva de objetivos en agentes de larga duración. Se tratan más abajo donde son relevantes.
Cada solicitud ya era un evento
Una petición de chat parece ser el punto de partida natural para un agente, pero oculta mucho trabajo invisible. La persona que la envió realizó tres acciones antes de que se procesara ningún token: decidió que la situación merecía una acción, lo cual es un proceso de triaje; la resumió en unas pocas frases, lo cual constituye la recopilación de contexto; y la envió en un momento específico, lo cual se refiere al control temporal. Un agente de chat es en realidad un agente que opera sobre una capa de eventos impulsada por un ser humano.
Los agentes ambientales, término popularizado por LangChain para referirse a aquellos que consumen un flujo de eventos y responden a él, posiblemente manejando varios eventos al mismo tiempo, eliminan la intervención humana. Los tres servicios gratuitos desaparecen. Lo que queda es un problema de ingeniería con cinco tipos distintos de entrada, cada uno con un comportamiento diferente:
- Mensajes. Una persona escribe al agente. Estos son raros, ya están filtrados por el juicio humano y contienen una intención clara. Este es el caso más sencillo.
- Horarios. Cron y todo lo que deriva de él. Un horario se dispara independientemente de si ocurrió algo o no. Esto es útil, ya que captura lo que los flujos de eventos pasan por alto, pero también es desperdiciado, porque la mayoría de las ejecuciones no generan respuesta alguna.
Diseñar un agente inactivo implica decidir cómo se componen estos elementos. ¿Cuál de ellos puede despertar al agente? ¿Qué hay entre la señal bruta y el modelo? ¿Qué reconstruye el agente sobre el mundo cuando se despierta? Cometer un error en una dirección da como resultado la situación descrita anteriormente, donde el modelo interpreta silencio cada dos minutos. Cometer un error en la dirección opuesta hace que el agente permanezca dormido durante todo el incidente que debería detectar.
El embudo de despertar: la triaje como una escalera
El hecho económico clave es que una llamada a un modelo representa la condición más costosa que se podrá escribir. Preguntarle a un modelo de frontera “¿esto es importante?” cuesta entre cinco y siete órdenes de magnitud más que un filtro de base de datos que responde a la misma pregunta con datos estructurados. Por lo tanto, la arquitectura de trabajo nunca es una línea directa desde el evento hasta el modelo; es un embudo: una serie de etapas, cada una más económica que la siguiente, y cada una descartando la mayor parte de lo que llega hasta ella.
Etapa uno: reglas estructurales
La primera etapa prácticamente no cuesta nada. Se trata de código sencillo que examina la estructura de un evento: su tipo, su remitente, sus etiquetas y el repositorio o cola de donde proviene. Las newsletters, las notificaciones automatizadas, los comentarios de bots y los eventos relacionados con proyectos que el agente no posee pueden enviarse aquí sin ningún tipo de evaluación. En una bandeja de entrada típica, una gran parte del tráfico bruto nunca necesita ir más allá. Si menos de la mitad de sus eventos brutos se descartan en esta etapa, es probable que sus reglas sean demasiado estrictas.
Segunda etapa: debounce y coalescencia
Los eventos llegan en oleadas que comparten una misma causa: docenas de correos electrónicos en un mismo hilo de conversación, una solicitud que contiene treinta cambios, cientos de alertas provenientes de un interruptor defectuoso. La unidad adecuada para que el agente preste atención no es el evento individual sino la situación que lo origina. Por eso, esta etapa establece un breve período de tiempo, agrupa los eventos entrantes según una clave de correlación como el hilo de conversación, la solicitud de integración o el incidente, y transmite una única señal combinada para cada situación.
También se necesita paciencia en esta etapa. Un documento que ha cambiado una vez es probable que lo haga varias veces más en los minutos siguientes. Si se activa después de un intervalo fijo desde el cambio más reciente y no desde el primero, se reduce significativamente la cantidad de activaciones, y cada una de ellas permite ver una imagen más completa. El mismo principio se aplica siempre que varios usuarios modifican un estado compartido: una ráfaga de cuarenta eventos suele describir un solo hecho.
Una nota sobre los monitores: consultar y comparar, nunca consultar y juzgar
Los monitores implican una decisión de costo que los otros mecanismos no tienen. Algo debe detectar el cambio, y existen exactamente tres formas de hacerlo:
- El origen envía la notificación. Un webhook o suscripción le informa cuando cambia el estado. Cuando esto está disponible, úselo.
La consulta periódica en sí merece una reputación mejor de la que sugiere ese escenario. La consulta es económica; lo costoso es el juicio. Una tarea programada que obtiene una página, la hashea y la compara con el hash anterior cuesta una cantidad insignificante al año. Muchos sistemas no ofrecen webhooks, por lo que la regla de “nunca hacer consultas” no es realista. La verdadera regla es que la consulta debe terminar con una diferencia, no con una llamada al modelo. Se toma una instantánea, se compara y solo los cambios detectados ingresan al proceso como eventos, donde enfrentan las mismas reglas y clasificador que todo lo demás. Si algo ha cambiado es una cuestión que resuelve la función de hash. Si ese cambio es importante es la pregunta para la cual se utiliza el modelo.
Etapa tres: clasificación económica
Lo que sobrevive a las reglas y al proceso de consolidación pasa a un modelo pequeño, rápido y económico con una instrucción deliberadamente específica, algo como “responda con una palabra: urgente, relevante o ignorar”. Se trata de la conocida cascada de enrutamiento de modelos aplicada a las alertas: el nivel económico absorbe la ambigüedad que las reglas fijas no podían expresar, y solo los resultados “relevantes” e “inciertos” avanzan a niveles superiores. Un modelo pequeño que tiene un 92% de acierto, frente a un modelo grande cuyo costo es treinta veces mayor, constituye toda la justificación económica de este nivel. Para una visión más amplia de dónde proviene el gasto en agentes, consulte un modelo de costos basado en la arquitectura para la IA agente.
Etapa cuatro: el agente
Solo en este punto comienza el arnés completo, con la verdadera configuración del contexto, las herramientas y un presupuesto. En un embudo saludable, solo una pequeña fracción del tráfico bruto llega hasta aquí, y cada caso que llega ya está estructurado como una situación concreta y no como un simple evento.
Etapa cinco: el ser humano
El embudo continúa más allá del agente, ya que este también funciona como filtro: decide cuáles de sus hallazgos merecen la atención de una persona. Es en esta etapa final donde los sistemas ambientales tienen éxito o fracasan, y se trata en una sección aparte a continuación.
La aritmética de un rediseño
Aplíquese esto al equipo desde el inicio. Supongamos que cambian la bandeja de entrada de modo de consulta a webhooks y añaden reglas estructurales, lo que elimina alrededor del 70% de los eventos en bruto, ya que se trata de boletines y correos automatizados. La consolidación por hilos elimina aproximadamente el 60% de lo que queda. Luego, un pequeño clasificador marca alrededor del 85% del resto como “ignorar”. El modelo frontier ahora se ejecuta unas treinta veces al mes, en comparación con veintidós mil antes, aunque siguen produciéndose las mismas once acciones valiosas. El costo por cada despertar útil disminuye en más de un orden de magnitud.
Lo sorprendente es que también mejora la precisión. Cada despertar ahora analiza una situación coherente en lugar de cualquier fragmento arbitrario que caiga dentro de un intervalo de dos minutos, por lo que el modelo cuenta con mejor información para razonar.
Dormir bien: cómo un agente inactivo no cuesta nada
Entre los períodos de inactividad, el agente ambiental ideal simplemente no existe. No está ejecutándose en silencio en segundo plano; no hay proceso, ni contenedor, ni contexto activo. Toda su existencia se reduce a un registro en un almacén: una identidad, una configuración, un puntero a su memoria y una lista de suscripciones. Esta es la idea de ejecución duradera según la cual “esperar es solo un estado”, llevada hasta su conclusión lógica. Una ejecución detenida es datos en reposo, y almacenar datos en reposo es una de las opciones más económicas que ofrece un proveedor de nube.
Eso significa que reanudar la ejecución es un acto de reconstrucción. Todo lo que aplica para reanudar un flujo de trabajo pausado también se aplica aquí, pero con mayor intensidad, ya que nadie está observando lo que ocurre.
Restablecer el reloj
Un agente que despierta después de seis días debe recibir la hora actual y debe volver a calcular todas las referencias relativas que posee. Una nota que dice “la fecha límite es viernes”, escrita un martes, ya está incorrecta para el lunes siguiente. Indíquele al agente la hora actual en la zona horaria de su responsable, así como la hora de su último despertar, para que sepa cuánto tiempo ha estado inactivo.
Trate la memoria como posible información obsoleta
El mundo siguió avanzando mientras el agente estaba ausente. Los datos almacenados en la memoria deben incluir una marca de tiempo y ser revalidados antes de su uso, además el contexto del despertar debe priorizar lecturas actualizadas sobre valores memorizados. Esta es la misma disciplina que se aplica cuando un paso de aprobación humana detiene un flujo de trabajo: vincule las decisiones a un estado instantáneo y vuelva a validarlas cuando se reanude la ejecución.
Vuelva a enfocarse en el objetivo
En los agentes que operan durante mucho tiempo, el objetivo se reconstruye efectivamente a partir del contexto en cada turno, y por eso los objetivos van desviándose con el paso de las semanas. Un “wake” reúne su contexto desde cero, lo que lo convierte tanto en el momento más riesgoso para que se produzca una desviación como en la mejor oportunidad que tendrás para corregirla. Si se hace correctamente, cada “wake” vuelve a leer la definición del objetivo. Si un agente se reconstruye doscientas veces al año, eso representa doscientas oportunidades de devolverlo a su propósito sin ningún costo adicional.
Por esta razón, los diseños que inician una sesión nueva cada vez que se activa el agente, manteniendo la continuidad en la memoria externa y los archivos en lugar de crear un registro que crece sin cesar, funcionan mucho mejor que una sola sesión permanente que acumula meses de datos residuales. Las funciones de agente programado en las herramientas de programación actuales, como las rutinas de Claude Code que son un ejemplo bien conocido en el momento de escribir esto, siguen en gran medida este modelo de nueva sesión por ejecución. Es una elección sensata para cualquiera que haya visto el efecto que tiene un contexto de varias semanas en el comportamiento de un agente.
Qué contiene un buen contexto de activación
“Reconstrucción” suena abstracto hasta que se escribe uno. Un prompt de activación bien elaborado se asemeja a una instrucción detallada que el sistema compila sección por sección:
- El archivo de objetivos, sin editar. La razón por la que existe este agente y los límites de lo que se le permite hacer.
Fíjese en lo que falta: la transcripción de las activaciones anteriores. Sus conclusiones se conservan, ya que cada activación resume en la memoria lo que ha aprendido antes de finalizar, pero el residuo resultante de cada sesión se descarta. Ese equilibrio mantiene la doscienta activación tan nítida como la segunda. También ayuda a controlar los costos, ya que un resumen de unos pocos miles de tokens sustituye a una transcripción que podría llegar a contener cientos de miles.
Garantías de entrega, con un toque de LLM
La activación también implica heredar los problemas clásicos de los sistemas distribuidos.
La entrega se realiza al menos una vez, por lo que cada solicitud debe ser idempotente. Las colas y los servicios de webhook se reservan el derecho de enviarte el mismo mensaje dos veces. Para un notificador sin estado, una duplicación es simplemente ruido. Pero para un agente que utiliza herramientas, una duplicación puede significar realizar dos veces la misma acción irreversible. La solución es la estándar: derivar una clave de idempotencia a partir del evento y verificarla antes de que la solicitud realice cualquier acción que no pueda deshacerse. Si necesitas repasar los detalles, consulta cómo funcionan las claves de idempotencia en los endpoints POST de Node.js.
Los agentes ambientales también necesitan una segunda verificación a nivel de situación. Un agente que se active porque “PR #482 es combinable” debe confirmar que la solicitud de fusión sigue siendo combinable antes de actuar. La activación podría haber ocurrido hace minutos, y otro participante, ya sea una persona o un segundo agente, podría haberse encargado ya del asunto. Las competencias en el momento de la activación son competencias normales con estado compartido, pero con un retraso mayor entre la causa y el efecto.
Los flujos de eventos tienen defectos, por lo que cada monitoreo requiere una verificación periódica. Los puntos finales sufren interrupciones, las suscripciones caducan y los proveedores a veces dejan de entregar datos sin avisar. Un sistema basado únicamente en la reacción a eventos eventualmente pasará por alto uno de ellos sin que nadie se dé cuenta, y desde el exterior, un agente que permanece en silencio porque no ocurrió nada parece idéntico a uno que permanece en silencio porque se ha vuelto inoperativo. La solución es antigua y poco atractiva: un análisis programado y lento que compara el estado real con lo informado por el flujo de eventos, de manera similar a como los sistemas de pago concilian lo que se pretendía hacer, lo que se cobró y lo que realmente se entregó. Utiliza el método push para manejar la latencia y este análisis para determinar la verdad.
Consideraciones avanzadas: adversarios, atención, concurrencia y tormentas
El desencadenante es la superficie de ataque
Revisite los cinco tipos de entrada desde una perspectiva de seguridad. Cualquiera que pueda enviar un evento puede, en efecto, activar a un agente ambiental. Las cargas de trabajo de webhook, los cuerpos de los correos electrónicos y los comentarios relacionados con problemas que pueden provocar la activación de un agente son todos textos no confiables, y llegan ante un modelo con acceso a herramientas. A diferencia del chat, no hay nadie presente en el momento de la activación para darse cuenta de que algo no está bien. Un correo electrónico “urgente” cuidadosamente elaborado no solo desperdicia una oportunidad de activación; también determina qué piensa el agente, y ese es el primer paso en casi todas las cadenas de inyección de comandos.
Todas las medidas de mitigación estándar son aplicables. Trate el contenido de los eventos estrictamente como datos. Aísle al agente ambiental con mayor rigor que a un agente de chat. Mantenga separadas las tres capacidades peligrosas: el acceso a datos privados, la exposición a contenido no confiable y la posibilidad de comunicarse con el exterior; un agente que monitorea bandejas de entrada y cuenta con herramientas amplias además de capacidad para enviar mensajes tiene todas estas capacidades además de otras más. Agregue una regla específica para los sistemas ambientales: la autonomía debe escalar según el grado de confianza que tenga en el desencadenante. Una activación causada por su propio horario puede actuar directamente, mientras que una activación provocada por contenido de un tercero debería limitarse principalmente a notificar.
El ser humano es el recurso más escaso en este ciclo
La mayor parte de lo que produce un agente ambiental son interrupciones a las personas, y las interrupciones son una “moneda” que pierde valor cuando se utilizan en exceso. Un patrón útil, bien descrito por el sistema de bandeja de entrada de agentes de LangChain, es una escalera de tres pasos para determinar qué puede solicitar un agente a una persona:
- Notificar. Solo para proporcionar información; no se requiere acción alguna.
- Preguntar. El agente necesita un dato concreto antes de poder continuar.
- Revisar. El agente ha preparado una acción y desea obtener aprobación.
La idea clave relacionada con el entorno es que esta escalera también funciona como métrica de calidad. Registre cómo reaccionan las personas ante cada interrupción: si toman acción, la descartan o la ignoran. Eso le proporciona una medición precisa para todo el proceso. Un agente cuyas notificaciones son ignoradas en el 80 % de los casos no solo tiene un 80 % de recursos desperdiciados; además, se está enseñando a las personas a silenciarlas, y una vez que lo hacen, el útil 20 % también desaparece. La fatiga por alertas ha obstaculizado la implementación de sistemas de monitoreo durante décadas, incluso antes de que existieran los modelos de lenguaje, y un texto de alerta elocuente no hace nada para cambiar eso.
Concurrencia: un superpoder con un riesgo asociado
La definición de un agente ambiental incluye actuar sobre varios eventos al mismo tiempo, y ese detalle es fácil de pasar por alto. Un agente de chat maneja una sola conversación. Un agente ambiental podría tener cuarenta instancias activas al mismo tiempo, cada una en un contexto separado e independiente, y cada una con una visión parcial de la realidad compartida. Has adquirido un sistema multiagente sin haberlo decidido, junto con sus problemas relacionados con el estado compartido. Dos instancias activas causadas por eventos relacionados podrían intentar obtener el mismo boleto, escribir respuestas contradictorias en un mismo hilo de conversación o ambas asumir la misma tarea, y ninguna de ellas podría darse cuenta, ya que los contextos independientes no comparten nada entre sí.
Las medidas de mitigación, en orden aproximado de preferencia:
- Particionar las instancias activas según una clave de correlación para que cada situación tenga su propio estado. El agrupamiento que se creó en la segunda etapa también funciona como regla de propiedad: cada situación recibe exactamente una instancia activa y no tiene un doble paralelo.
Si el embudo está bien diseñado, la mayor parte de esto se logra sin costo adicional, y eso no es casualidad. Las claves de correlación que agrupan los eventos y las claves de propiedad que protegen el estado naturalmente quieren ser las mismas claves.
Modo Storm
Un único incidente en la fase inicial puede generar diez mil eventos correlacionados. Un embudo ingenuo convierte eso en diez mil despertares, un aumento brusco en el consumo de tokens y cuarenta notificaciones que causan que el canal sea silenciado en medio del incidente. Los equipos de operaciones resolvieron una versión de esto hace tiempo mediante la detección de fluctuaciones y el agrupamiento de incidentes.
El equivalente en términos de agente es un detector de tormentas que compara la tasa actual de eventos con un valor de referencia y, cuando esta aumenta bruscamente, pasa el sistema a otro modo. En modo tormenta, todo lo relacionado se agrupa en una sola situación: se despierta a un único agente con un resumen del caso y este recibe instrucciones específicas: se trata de una tormenta; resúmela, identifique la causa más probable y envíe una notificación. El control de costos es importante, ya que es en la parte final del volumen de trabajo donde se agotan los presupuestos, pero el factor de atención es aún más relevante. Durante un incidente, la capacidad de una persona para manejar interrupciones disminuye justo en el momento en que la tasa de eventos aumenta. El modo tormenta es la forma en que el sistema respeta esa inversión.
Mida al agente inactivo como si fuera un producto
Hay dos cifras que son las más importantes:
- Costo por despertar útil. El gasto total dividido entre la cantidad de despertares que una persona, en retrospectiva, considera valiosos. Se trata de la economía unitaria aplicada a su propio sistema.
- Precisión y capacidad de recuperación en la triaje. Estos parámetros pueden evaluarse de manera muy efectiva sin conexión. Pase por un embudo de candidatos los eventos de los últimos treinta días y compare los despertares que habría generado con la forma en que las personas realmente respondieron.
Ese conjunto de herramientas para reproducir es una de las pocas evaluaciones que se pueden crear casi sin costo, ya que las etiquetas ya existen en el historial de tickets. Convierte los cambios en el embudo de cuestiones subjetivas en diferencias medibles.
Autonomía que depende del reloj
Otro patrón que es económico de implementar y, curiosamente, poco común consiste en hacer que el límite de autonomía de un sistema dependa del momento en que se activa y de quién puede ser contactado. Un hallazgo que justifique una corrección automática a las 11 a.m. de un martes, cuando hay personas en línea, un botón de detención al alcance de la mano y se conoce bien el radio de impacto, podría merecer no más que una alerta en las primeras horas de un domingo.
Esto no es una precaución excesiva. Se trata de una decisión basada en el valor esperado, con el tiempo como factor determinante. El costo de solicitar una intervención es bajo durante las horas laborales y muy alto por la noche. Al mismo tiempo, el beneficio de la supervisión humana —la probabilidad de que alguien detecte un error multiplicada por el costo de ese error— disminuye por la noche porque no hay nadie vigilando. Por lo tanto, el término de error domina y el umbral debería desplazarse hacia la solicitud de intervención, lo que en la práctica significa posponerla, ya que no hay nadie despierto para responder.
Codifique esto como una búsqueda en el sistema que combina la confiabilidad del desencadenante, la gravedad de la acción y la disponibilidad humana, y las asocie a uno de tres resultados: actuar ahora, ponerse en cola para la mañana o notificar de inmediato. La opción de ponerse en cola para la mañana es el verdadero héroe silencioso. La mayoría de las cosas que un agente ambiental detecta a las 3 a.m. están perfectamente bien como elementos para revisar a las 8:55 a.m., ya incluidos con la acción propuesta por el agente, llegando más o menos cuando se prepara el primer café.
Patrones en sistemas reales
Un asistente de correo con una bandeja de entrada para sus usuarios
El agente ambiental de referencia de LangChain se encarga de los correos electrónicos: redacta respuestas, guarda mensajes y procede a la escalada de casos. Su diseño de interacción es más instructivo que su función de redacción. El equipo detrás de él considera la participación humana no como una concesión, sino como algo que reduce los riesgos y facilita el lanzamiento de funciones, fomenta la confianza y alimenta la memoria a largo plazo. Su “Agent Inbox”, una única interfaz revisable que muestra cada conversación abierta entre una persona y sus agentes, representa de forma tangible la estructura para notificar, hacer preguntas y revisar. Un chiste recurrente de ese proyecto, según el cual si se ignora a una persona seguramente es culpa del agente, refleja perfectamente la economía de la atención: el agente existe para que una persona utilice su atención de manera más inteligente, y los chistes surgen cuando eso no ocurre.
Agentes programados en herramientas de programación
Las principales plataformas de agentes de programación han ido añadiendo agentes que se ejecutan según horarios y eventos del repositorio en lugar de por comandos; las rutinas de Claude Code y las ejecuciones desencadenadas por GitHub son ejemplos que muchos desarrolladores habrán encontrado. Consulte la documentación actual, ya que estas funcionalidades evolucionan rápidamente. Dos opciones de diseño se repiten en todas ellas, y ambas respaldan el argumento presentado aquí. Cada ejecución inicia una sesión nueva, manteniendo la continuidad en los archivos y la memoria en lugar de a través de un registro interminable. Además, la capa de desencadenamiento utiliza infraestructura clásica, como expresiones cron, filtros webhook y YAML condicional, sin que el modelo participe en ningún momento del proceso. La inteligencia artificial es costosa mientras que los mecanismos de alerta son económicos, por lo que los productos los mantienen separados.
Observadores de infraestructura
Los proveedores de nube han descrito patrones para agentes ambientales que monitorean la infraestructura y presentan hallazgos de forma proactiva. Los bien diseñados se asemejan a la puesta en práctica de esta guía. Los eventos provienen del bus de eventos nativo de la plataforma, por lo que el filtrado estructural está disponible de forma gratuita. Los eventos se correlacionan antes de invocar a cualquier agente. Y en el caso de algo importante, los agentes generan hallazgos para su revisión en lugar de aplicar soluciones por sí mismos. El detalle que vale la pena adoptar es el gradiente de confianza: cuanto más lejos llegue una acción propuesta, más arriba en la escalera de notificación, consulta y revisión se encuentra. La observación puede ser autónoma; la intervención requiere supervisión.
El equipo de monitoreo, un cuarto de año después
Regresen al equipo tras el inicio, una vez que se haya estabilizado la nueva configuración. Su sistema ahora consta de webhooks, un proceso de agrupamiento con un período de silencio de diez minutos, un pequeño clasificador cuya instrucción completa cabría en una tarjeta de índice, y alrededor de treinta ejecuciones mensuales de modelos fronterizos. Dos resultados destacan: el costo por cada ejecución útil disminuye aproximadamente cuarenta veces, y, de forma inesperada, la tasa de acierto aumenta. El diseño anterior dividía las situaciones en fragmentos arbitrarios de dos minutos, y al menos en dos ocasiones descartó una visión parcial de algo que, considerado en su totalidad, claramente merecía un “sí”.
Así que la nueva configuración no solo redujo costos; al agrupar los eventos se mejoró la calidad de las decisiones, ya que el modelo finalmente evaluaba situaciones completas en lugar de fragmentos arbitrarios de ellas. El problema nunca fue el trabajo programado, sino pedirle al modelo que evaluara cada uno de sus intervalos.
Elegir sus componentes básicos
La mayor parte de este conjunto de herramientas debería adquirirse o reutilizarse en lugar de desarrollarse desde cero.
- Infraestructura de desencadenamiento. Cron y sus equivalentes gestionados; buses y colas de eventos como EventBridge, Pub/Sub, Kafka o webhooks simples; además, programaciones y señales en motores de flujos de trabajo como Temporal, Restate o Inngest, que también ofrecen almacenamiento duradero. Las etapas uno y dos del mapa de proceso se corresponden directamente con las funciones que ya realizan estas herramientas.
Gaste su presupuesto para cosas novedosas en el embudo y en la reconstrucción del contexto posterior, y compre todo lo demás. Los programadores de tareas son un problema ya resuelto, con décadas de pruebas en el campo. Un bucle casero que consulta un modelo cada dos minutos no lo es.
Todo el diseño cabe en unas pocas líneas de pseudocódigo. Úselo de arriba hacia abajo como el embudo: una verificación gratuita de reglas, que se integra en una situación (sin devolver nada mientras la ráfaga aún se está asentando), una clasificación económica, una protección contra entregas duplicadas mediante idempotencia, la reconstrucción del contexto posterior a partir del tiempo actual, el archivo de objetivos y lecturas frescas, la ejecución de un agente con presupuesto establecido, y finalmente la entrega a través de uno de los tres verbos relacionados con la bandeja de entrada.
async def on_event(evt):
if not rules_pass(evt): return # stage 1: free
sit = coalesce(evt, window="10m") # stage 2: situations, not events
if sit is None: return # burst still settling
if triage_small_model(sit) == "ignore": return # stage 3: cheap
if seen(sit.idempotency_key): return # at-least-once armor
ctx = rebuild(now(), goal_file, fresh_reads(sit)) # stage 4: wake = reconstruction
outcome = await agent.run(sit, ctx, budget=WAKE_BUDGET)
inbox.deliver(outcome.verb, outcome.summary) # notify | question | review
Tenga en cuenta dónde se realiza la verificación de idempotencia: después de los filtros económicos pero antes de cualquier operación costosa o irreversible. También podría realizarse más temprano; lo importante es que ningún duplicado llegue nunca a agent.run. En un sistema real, rebuild es también donde debe realizarse la verificación antes de actuar a nivel de situación, ya que es el primer momento en que está disponible un estado actualizado.
Guía práctica de los modos de fallo
- La hoguera de sondeos. Se le pide repetidamente a un modelo costoso que inspeccione algo que no existe. Solución: aplicar reglas y procesos de consolidación antes de cualquier llamada al modelo, y luego utilizar un modelo económico antes del costoso.
- La manada estruendosa. Una sola interrupción se extiende y genera miles de efectos secundarios. Solución: modo tormenta, con un detector de tasa, consolidación total, un agente y una notificación únicas.
Un plan de una semana para comenzar
- Haga un auditoría de sus desencadenantes. Anote cada ruta que puede activar a su agente hoy y cuánto cuesta cada ejecución. Marque como la primera cosa a corregir cualquier ruta que implique “llamar a un modelo según un temporizador”.
- Construya la primera fase. Coloque filtros estructurales delante de cada desencadenante y mida la tasa de descarte. Si es inferior a la mitad, sus reglas son demasiado cautelosas.
Conclusión: percepción ambiental, compromiso humano
Existe un debate real sobre hacia dónde se dirigen las interfaces de los agentes. Un bando sostiene que el chat es una interfaz transitoria y que los agentes vivirán cada vez más dentro de flujos de eventos, detectando problemas antes que las personas. La atención es lo más escaso que tienen los trabajadores del conocimiento, y el software que invierte su propia atención en la observación y solo utiliza la tuya cuando es necesario, es simplemente un software mejor.
La otra parte señala que un agente siempre activo con herramientas combina exactamente los riesgos mencionados anteriormente: desencadenantes no confiables, ausencia de una persona en el momento de activación y autonomía en medio de la noche. Desde ese punto de vista, la solicitud nunca fue un costo adicional. Fue un consentimiento, y cada paso que elimina a una persona del proceso traslada el riesgo desde el momento de la acción hacia la calidad de las medidas de control implementadas.
Ambas partes tienen razón, y el embudo es el lugar donde se encuentran. Es posible monitorear todo, pero hay que notar que lo que hizo exitosos los ejemplos anteriores fue la ingeniería tradicional: filtrado, reducción de rebotes, manejo idempotente, tareas de reconciliación y atención a la fatiga por alertas. El compromiso sigue requiriendo consentimiento, que es exactamente lo que expresa la escalera de notificar, cuestionar y revisar: autonomía para detectar problemas y escalada para actuar. La fórmula consiste en agentes que observen de manera amplia, se activen con poca frecuencia y busquen aprobación antes de cambiar algo importante.
Un ejercicio útil se puede realizar en una sola tarde. Elige el flujo de notificaciones más intenso de tu día laboral y diseña un embudo para él: qué regla simple podría descartarlas, qué se uniría, qué modelo sencillo podría clasificarlas y qué realmente merecería una atención inmediata. Habrás diseñado tu primer agente inactivo antes incluso de escribir su código.
Lecturas relacionadas
- Verificando qué hacen los agentes de IA: permisos, puertas de aprobación y niveles de riesgo — Aprenda por qué los agentes que actúan necesitan una mentalidad de verificación, y cómo el principio del mínimo privilegio, la aprobación humana y la autonomía basada en riesgos ayudan a contener sus errores.
- Por qué los agentes de IA gastan el presupuesto sin finalizar, y cómo detenerlos — Aprenda por qué los agentes que utilizan herramientas siguen en bucle cuando “terminado” no está definido, a dónde van los tokens gastados, y qué condiciones de detención son más efectivas que simplemente establecer límites en el número de pasos o en el presupuesto.