diff --git a/workloads/docs-portal/docs/arquitectura/agente-monitoreo.md b/workloads/docs-portal/docs/arquitectura/agente-monitoreo.md
index 45b5fe3..fc59a0d 100644
--- a/workloads/docs-portal/docs/arquitectura/agente-monitoreo.md
+++ b/workloads/docs-portal/docs/arquitectura/agente-monitoreo.md
@@ -197,6 +197,28 @@ de un usuario es el mismo across bots, pero Telegram igual devuelve
 persona. Se resolvió confirmando el `chat_id` real vía `getUpdates` del
 bot correcto.
 
+**Formato:** cada notificación lleva un ícono según su naturaleza
+(✅ acción ok, 🛑 acción falló/rechazada, 🚨 alerta de seguridad,
+❌ error operativo, 👀 solo diagnóstico) y el log completo de esa
+corrida va adjunto como documento (`sendDocument`), no solo como ruta —
+útil para revisar desde el celular sin acceso a shell.
+
+**Notificación silenciosa y respuestas en hilo (2026-08-26):** el nivel
+`info` (nada elegible, todo diagnóstico rutinario) se manda con
+`disable_notification=true` — no interrumpe; acciones, fallas y alertas
+de seguridad sí suenan. Cuando se ejecuta una acción correctiva, el
+`message_id` de Telegram queda guardado por recurso en `state.json`
+(`telegram_message_id`); si ese recurso se recupera solo en una corrida
+posterior, se manda un aviso silencioso como **respuesta** (hilo) al
+mensaje original antes de limpiar el estado — agrupa visualmente todo
+un incidente. Limitación conocida: si un humano desbloquea el recurso a
+mano borrando su entrada de `state.json` (ver más abajo), el
+`message_id` se pierde con esa entrada, así que ese caso puntual no
+queda threadeado — solo el "se recuperó solo" está cubierto hoy.
+Validado en vivo con el canario: acción real → `message_id` capturado →
+canario parcheado a una imagen sana → reply en hilo confirmado,
+silencioso, al recuperarse.
+
 ## Horario activo y costo
 
 **Pausa nocturna (`ACTIVE_HOURS_START`/`END`, hora local del host):**