El asistente que avisa solo: pasar de «ir a mirar» a «que me avisen»

Serie Homelab · Parte 8 · ← Mi asistente me pide permiso · Un agente que lee las noticias de IA por mí → · Ver la serie

TL;DR: Hay dos formas de saber cómo está tu infraestructura: ir a mirar o que te avisen. Lo primero es pull, lo segundo es push, y casi todo el valor está en el segundo. Te cuento cómo lo armé, por qué una parte no necesita un agente que «razone» y qué pasa cuando el mensajero también se cae.

Pull y push

Hasta aquí en la serie, todo lo que hace mi asistente empieza porque yo le pregunto. Eso es pull: yo voy a buscar. Está bien, pero tiene un límite incómodo: solo me entero de lo que se me ocurre preguntar.

Push es lo contrario: el asistente me avisa de lo que importa, cuando importa, sin que yo abra nada. Con las alertas pasa lo mismo: una alerta que no ves es un archivo, no un aviso (lo conté en la parte de observabilidad).

Qué me avisa hoy

Los avisos viven en un motor de tareas que corre en una VM aparte, la de procesos de fondo. Se encarga de los recordatorios, los avisos de reuniones, el resumen diario y de procesar las transcripciones. Las alertas de infraestructura llegan por ntfy, directo al teléfono.

Y hay una decisión de diseño que me gusta: WhatsApp es solo de salida. ARIA me escribe, pero yo no le escribo por ahí. Todo lo que implica pedir o aprobar pasa por el Dashboard, donde existe la compuerta de permisos (te lo cuento en la Parte 7). Un canal de entrada abierto por mensajería es una puerta más que defender, y prefiero tener una sola.

¿Agente o pipeline?

Mi primera versión de «el que avisa solo» fue un pipeline secuencial, no un agente ReAct. El flujo era: recolectar logs, analizarlos con un modelo y entregar el resumen por WhatsApp y ntfy, todo disparado por un cron a primera hora.

¿Por qué no un agente que razone? Porque en este caso no había nada que decidir en el camino. Siempre es el mismo recorrido: juntar, analizar, entregar. Un agente ReAct (Parte 5) sirve cuando no sabes de antemano qué herramienta toca usar; aquí lo sabía. Y un pipeline fijo tiene tres ventajas muy concretas:

• Es predecible. Cada paso hace una cosa y siempre en el mismo orden.
• Es barato. Una llamada al modelo donde hace falta, no un bucle de razonamiento.
• Se puede probar. Soy QA, así que esto me importa: puedo validar cada etapa por separado, con entradas conocidas, y saber exactamente dónde falló.

La regla que me quedó: agente cuando el camino es incierto, pipeline cuando el camino es fijo. Usar un agente para algo fijo es contratar a un detective para encontrar tu propio sillón.

Cuando el mensajero se cae

Una anécdota que no pienso omitir: cuando tomé las capturas de esta serie, la tarjeta de WhatsApp de mi propio Dashboard estaba en rojo. Decía que el gateway no respondía y que el envío público estaba caído. Es decir: mi sistema de avisos tenía un aviso pendiente que no podía avisarme.

Moraleja con tono de chiste, pero en serio: el canal de avisos también falla, así que también hay que monitorearlo. Por eso el canal tiene su tarjeta en el Dashboard, y por eso en Servicios tengo a Uptime Kuma con sus monitores en verde. Y por eso las alertas importantes tienen un segundo camino, ntfy, que no depende de WhatsApp.

Lo que aprendí

1. Avisa poco. Si suena todo el tiempo, dejas de oírlo.
2. Un aviso tiene que decir qué hacer, no solo qué pasó. «Disco alto» a secas es medio aviso.
3. Dos canales para lo importante. Si todo pasa por uno, el día que falle no te enteras.
4. Que el aviso sea idempotente. El mismo problema no debe generar diez mensajes. Una persona que recibe diez avisos lee cero.
5. Monitorea al mensajero. Si no, el silencio parece paz.