ChatGPT sabe de DevOps. Puede explicar conceptos de Kubernetes, sugerir patrones de Terraform y ayudar a depurar mensajes de error.

Pero no puede decirte por qué TUS pods se caen a las 3 de la mañana.

Esta guía te enseña los patrones para construir agentes de IA que van más allá del consejo genérico: agentes que entienden tu infraestructura específica y pueden tomar acciones relevantes.

Por qué los agentes verticales superan a la IA genérica

El problema de la IA genérica

Pregúntale a ChatGPT “¿Cómo arreglo un pod en crash loop de Kubernetes?” y recibirás una respuesta completa que cubre todas las causas posibles. Eso sirve para aprender, pero no para resolver TU problema a las 2 de la mañana.

La IA genérica te da:

Explicaciones amplias que aplican a todo el mundo
Sugerencias que quizá no encajen con tu arquitectura
Ningún contexto sobre tus sistemas
Riesgo de alucinar en los detalles

El enfoque del agente vertical

Los agentes verticales invierten este modelo:

Aspecto	IA genérica	Agente vertical
Alcance	Todo	Un solo dominio
Contexto	Ninguno	Tu infraestructura
Resultado	Consejos genéricos	Pasos accionables
Alucinación	Mayor riesgo	Menor (dominio acotado)

Un agente de monitoreo que conoce TU infraestructura puede decirte:

“El pod X está en crash loop porque el connection pool de la base de datos está agotado”
“Esto pasó dos veces el mes pasado, después del pico de tráfico del martes”
“El runbook 7.3 resuelve esto, ¿lo aplico?”

La filosofía de agentes de Webera

No construimos una sola IA que lo haga todo. Construimos 9 especialistas que hacen una sola cosa de manera excelente:

Sentinel — Monitoreo y observabilidad
Guardian — Seguridad y cumplimiento normativo
Optimizer — Costos y rendimiento
Conductor — CI/CD y despliegue
Dispatcher — Alertas y enrutamiento
Navigator — Descubrimiento y documentación
Keeper — Gestión de secretos y accesos
Warden — Auditoría y gobernanza
Forge — Preparación de aplicaciones

Cada agente es un experto profundo en su dominio, con contexto sobre TUS sistemas.

Parte 1: Anatomía de un agente de infraestructura

Todo agente eficaz necesita tres cosas: el Por qué, el Cómo y el Qué.

El Por qué: identidad y misión

Antes de escribir una sola línea de código, define:

¿Quién es este agente? Dale un nombre y una personalidad
¿Qué problema resuelve? Un problema específico, no varios
¿Cómo se ve el éxito? Resultados medibles

Ejemplo: Sentinel (agente de monitoreo)

identity:
  name: Sentinel
  tagline: "Watching while you sleep"
  mission: Ensure no issue goes undetected
  success_metrics:
    - Zero surprise outages
    - Mean time to detection < 5 minutes
    - False positive rate < 10%

El Cómo: principios de operación

Define cómo toma decisiones el agente:

¿Qué puede hacer de forma autónoma? Operaciones de solo lectura, cambios en entornos que no son de producción
¿Qué requiere aprobación? Cambios en producción, eliminaciones
¿Con quién colabora? Otros agentes, personas

El Qué: responsabilidades específicas

Enumera lo concreto que hace este agente:

El conocimiento del dominio que necesita
Los flujos de trabajo que ejecuta
Los resultados que produce
El material de referencia que usa

Parte 2: Autoridad de decisión, el patrón crítico

Sin límites de autoridad claros, los agentes o piden permiso para todo (inútiles) o actúan de forma autónoma en todo (peligrosos).

La matriz de autoridad

Tipo de acción	Nivel de autoridad
Descubrimiento de solo lectura	Autónomo
Evaluación y análisis	Autónomo
Cambios fuera de producción	Autónomo
Propuestas para producción	Autónomo para proponer
Ejecución en producción	Requiere aprobación
Eliminar o quitar cualquier cosa	Requiere aprobación

Cómo implementar la matriz

Así maneja una solicitud un agente bien diseñado:

Solicitud: “Configura el monitoreo para producción”

AUTÓNOMO: Descubrir la infraestructura actual
AUTÓNOMO: Evaluar qué falta
AUTÓNOMO: Proponer el stack de monitoreo
REQUIERE APROBACIÓN: Ejecutar los cambios en producción
AUTÓNOMO: Verificar y documentar

El agente piensa y las personas aprueban la acción.

Por qué importa

Considera dos escenarios:

Escenario A: sin matriz de autoridad El agente recibe una alerta por CPU alta. ¿Escala? ¿Investiga? ¿Despierta a alguien? Sin límites claros, o no hace nada útil o hace algo peligroso.

Escenario B: con una matriz de autoridad clara El agente recibe la alerta. De forma AUTÓNOMA investiga y la correlaciona con los despliegues recientes. De forma AUTÓNOMA propone un rollback con evidencia que lo respalda. REQUIERE APROBACIÓN antes de ejecutar el rollback.

El segundo agente es útil Y seguro.

Parte 3: Inyección de contexto, tu infraestructura y no consejos genéricos

La diferencia entre “ChatGPT sabe de DevOps” y “Nuestros agentes conocen TU infraestructura” es el contexto.

El patrón del archivo de contexto

Los agentes necesitan conocimiento estructurado sobre TUS sistemas:

# .webera/context.yaml
infrastructure:
  cloud: aws
  region: us-east-1
  account_id: "123456789012"

  kubernetes:
    version: "1.28"
    cluster: "production-eks"
    namespaces:
      - name: api
        criticality: high
      - name: workers
        criticality: medium

  databases:
    - type: postgresql
      version: "15"
      name: "primary-db"
      rds_instance: "db.r6g.xlarge"

services:
  - name: api
    repository: "company/api"
    criticality: high
    dependencies: [primary-db, redis]
    sla_target: "99.9%"

  - name: worker
    repository: "company/worker"
    criticality: medium
    dependencies: [primary-db, rabbitmq]

Por qué el contexto supera al prompting

Sin archivo de contexto:

User: "Why is my API slow?"
Agent: "There could be many reasons. Check your database queries,
       network latency, CPU usage..."

Con archivo de contexto:

User: "Why is my API slow?"
Agent: "Your API service depends on primary-db (PostgreSQL 15 on
       db.r6g.xlarge). Checking CloudWatch metrics... Connection
       pool is at 95% capacity. This matches the pattern from last
       Tuesday's incident. Recommend increasing pool size per
       runbook 4.2."

La diferencia es la especificidad accionable.

Cómo mantener el contexto actualizado

Los archivos de contexto deben ser:

Versionados — En tu repositorio de git
Autodescubiertos — Los agentes pueden actualizarlos (con aprobación)
Validados — Verificados contra un esquema para evitar errores

Parte 4: Colaboración entre agentes

Un agente solo tiene límites. Los sistemas de agentes son poderosos.

El patrón de traspaso

Los agentes trabajan juntos mediante traspasos definidos:

Sentinel (monitoring) ──detects issue──► Dispatcher (routing)
Dispatcher ──routes to──► On-call engineer

Guardian (security) ──secures──► Conductor (pipelines)
Optimizer (cost) ◄──metrics from── Sentinel (monitoring)

Cómo diseñar los traspasos

Cada traspaso necesita:

Un disparador claro — ¿Cuándo ocurre el traspaso?
Traspaso de contexto — ¿Qué información se transfiere?
Confirmación — ¿Cómo confirma el agente que recibe?

Ejemplo de traspaso:

handoff:
  from: sentinel
  to: dispatcher
  trigger: alert_threshold_exceeded
  context:
    - alert_type
    - affected_service
    - metrics_snapshot
    - suggested_runbook
  acknowledgment: dispatcher_received

Un ejemplo del mundo real

1. Sentinel detects: High error rate on API service (5xx > 1%)
2. Sentinel outputs:
   - Alert with context (service, metrics, timeframe)
   - Correlation with recent events
   - Suggested runbook
3. Sentinel suggests: "Engage Dispatcher to route this alert"
4. Dispatcher receives: Alert + context
5. Dispatcher checks: Runbook exists for this scenario
6. Dispatcher decides: Route to API team based on on-call schedule
7. Dispatcher notifies: Slack + PagerDuty with full context

Ninguna persona interviene hasta el paso 7. Pero las personas siguen al mando.

Parte 5: Personalización por cliente

El mismo agente debe comportarse de forma distinta según el contexto.

Por qué importa la personalización

Cliente A: enfocado en SOC 2, control de cambios estricto, requiere aprobación para todo
Cliente B: moverse rápido, romper cosas (pero arreglarlas rápido), autónomo fuera de producción

El mismo agente, comportamientos distintos.

El patrón de personalización

# Client-specific settings
agent_customization:
  sentinel:
    focus_areas:
      - "API latency"
      - "Database connections"
    ignore_namespaces:
      - "kube-system"
      - "monitoring"
    alert_threshold_multiplier: 1.5  # More lenient
    notes: "Previous P1 was API latency related - prioritize"

  guardian:
    compliance_focus:
      - "SOC2"
      - "HIPAA"
    backup_priority: "critical"
    approval_required_for: "all_changes"
    notes: "Healthcare client, strict compliance required"

Consejos de implementación

Revisa primero la personalización — Antes de cualquier acción, carga la configuración del cliente
Aplica las notas como contexto — Las notas históricas informan las decisiones actuales
Por defecto, lo seguro — Si no hay personalización, usa valores conservadores

Parte 6: Cómo construir tu primer agente

¿Listo para construir? Este es el proceso paso a paso.

Paso 1: Elige un dominio acotado

NO esto: “Agente de infraestructura” SÍ esto: “Agente de monitoreo y alertas”

Alcance acotado = experiencia profunda = mejores resultados.

Paso 2: Define la identidad (el Por qué)

identity:
  name: [Agent name]
  tagline: [One-line mission]
  problem_solved: [Specific problem]
  success_criteria:
    - [Measurable outcome 1]
    - [Measurable outcome 2]

Paso 3: Define la autoridad (el Cómo)

authority:
  autonomous:
    - Read infrastructure state
    - Analyze metrics and logs
    - Generate reports
    - Propose changes
  requires_approval:
    - Execute production changes
    - Modify security settings
    - Delete resources
  handoffs_to:
    - [Other agent for related work]

Paso 4: Define el conocimiento (el Qué)

knowledge:
  domain_expertise:
    - [Technical area 1]
    - [Technical area 2]
  reference_materials:
    - [Documentation source]
    - [Runbook location]
  output_formats:
    - [Report type]
    - [Alert format]

Paso 5: Crea la inyección de contexto

Define lo que el agente necesita saber de cada infraestructura:

Inventario de servicios
Dependencias
SLAs y criticidad
Incidentes anteriores

Paso 6: Prueba de forma incremental

Primero, solo lectura — ¿Entiende correctamente la infraestructura?
Segundo, análisis — ¿Son precisas sus evaluaciones?
Tercero, propuestas — ¿Son adecuadas las acciones que sugiere?
Al final, ejecución — ¿Ejecuta de forma segura, con aprobación?

Parte 7: Errores comunes

Error	Problema	Solución
Demasiado amplio	El agente no sabe cuándo intervenir	Acota el dominio
Sin matriz de autoridad	Pide permiso para todo	Define las acciones autónomas
Sin contexto	Consejos genéricos, no específicos	Inyecta el contexto de la infraestructura
Sin traspasos	El agente trabaja aislado	Define las relaciones
Sin personalización	El mismo comportamiento para todos los clientes	Agrega configuración por cliente
Sin pruebas	Peligroso en producción	Prueba de forma incremental

Por qué construimos 9 agentes y no 1

La tentación

“Construir una sola IA que se encargue de todo el DevOps.”

Suena eficiente. Un solo sistema para gobernarlos a todos.

La realidad

En dominios especializados, lo vertical supera a lo horizontal:

El monitoreo requiere una experiencia distinta a la de la seguridad
La optimización de costos requiere un contexto distinto al del despliegue
9 especialistas > 1 generalista

Cada uno de nuestros agentes es un experto profundo en una sola cosa. Colaboran cuando hace falta, pero no intentan hacerlo todo.

Nuestros agentes conocen TU infraestructura porque:

Leen tus archivos de contexto
Aplican tus personalizaciones
Siguen tus runbooks
Se integran con tus herramientas
Aprenden de tus incidentes

ChatGPT sabe de DevOps. Nuestros agentes conocen TU infraestructura.

Próximos pasos

Opción 1: Constrúyelo tú

Usa esta guía para crear agentes para tus propias necesidades. Empieza con un alcance acotado, prueba a fondo y amplía poco a poco.

Opción 2: Usa los nuestros

Nuestros 9 agentes ya están construidos, probados y curtidos en decenas de infraestructuras de clientes.

Agenda una llamada de descubrimiento para ver cómo nuestro equipo de IA puede trabajar con el tuyo.

Opción 3: Híbrido

Algunos clientes usan nuestros agentes mientras construyen los suyos para dominios específicos. Con gusto compartimos patrones y colaboramos.