¿Alguien ejecuta agentes de IA como procesos de fondo de larga duración, no solo interfaces de chat?

Los agentes son frágiles en gran medida debido a las limitaciones de memoria

Lo que preguntas actualmente no se hace porque las aplicaciones de observación pueden hacerlo mejor. K-I-S-S es realmente el mejor estándar

Para tus puntos:

La monitorización y alerta se pueden hacer localmente con 0 agentes

Las colas de procesamiento requerirían una transferencia. Actualmente estoy autoalojando un tablero Fizzy y tengo MCPs conectados a Grok-cli y Kiro-cli. Los webhooks alertan al grupo cuando un agente termina una tarea. Esto también me da un mapa visual de lo que está sucediendo en mi proyecto

Los resúmenes diarios son absolutamente razonables y se pueden hacer con cualquiera de los arneses populares (OpenClaw, Hermes, etc.)

La vigilancia de eventos se puede hacer usando RSS o si realmente quieres que sea agéntico, simplemente crea un raspador para tu tipo de evento y apúntalo a los sitios que creas que darán mejores resultados (conciertos = stubhub) esto también podría ser manejado por tu arnés agéntico

Espero que esta información te sea útil. Todo lo mejor

Técnicamente, cosas como el OCR automatizado en documentos entrantes y la indexación para búsquedas han sido IA desde mucho antes de que existieran los LLM, pero probablemente no te refieres a eso.

Los LLM son intrínsecamente probabilísticos, por lo que el caso de uso significativo es algo que toma datos no estructurados como entrada y produce salida no estructurada o semiestructurada sin que haya una forma consistente de realizar ese mapeo.

Aparecen nuevos artículos en línea, resumir y mapear a puntos de datos existentes para construir un grafo de información sobre un tema. Generar un resumen de IA de las noticias de una docena de fuentes RSS que de otro modo no leería y enviarme un informe por correo electrónico. Resumir nuevas respuestas a una pregunta de encuesta abierta y actualizar un panel para obtener un promedio móvil de las opiniones. Monitorear un repositorio de GitHub y buscar errores comunes o mejoras de código y enviar un PR. Analizar comportamiento anómalo y enviar un resumen a un respondedor humano en el ciclo. Todo esto existe en sistemas que administro o manejo como parte del trabajo, y todos funcionan teniendo desencadenantes de entrada explícitos, límites en lo que producirán y límites de tokens en cuántos tokens se pueden generar en un solo pipeline. Puedes determinar tu costo multiplicando el número de veces que puede ocurrir el desencadenante por el número de tokens que cada desencadenante puede ingerir y generar, y ese es tu límite superior de costo.

Para algo con entrada de tamaño indeterminado o que pueda desencadenarse más veces, debes poner barreras de seguridad en la fuente. No puedes confiar en que el agente descubra el punto final exclusivamente por sí solo. No pongas un LLM a leer tus registros de Loki directamente, solo haz que se active si nota un aumento discreto en problemas reportados desde Prometheus o Kuma. Pásalo a un modelo barato como Sonnet o Haiku para clasificar. Si supera un umbral suficiente, pásalo a una IA más inteligente para resumir. Diría que los modelos actuales ni siquiera son lo suficientemente buenos para una depuración automatizada sin un humano en el ciclo, pero supongo que eso depende de la tolerancia al riesgo del usuario para procesos descontrolados. Siempre puedes establecer límites de uso como medida de corte antes de la IA.

La orquestación de agentes será un campo en crecimiento si los agentes demuestran ser valiosos y operan a escala. No he usado ninguno personalmente, pero he oído que personas en diferentes laboratorios los están adoptando y practicando. En estos casos, sin embargo, no les importa gastar dinero, les importa encontrar resultados.

Para los agentes en segundo plano, un patrón viable se acerca más a un servicio de trabajo aburrido que a un agente de chat. Utiliza disparadores explícitos, trabajos acotados y un watchdog separado.

Una forma que funciona:

cola/evento/programación crea un trabajo con una clave de idempotencia

el agente recibe una lista de herramientas pequeña y un presupuesto duro por trabajo

cada decisión escribe un evento de solo añadidura con entradas, llamadas a herramientas, resumen de salida

el watchdog fuera del modelo verifica el tiempo máximo de ejecución, gasto, número de reintentos y antigüedad del heartbeat, luego enruta los trabajos fallidos a una cola de mensajes fallidos con el rastro de eventos capturado para reproducción

las salidas que pueden cambiar de estado pasan por simulación, diff o aprobación humana hasta que esa clase de tarea haya demostrado ser de bajo riesgo

Esto mantiene al agente útil para trabajo no estructurado, mientras que la fiabilidad real proviene de controles operativos normales: workers, colas, leases, colas de mensajes fallidos, alertas e interruptores de apagado.

la mayoría de las preocupaciones sobre fugas desaparecen si separas al agente de su vigilante. un script bash barato (no otro LLM) monitorea el costo, la tasa de error y la marca de tiempo de la última ejecución, y mata al agente cuando se alcanza algún umbral. eso te da el interruptor de apagado a las 3 a.m., visibilidad de éxito silencioso y fallo verbose, y parada presupuestaria desde un solo proceso. el propio bucle de ejecución solo añade anomalías