"Avisame cuando esta API devuelva stock en cero." La vigilancia apunta a una
HERRAMIENTA ya configurada del agente y nunca a una URL libre: así hereda
entero el blindaje de LlamarHerramientaWebhook —DNS resuelto en el connect,
IPs internas rechazadas, sin redirects, respuesta acotada— sin reimplementar
una línea de eso. Hay un test que falla si alguien le agrega un campo url.
El ahorro que hace viable la feature: se hashea la respuesta y, si no cambió,
no hay nada que evaluar y no se gasta un token. Preguntarle a la IA en cada
chequeo serían 1440 consultas diarias por cliente para responder algo que ya
sabíamos. El test verifica que el corte por hash esté ANTES de la evaluación.
Y se avisa al ENTRAR en condición, no en cada chequeo que la siga cumpliendo:
una alerta que llega cada media hora deja de leerse a la segunda. Es la lección
que el monitor de sitios ya había aprendido con las transiciones de estado.
Solo un SI explícito dispara el aviso. Un modelo que devuelve una explicación,
un error o cualquier otra cosa se toma como que no: un aviso que no llega
molesta menos que uno que despierta a alguien a las 3 AM sin motivo.
Si el envío del aviso falla, no se marca como avisado — se reintenta al
siguiente ciclo. Y tras diez fallos seguidos la vigilancia se apaga sola: una
API que dejó de existir no puede consultarse para siempre ni seguir gastando el
plan de quien la configuró.
Máximo 5 por agente, mínimo 5 minutos de intervalo. Solo canal interno: cada
vigilancia es una llamada saliente recurrente y consultas a la IA, o sea plan
del dueño gastado por quien la pida.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
