Durante décadas, la automatización de TI fue sinónimo de scripts que ejecutan tareas fijas cuando se cumplen condiciones fijas. Útiles, predecibles, frágiles ante lo inesperado. Un agente de IA opera bajo una lógica distinta: recibe un objetivo, observa el estado del sistema, decide qué acción tomar y ejecuta — sin que nadie haya anticipado exactamente ese escenario.
Qué hace un agente de TI que un script no puede
Un script reacciona: si la métrica X supera el umbral Y, ejecuta Z. Un agente razona: analiza el log de las últimas 4 horas, correlaciona el pico de latencia con el deploy de las 14:00, determina que la causa probable es una query sin índice, genera el comando de remediación y lo ejecuta. La diferencia no es de velocidad; es de profundidad.
«Cuando tu infraestructura tiene agentes, el ingeniero de guardia deja de apagar incendios y empieza a diseñar cómo el sistema se apaga solo.»
Casos de uso reales en operaciones de TI
El análisis de logs es el caso de entrada más común: un agente puede leer miles de líneas, identificar patrones anómalos y escalar solo lo que requiere atención. La clasificación de incidentes evalúa severidad, impacto y contexto antes de notificar. La remediación automatizada reinicia servicios, redirige tráfico o ejecuta playbooks en escenarios conocidos.
Qué cambia cuando TI se vuelve agéntico
Los ingenieros de infraestructura dejan de ser operadores de incidentes y se convierten en diseñadores de políticas. La otra consecuencia es la auditabilidad: un agente que actúa de forma autónoma debe dejar registro de cada decisión y acción. Sin eso, los incidentes son imposibles de diagnosticar. La pregunta no es si vas a automatizar con agentes, sino si lo harás con disciplina antes de que la urgencia te obligue a hacerlo sin ella.
Conectar Claude a tu infraestructura para que monitoree en tiempo real no es un proyecto de tres meses: es un sprint bien ejecutado. Pero hacerlo mal genera falsa seguridad que convierte un incidente menor en una caída de producción. Esta guía cubre la arquitectura mínima viable de un agente de monitoreo.
Arquitectura del agente de monitoreo
Un agente de monitoreo con Claude necesita tres capas. La primera es la capa de observabilidad: acceso estructurado a logs, métricas y eventos. Pasa JSON estructurado con timestamps, niveles de severidad y metadata. La segunda es la capa de herramientas: get_recent_logs(service, minutes), get_metrics_snapshot(service), get_incident_history(service, days). La tercera es la capa de acción: funciones con controles de autorización explícitos.
El loop: observar, clasificar, actuar
El agente ingiere el estado del sistema, razona sobre anomalías comparando con baselines históricos, clasifica el incidente y decide: notificar, remediar o escalar. Claude es especialmente útil en clasificación: puede correlacionar un pico de errores 500 con un deploy reciente, contextualizando cada alerta.
«El agente no reemplaza el criterio del ingeniero; lo escala a cada minuto del día sin necesidad de que esté despierto.»
La implementación usa la API de Claude con tool_use. Defines cada herramienta con nombre, descripción y schema. Claude decide cuándo llamarla, tú ejecutas y devuelves el resultado. El error más común: pasar el estado completo del sistema sin filtrar satura la ventana de contexto. Filtra: entrega solo los servicios con comportamiento fuera de baseline.
Qué vigilar para no perder el control
Define qué acciones puede tomar el agente autónomamente y cuáles requieren confirmación. Logea cada decisión. Establece un modo degradado: si el agente falla, cae a alertas convencionales. Un agente de monitoreo bien implementado libera a tu equipo de la guardia reactiva — construido con la misma disciplina que aplicas al software que monitorea.
Los scripts de automatización que escribiste hace cinco años siguen funcionando, pero ya no son suficientes para el sistema que operas hoy. No porque sean viejos, sino porque fueron diseñados para un mundo donde los escenarios de fallo eran predecibles. La pregunta no es si reemplazarlos con agentes, sino cuándo ese reemplazo genera más valor que complejidad.
Scripts vs. agentes: la diferencia fundamental
Un script es determinista: dada la condición A, ejecuta B. Su poder está en la predictibilidad; su límite está en que solo maneja los escenarios que su autor anticipó. Un agente es probabilístico: dado el objetivo O y el estado S, razona cuál es la mejor acción. Puede manejar escenarios no anticipados, pero introduce incertidumbre.
«No migres a agentes porque es la tendencia. Migra cuando el espacio de escenarios supere lo que puedes codificar en condiciones explícitas.»
Framework de decisión: ¿cuándo migrar?
Evalúa cada proceso contra cuatro criterios: Variabilidad de contexto (alta variabilidad favorece agentes), Coste del error (alto costo favorece mantener scripts con confirmación humana), Volumen de casos (alto volumen favorece agentes), Disponibilidad de contexto (sin datos buenos, un agente razona sobre ruido).
Enfoque de migración: no todo a la vez
El error más costoso es la migración big bang. El enfoque correcto: identifica el proceso con mayor variabilidad y menor riesgo catastrófico, implementa el agente en modo observación, valida que sus clasificaciones coinciden con decisiones humanas durante dos o tres semanas, activa la acción autónoma solo donde la coincidencia es consistente. Expande gradualmente. Mantén los scripts como fallback.
Riesgos y recompensas
El riesgo principal es la falsa confianza. Mantén runbooks humanos actualizados aunque el agente los ejecute. La recompensa: los equipos que operan con agentes dedican su capacidad a mejorar el sistema, no a mantenerlo. El siguiente nivel de automatización institucionaliza tu conocimiento operacional en un sistema que trabaja mientras tú construyes lo que sigue.
