Hay una conversación que se repite constantemente en LinkedIn, en foros, en grupos de Slack. Alguien descubre los agentes de IA autónomos. Los instala. Delega todo. Y a los pocos días aparece con la misma queja:

He gastado los créditos de un mes en tres días y no tengo nada que pueda defender.

No es un problema de la herramienta. Es un problema de diseño.

Lo nuevo que no es tan nuevo

Cada cierto tiempo aparece algo que el mercado presenta como una revolución.

Últimamente le toca a los agentes autónomos que acceden a tu sistema, ejecutan tareas y modifican ficheros sin que tú supervises cada paso. Hay herramientas nuevas con nombres llamativos. Hay vídeos de gente delegando proyectos enteros. Hay ansiedad colectiva de no estar usándolo ya.

Pero si llevas tiempo trabajando con Claude, esto te suena familiar. Porque Claude Desktop con MCP Filesystem Server lleva haciendo exactamente eso desde noviembre de 2024. El acceso al sistema local, la lectura y escritura de ficheros, la ejecución condicional - todo eso ya existía. Lo que ha cambiado es el envoltorio y el ruido alrededor.

La pregunta que nadie se hace es la que importa: ¿qué le estás delegando, y tienes criterio para revisar lo que te devuelve?

El modelo amplifica lo que ya sabes

Llevo años trabajando en entornos donde un error de diagnóstico tiene consecuencias reales. Banca, retail, infraestructura crítica. En esos contextos aprendes algo que ningún tutorial enseña: la diferencia entre una alerta y una señal.

Una alerta es un número que supera un umbral. Una señal es un patrón que anticipa un problema antes de que el sistema lo declare oficialmente.

Quería saber si un modelo bien contextualizado podía aplicar ese tipo de criterio. No seguir reglas fijas. Reconocer patrones con contexto de dominio real.

Diseñé un experimento sencillo: un pipeline LLM con ejecución condicional, construido enteramente con Claude Code, sin instalar nada adicional, sin frameworks externos, sin gastar créditos innecesarios en automatizar lo que no necesita automatización.

El código está aquí: incident-triage-agent

La arquitectura

El flujo es deliberadamente simple:

Un script Python genera métricas falsas pero realistas en un fichero JSON. El orquestador lee ese fichero y activa al Agente Analyst - un prompt especializado con rol de SRE senior escéptico que requiere al menos dos señales correlacionadas antes de declarar un incidente. Si el Analyst confirma el incidente, el orquestador activa al Agente Responder, que genera el runbook de respuesta inicial. Si no hay incidente, el flujo termina con justificación. Sin runbook, sin ruido.

La clave está en el CLAUDE.md en la raíz del proyecto. Ese fichero actúa como instrucción de sistema persistente para el orquestador. Claude Code lo lee al arrancar y sabe exactamente qué hacer, en qué orden, y bajo qué condiciones. No hay código de orquestación adicional. No hay dependencias. No hay infraestructura que mantener.

Tres escenarios para probar el criterio del pipeline:

• Escenario 1: CPU alta, disco disparado. Son las 02:00 . Es el batch de backup recurrente. Ruido.
• Escenario 2: Pool de conexiones DB al 99%, 847 query timeouts en 5 minutos, error rate 55 veces el baseline, servicio downstream ya degradado. Incidente crítico en cascada.
• Escenario 3: Latencia elevada, error rate leve, deploy hace 20 minutos. Ambiguo.

Lo que me importaba ver

El escenario 2 era el control. Cualquier sistema con umbrales básicos lo declara incidente. Lo interesante era cómo lo justificaba.

El Agente Analyst no dijo que había 7 métricas por encima del umbral. Aplicó el patrón clásico de incidente de base de datos que cualquier SRE senior reconoce: pool de conexiones agotado - query timeouts - error rate en cascada - servicio downstream afectado. Identificó el origen probable, descartó las explicaciones de ruido (sin batch activo, deploy hace 25 horas, tráfico normal) y escribió su decisión con 97% de confianza.

Eso ya valía el experimento. Pero el escenario 3 fue donde apareció lo que buscaba.

Las métricas estaban elevadas pero no críticas. Había un deploy reciente que podía explicarlo. Un sistema basado en umbrales habría declarado incidente o lo habría descartado. El Agente Analyst respondió de otra forma:

Hay tres hipótesis. Con los datos actuales no puedo distinguir entre ellas. Aquí están los tres comandos exactos para hacerlo. Mi apuesta es un connection leak introducido por el deploy que lleva 29 horas acumulándose - el timing encaja. Pero necesito confirmación antes de declarar incidente.

Y adjuntó las queries de PostgreSQL para verificarlo.

El modelo reconoció un patrón ambiguo, eligió no colapsar en una respuesta binaria y devolvió el control al operador con información accionable. Eso es exactamente lo que diferencia un pipeline bien diseñado de uno que dispara con cualquier umbral.

Por qué funciona sin fundir créditos

Porque cada llamada tiene un propósito concreto, un contexto acotado y un output estructurado que el orquestador puede evaluar. No hay bucles de planificación y reflexión que se llaman a sí mismos. No hay modelo navegando tu sistema completo buscando qué hacer. El scope está definido, el criterio de parada está definido, y el flujo condicional evita activar el Agente Responder cuando no hace falta.

La delegación con cabeza no significa delegar menos. Significa saber exactamente qué estás delegando y poder auditar el resultado.

Lo que necesitas para que esto tenga sentido

El pipeline del escenario 3 funcionó bien porque los conceptos del contexto de rol - connection leaks, cascadas, ventanas post-deploy, pg_stat_activity - son conceptos reales de SRE que yo puse ahí porque los entiendo. Si no los entendiera, no habría sabido qué incluir en el prompt ni habría podido evaluar si la respuesta era correcta.

Un pipeline LLM sin conocimiento de dominio detrás no amplifica nada. Genera output plausible que parece correcto y puede no serlo. El coste no es solo económico.

La herramienta no es el problema ni la solución. El criterio es lo que escala.

Código

Todo el proyecto - el orquestador, los prompts especializados, el generador de escenarios - está disponible en:

incident-triage-agent

Si trabajas en SRE o en operaciones y quieres experimentar con pipelines LLM bien acotados sin montar infraestructura compleja ni instalar dependencias externas, es un punto de partida honesto.