Saltar a contenido

Estrategia Q10 — agente AI gestionando el smart home (v1)

Primera versión operativa de la pregunta guía Q10. La meta del usuario es "smart home invisible, no tinkering, agent-managed". Esta página define el rol del agente, el perímetro de autoridad, las herramientas que necesita, y la trayectoria de adopción de "agente de lectura" a "agente operando con perímetro autónomo razonable". Coexiste con ha-upgrade-reliability-strategy (Q2) — el agente es uno de los mecanismos para ejecutar esa estrategia.

Contexto

El AI tooling no es decorativo en este proyecto: es la pieza que hace viable la meta operativa del usuario. Sin agente persistente, "no tinkering" es ilusorio porque alguien tiene que aplicar pre-update checklists, revisar logs, decidir qué upgrade aplicar, hacer rollbacks. El agente es quien hace eso por defecto, y el humano interviene sólo cuando el agente escala una decisión que no se siente cómodo tomando solo.

Contenido

Rol del agente

"El agente es el operador por defecto. El humano es el dueño y el escalation path."

Concretamente, el agente:

  1. Vigila: corre health checks vía Gatus, lee logs Loki, observa métricas Prometheus.
  2. Diagnostica: cuando algo falla, busca la causa cruzando logs + estado + recent changes (git history).
  3. Repara: aplica fixes para patterns en su lista autónoma (ver ../concepts/ai-as-operator).
  4. Escala: si el problema no es un pattern conocido, abre un GitHub issue / PR / mensaje Telegram con el diagnóstico y propuesta de fix.
  5. Documenta: cada acción queda en docs/agent-log.md del repo (o equivalente).
  6. Aprende: el humano marca patterns como "agregar al perímetro autónomo" cuando confía en cómo el agente los resolvió 3+ veces.

Stack candidato

Tres opciones razonables, de menor a mayor inversión:

Opción 1 — Claude Code + cron + MCP (la más liviana)

  • Cómo funciona: cron en el mini-PC dispara cada N minutos un claude con un prompt fijo: "revisá health checks, logs recientes, diagnostica cualquier problema, proponé fix vía PR". MCP servers configurados: ha-mcp (HA control), filesystem (repo), gh (PRs).
  • Pros: el setup es trivial. Si no funciona, sólo perdiste cron + un script.
  • Contras: cada invocación es ciega de la anterior (sin estado persistente). No reacciona a eventos en tiempo real; sólo en el siguiente tick.
  • Cuándo elegir: para empezar y validar la idea esta semana, no en 2 meses.

Opción 2 — Agente custom basado en Claude SDK + webhook listener (intermedio)

  • Cómo funciona: container con FastAPI o equivalente que escucha webhooks de Gatus (cada fallo) y de GitHub Actions (cada deploy). Cuando llega un webhook, dispara una conversación Claude con el contexto del evento. Estado persistente en una DB local.
  • Pros: reacciona a eventos en segundos. Estado entre conversaciones (puede saber "ya intenté esto hace 10 min y no funcionó"). Customizable.
  • Contras: hay que construirlo. ~1-2 semanas de trabajo. Mantenimiento propio.
  • Cuándo elegir: si la opción 1 valida pero no alcanza por latencia o falta de memoria, escalar acá.

Opción 3 — OpenClaw (la más completa)

  • Cómo funciona: deployar ../entities/openclaw como container. Configurar sus tools (kubectl removido, terraform, ansible, gh, ssh-yellow, ha-mcp). Webhook integration ya viene built-in.
  • Pros: madebynathan + Dan Malone lo usan en producción. No reinventás la rueda. Updates suben con el proyecto.
  • Contras: hay que aprender su modelo. Dependencia externa. Habría que verificar madurez exacta (pendiente ingerir docs).
  • Cuándo elegir: si la opción 2 valida y querés cambiar a algo más mantenible.

Recomendación: empezar con Opción 1 esta semana. Si funciona durante un mes, considerar Opción 3 (saltarse Opción 2). Si Opción 1 no alcanza pero Opción 3 parece overkill, ir a Opción 2.

Herramientas que el agente necesita (independiente del stack elegido)

Herramienta Para qué Notas
ssh ha-yellow Restart de add-ons, ha CLI (ver ../entities/ha-cli) Acceso de sólo restart inicialmente; NO permisos de borrado
ha-mcp (MCP) Query y control de HA via API Genera tokens long-lived. Restricción: tokens sólo de lectura inicialmente
docker compose (local en mini-PC) Restart de containers, redeploy desde tag pinned Acceso normal de Docker socket
git + gh Lee estado, abre PRs, escribe postmortems GitHub token con scope repo
curl / httpx Hablar con Gatus API, Loki API, Prometheus API Sólo lectura
loki-cli o logcli Querys ad-hoc a Loki Para diagnóstico
esphome CLI OTA flash desde la repo de configs ESPHome Sólo cuando se promueva al perímetro autónomo

Lista negra explícita (NO): - kubectl — no aplica, k8s out. - Cambios en firewall del router / VLAN config. - Borrado masivo de devices Zigbee/BLE. - Cambios de credenciales (HA Cloud, MQTT, GitHub tokens). - Rollback de DB del recorder con drop de tablas.

Trayectoria de adopción del perímetro autónomo

Tabla de progresión: mes → acciones del agente sin pedir approval.

Mes Capacidades autónomas Capacidades con approval Notas
Mes 1 Solo lee + reporta. Sin ejecutar nada. Todo. Validar que diagnostica bien.
Mes 2 Restart de containers no-críticos (Gatus, Loki, Grafana). Cleanup de logs viejos. Restart de HA Container, restart de Z2M, cualquier cambio de config. Empezar safe.
Mes 3 Lo de mes 2 + restart de HA Container experimental + apply de PRs aprobados. Update de HA Container a 2026.X.0 mensual + Update de HAOS Yellow. Promover una acción al perímetro cuando funcionó autónomo 3+ veces.
Mes 6 Lo anterior + pre-update checklist completo + smoke tests post-update. Major version jumps + cambios de schema (recorder). El agente ahora ejecuta ../concepts/ha-pre-update-checklist entero.
Mes 12 Todo lo anterior + restore desde backup si detecta failure mode catalogado. Cambios que afectan ESPHome devices (OTA), cambios en MQTT topology, cambios en network. Acercándose a "invisible".

Conexión con failure modes catalogados

El agente debe conocer el catálogo (failure-mode-stuck-haos-update-mechanism, failure-mode-hardware-support-cutoff) y tener playbooks para cada uno. Cuando detecta el pattern:

  • Failure mode 1 (stuck HAOS): el agente ejecuta ha os update --version <next-step> con backup previo. Sin approval (es recovery, no upgrade voluntario).
  • Failure mode 2 (hardware support cutoff): el agente NO aplica el upgrade. Detecta la inminencia consultando hardware support matrix, alerta al humano vía Telegram con propuesta de cambio de hardware.

Métricas a trackear

Métrica Cómo se mide Objetivo
Tasa de fixes autónomos exitosos (fixes que cerraron el alert) / (fixes intentados) > 95% después de mes 3
Tasa de escalations falsos positivos (escalations que el humano cierra sin tocar nada) / (total escalations) < 20%
Tasa de over-action (deshacer del humano) (cambios deshechos en 24h) / (total cambios del agente) < 5%
Tiempo del humano dedicado al smart home / semana Honest self-report Trending down hasta < 30 min/semana

Relaciones

Citas / evidencia

  • "que sea más auto atendido y manejado por agentes IA. Quiero un smart home que funcione. Ojalá invisible. No quiero estar tinkering with it" — usuario, mensaje 2026-05-20 (norte explícito del proyecto).

  • "AI as operator, not owner" — ../sources/madebynathan-self-healing-2026-02.

Abierto / gaps

  • Definir el prompt inicial del agente para Opción 1 (Claude Code + cron). Esqueleto: "actúa como SRE de mi smart home; revisa estado y reporta cualquier issue con diagnóstico y plan de fix; si el fix está en tu perímetro autónomo, aplícalo y abre PR documentándolo; si no, abre issue con propuesta".
  • Ingerir docs oficiales de OpenClaw para tener decisión informada Opción 1 vs 3.
  • Ingerir Dan Malone series (Q10 candidatos alta restantes) — sus patrones multi-agent enriquecen esta página.
  • Definir el primer issue real que el agente va a resolver — quizás "tu HA Yellow está N días sin update" como caso de aprendizaje.
  • Patrón concreto de inyección de contexto del wiki al agente: ¿el wiki es accesible? ¿el gaps.md lo lee el agente y propone trabajar en él?