Ejemplos de agentes de IA: Cuatro formas en produccion

Ejemplos de agentes de IA en produccion

En busca de ejemplos de agentes de IA en produccion reales, la mayoría de listas que encontrarás hoy parecen catálogos de productos: chatbots, asistentes de ventas, bots de RRHH. Ninguno responde la pregunta que un ingeniero de plataforma realmente se hace: ¿qué pinta tiene un agente cuando se le permite estar cerca de un pipeline de despliegue?

La respuesta honesta es más estrecha y menos glamurosa de lo que sugieren los decks de marketing. Los ejemplos de agentes de IA que funcionan en infraestructura de produccion caen en cuatro categorías: agentes de rollback, agentes de triage, agentes de diagnóstico y ejecutores de runbooks. Todo lo demás es un chatbot con un prompt mejor.

Los extrajimos de estudios de caso públicos, post-mortems de proveedores y nuestro propio trabajo con rollouts controlados por SLO. Ninguno es totalmente autónomo de principio a fin. Todos son estrechos, auditables y limitados a un solo trabajo.

¿Qué cuenta realmente como un agente en un pipeline de despliegue?

Un dashboard que marca una anomalía no es un agente. Un bot de Slack que te pincha cuando p99 cruza un umbral tampoco; es un cron con mejor copy. Lo que importa para los equipos de plataforma: un agente planifica una secuencia de acciones en más de un sistema, adapta ese plan según lo que encuentra, y ejecuta sin que un humano confirme cada paso.

Por ese baremo, la mayoría del tooling "DevOps con IA" sigue siendo asistivo, no agéntico. Surfacesea información más rápido. Las cuatro categorías abajo cruzan la línea hacia la acción, al menos dentro de un blast radius definido.

El agente de rollback: revertir antes de que un humano abra un dashboard

Esta es la forma más cercana a lo que construimos. Un agente monitorea la tasa de quema de SLO durante un despliegue y revierte la implementación cuando el presupuesto cruza un umbral, antes de que un humano abra un dashboard. Sin juicio, sin threads de Slack a las 3am preguntando "¿esto es lo bastante malo para revertir?" El umbral se decide a la luz del día, cuando nadie está haciendo matemáticas por adrenalina.

Una versión mínima del gate se ve así:

type RolloutState = {
  errorBudgetBurn: number; // fracción del presupuesto SLO consumido en esta ventana
  windowMinutes: number;
  canaryPercent: number;
};

function shouldAutoRollback(state: RolloutState): boolean {
  const burnRateThreshold = 0.14; // 14% del presupuesto mensual en una ventana = alerta
  const fastBurn = state.errorBudgetBurn / state.windowMinutes > burnRateThreshold / 60;
  return fastBurn && state.canaryPercent > 0;
}

Esa es toda la decisión. La parte agéntica es todo lo que la rodea: traer live error rate y latencia de la pila de observabilidad, comparar contra el SLO pre-declarado, ejecutar el revert via el deployment API, y escribir una nota estructurada en el canal de incidentes explicando qué lo disparó y qué vio. Hemos visto este patrón correr en produccion en una fintech Series C haciendo alrededor de 40 despliegues al día. Tiempo mediano de detección de quema a revert: menos de 90 segundos. El mediano manual del equipo, medido en seis meses de post-mortems, fue de 11 minutos.

Saltate este patrón si tu frecuencia de despliegue es tan baja que un humano ya está mirando cada rollout en vivo. El agente se gana su sueldo a volumen, no a 2 despliegues por semana.

El agente de triage de causas raíz: de la alerta a un thread de Slack en minutos

Esta es la categoría con más datos públicos detrás ahora mismo, porque es la más fácil de vender y la más fácil de medir. El DevOps Agent de AWS, por ejemplo, se dispara por una alarma de CloudWatch o un page de PagerDuty, forma una hipótesis sobre la causa, consulta logs y trazas para probarla, correlaciona la anomalía contra timestamps de despliegues recientes, y postea hallazgos en Slack con una mitigación recomendada. AWS reporta hasta 75% menor MTTR en sus despliegues documentados, y el caso de estudio de Western Governors University cita específicamente tiempo de resolución cayendo de alrededor de dos horas a 28 minutos (fuente).

Lo que vale la pena notar no es el porcentaje. Es el requisito de auditría: cada paso de razonamiento que el agente toma está registrado en un record inmutable que no puede modificar él mismo. Eso no es un nice-to-have. Si un agente va a correlacionar tu historial de despliegues con tu spike de errores y decirle a un ingeniero on-call "esto es probablemente el cambio del servicio de checkout", necesitas poder reconstruir exactamente cómo lo obtuvo cuando esté mal, y ocasionalmente estará mal.

Hemos visto el mismo patrón bajo diferentes nombres: Wild Moose promete surfacesea de causa raíz en menos de un minuto, HolmesGPT diagnostica alertas cloud via el mismo loop detect-correlate-explain. La mecánica converge porque el problema tiene la misma forma en todas partes: alerta dispara, agente lee telemetría, agente propone causa, humano confirma u override.

Vale la pena la inversión en setup si tu equipo pagea más de un puñado de veces a la semana y tus post-mortems siguen citando "tardó demasiado en encontrar la causa real" como factor contribuyente. Saltátelo si tus incidentes son raros lo suficiente como para que el tiempo de tuning no se amortice antes de que tu siguiente cambio de arquitectura haga que los datos de entrenamiento del modelo queden obsoletos.

El agente de diagnóstico Kubernetes: un slice más estrecho y seguro

Kubernetes debugging es donde muchas de estas herramientas comenzaron, probablemente porque la salida de kubectl es exactamente el tipo de texto denso y estructurado en el que un LLM es bueno para resumir. k8s-GPT escanea un cluster y explica fallos en lenguaje natural: por qué un pod está atrapado en CrashLoopBackOff, por qué un PVC no se bindeará, por qué un servicio no tiene endpoints. No actúa, explica. Ese scoping es deliberado, y es la jugada correcta para una herramienta que un ingeniero junior podría correr en un cluster que no entiende completamente.

El siguiente tier actúa, cuidadosamente. Los agentes Guardian-style detectan un issue, encuentran la causa raíz, y abren una fix PR en vez de pushear directamente al cluster. Ese paso extra, una PR en vez de un cambio vivo, es toda la diferencia entre "automatización útil" y "la cosa que causó el apagón del martes pasado." Una PR se revisa. Un kubectl apply directo desde un agente no, a menos que hayas construido un paso de revisión tú mismo, y la mayoría de equipos no lo ha hecho.

La capa de docs importa más aquí de lo que la gente espera. Cuando un agente explica una falla de Kubernetes o abre una fix PR, el runbook que está implícitamente siguiendo vive en la cabeza de tu equipo o vive en algún lugar donde el agente (y el siguiente ingeniero) pueden leerlo realmente. Los equipos que mantienen runbooks en una herramienta docs-as-code con una capa de IA consultable ven menos threads de "espera, ¿por qué lo hicimos así?" seis meses después. Eso no es consejo específico de agentes, es solo que la salida de agentes hace evidente la documentación obsoleta más rápido de lo que un humano leyéndola alguna vez lo haría.

El ejecutor de runbooks: qué pasa cuando dejas que un agente toque prod

Esta es la categoría que la gente significa cuando dice "agente SRE totalmente autónomo", y también es la que tiene la evidencia más delgada. El pitch: un agente detecta una fuga de memoria, dispara un rolling restart durante una ventana de bajo tráfico, confirma que el servicio volvió sano, y cierra el loop sin pagear a nadie. Playbooks de remediación multi-paso, ejecutados sin el riesgo de un typo o un paso saltado en un runbook de las 2am que fue testeado por última vez en marzo.

Funciona, cuando el playbook es estrecho y el blast radius es pequeño. Un rolling restart de un servicio sin estado durante una ventana de bajo tráfico definida es algo razonable de automatizar. Un failover de base de datos durante horario de negocio no es, no importa cuán bueno se vea el track record del agente en una demo. Los equipos que se queman aquí no son los que automatizan restarts, son los que dejan que una victoria temprana los convenza de automatizar algo con riesgo real de pérdida de datos antes de que el agente tuviera suficientes reps de produccion para ganar ese trust.

Nuestra propia lectura, de ver clientes wiring AI Pilot en rollouts progresivos: comenzar con la acción que es más fácil de revertir y más difícil de equivocarse. Restart antes de failover. Rollback de porcentaje canary antes de cambios de esquema de base de datos. Deja que la tasa de error del agente en acciones de bajo riesgo construya el caso para las de riesgo más alto, en una timeline medida en meses, no en la primera semana buena.

Los agentes de propósito general también aparecen, y tienen la forma equivocada para esto

Busca "ejemplos de agentes de IA" en cualquier lado fuera de un contexto de ops y aterriczarás en una categoría completamente diferente: agentes generalistas construidos para planificar y ejecutar tareas open-ended en un navegador virtual, terminal y sistema de archivos.

Manus opera dentro de una computadora virtual completa e reportea con deliverables finales en vez de una respuesta de chat. Es genuinamente capaz en investigación y tareas web multi-paso. También es la herramienta equivocada para una decisión de rollout de produccion, porque su propuesta de valor es amplitud: puede hacer casi cualquier cosa, dado suficientes pasos y suficiente tiempo. Una decisión de rollback necesita la propiedad opuesta. Necesita ser rápida, estrecha y aburrida lo suficiente para que puedas predecir exactamente qué hará antes de que lo haga.

Lindy se sienta más cerca de la mitad ops-adjacent: workflows sin código que manejan triage de inbox, scheduling de reuniones y seguimientos recurrentes. Útil para el lado humano de una rotación on-call (nadie quiere reschedule manualmente un handoff a las 6am), inútil para la respuesta de incidente real. Misma historia con el Super Agent sin código de Genspark, que browsea, llama y genera on request pero no tiene concepto de presupuesto SLO o porcentaje canary.

Ninguno de esto es un golpe bajo contra esos productos. Están construidos para un trabajo diferente. El error que seguimos viendo es equipos evaluando un agente de propósito general contra un problema de ops estrecho, quedando sin impresionar, y concluyendo "los agentes de IA no están listos para infra." Categoría equivocada, conclusión equivocada.

Dónde aún fallan estos agentes, y por qué eso es la parte interesante

El modo de fallo que nadie pone en el caso de estudio: agentes que son 94% precisos en identificación de causa raíz aún están mal una de cada diecisiete veces, y la respuesta equivocada usualmente suena segura y es lo suficientemente específica para enviar a un ingeniero on-call persiguiendo el servicio equivocado por veinte minutos antes de que alguien note que la correlación que el agente encontró era coincidencia, no causal. La correlación de timestamp de deploy es una señal real. No es prueba. Un agente entrenado para sonar seguro sonará igual de seguro sobre una coincidencia que sobre una causa real.

El segundo modo de fallo es más callado: sprawl de agentes. Una vez que triage, diagnóstico y agentes de rollback están todos corriendo, alguien tiene que monitorear los agentes. Los despliegues de principios de 2026 ya están mostrando que la victoria operacional más grande no es el número de MTTR, es construir observabilidad para la capa de agentes misma, porque un agente que silenciosamente deja de dispararse es peor que ningún agente en absoluto. Nadie nota la ausencia de una alerta.

Salta la autonomía total en cualquier cosa con blast radius irreversible, sin importar cuán buenas se vean las últimas veinte ejecuciones. Veinte buenas ejecuciones no es una distribución, es una muestra.

¿Cableas un agente en tu rollout, o esperas otro ciclo?

Si tu equipo pagea más de un puñado de veces al mes y tus post-mortems siguen repitiendo la misma causa raíz con diferentes nombres de servicio, un agente de triage se pagará a sí mismo más rápido de lo que esperas, principalmente acortando la fase "qué cambió" de cada incidente. Si tu volumen de despliegue es lo suficientemente alto como para que un humano no pueda ver cada rollout en vivo, un agente de rollback controlado por SLO remueve completamente la decisión de juicio de las 3am, que es el punto real: no quieres que el ingeniero on-call piense a las 3am, quieres que presione un botón que fue configurado a la luz del día.

Si aún ni uno ni otro es cierto, la jugada honesta es instrumentar tus SLOs correctamente primero. Un agente sentado sobre error budgets ruidosos e indefinidos solo automatizará decisiones malas más rápido de lo que un humano las hubiera hecho. El agente no es la parte dura. Saber exactamente qué "lo bastante malo para actuar" significa, en números, antes de pasar la decisión a algo que no se cansa a las 3am, es.