POC en producción · Operativo hoy

La primera plataforma autónoma de cambio para Kubernetes

Multi-agente que detecta, diagnostica, repara y documenta incidentes de forma autónoma — con human-in-the-loop solo donde importa.

~10 min
MTTR autónomo
60 s
Ciclo de detección
18
Tipos de anomalía
100 %
On-prem · GitOps
El status quo

Cuando un pod falla en producción a las 3 AM, el reloj corre.

El proceso es siempre el mismo y siempre lento. Cada minuto que el incidente permanece abierto cuesta dinero, reputación y horas de sueño del equipo on-call.

45+ min

MTTR típico por incidente

Desde la alerta hasta el cierre del cambio: detección manual, coordinación on-call, kubectl, RFC, aprobaciones y deploy.

🌙
3 AM

Trabajo nocturno recurrente

El mismo OOM se repite cada semana. El on-call lo sabe, lo reinicia, y el fix permanente nunca llega al backlog.

📋
0 %

Trazabilidad en frío

RFCs ad-hoc, runbooks desactualizados y postmortems que se quedan en pendiente. ITIL es teoría, la realidad es Slack.

⚡ Línea de tiempo de un incidente típico
T+0:00 Pod OOM-killed — alerta dispara, on-call recibe page Manual
T+0:05 Login a VPN + abrir Grafana, kubectl, ticket Jira Manual
T+0:12 Diagnóstico manual — leer logs, identificar causa probable Manual
T+0:18 kubectl rollout restart — pod restaurado temporalmente Manual
T+0:25 Crear RFC en ServiceNow — copiar/pegar contexto a mano Manual
T+0:35 Esperar aprobación del manager para subir el límite de memoria Manual
T+0:45 Editar YAML, commit, PR, merge, deploy — fix permanente en producción Manual
La oportunidad

Si la máquina puede observar, decidir, ejecutar y documentar — el humano solo aprueba.

El loop completo de incidente a deploy se reduce a un único punto crítico donde la supervisión humana aporta valor real: aprobar el cambio. Todo lo demás es trabajo mecánico que un agente con LLM y guardrails puede hacer mejor, más rápido y con trazabilidad nativa en Git + ITIL.

45 min
Proceso manual
~10 min
Autónomo
Estrategia

Multi-agente, no monolito.

Cada agente tiene un dominio claro, herramientas propias, memoria y guardrails. Se comunican vía un orquestador LangGraph con registro explícito de skills y tools.

Planner Grouper Batch Executor Supervisor loop replan

Patrón LangGraph

El orquestador descompone una intención en subtareas, las agrupa, las ejecuta en lotes paralelos y supervisa la calidad antes de cerrar el ciclo.

  • Aislamiento por dominio — un agente, una responsabilidad
  • Tools registrados — capacidades explícitas, auditable qué puede hacer cada uno
  • Memoria propia — Postgres + Qdrant (RAG) por agente
  • Tres frenos de seguridad — solo actúa si su confianza supera un umbral, se autopausa ante fallos repetidos y nunca corre dos instancias en paralelo
Los protagonistas

Dos agentes especializados que cierran el loop completo.

Raphael vigila la salud del cluster. Camael traduce los hallazgos en cambios permanentes con trazabilidad GitOps + ITIL.

R
Raphael
Site Reliability Engineer · Autónomo

Loop autónomo cada 60 segundos. Observa el cluster, detecta anomalías, diagnostica con LLM + RAG, decide la acción y la ejecuta dentro de los guardrails.

Observe Detect Diagnose Decide Act Report
  • 18 tipos de anomalías — OOM, CrashLoop, SLO burn, predictivos (predict_linear, deriv), infra proactiva
  • LLM on-prem — qwen3:14b + nomic-embed sobre RAG en Qdrant
  • Frenos de seguridad — umbral de confianza mínima para actuar, autopausa ante fallos repetidos, una sola instancia activa en HA y ventanas de mantenimiento configurables
  • Verificación T+10min — auto-rollback si el fix no funciona
C
Camael
DevOps Agentic · GitOps + ITIL v4

Recibe el handoff de Raphael y traduce el incidente en un cambio permanente: PR en Bitbucket + RFC en ServiceNow. El humano aprueba, ArgoCD despliega.

Read YAML LLM analyze PR RFC Approve Deploy
  • Bitbucket nativo — lee, edita y abre PR con diff exacto del cambio
  • ServiceNow ITIL v4 — RFC con flujo Draft → Assess → Scheduled → Implement → Closed
  • Aprobación humana — desde chat web o WhatsApp, sin abrir consolas
  • ArgoCD GitOps — el merge dispara el deploy, nada de kubectl directo
El loop completo

De anomalía detectada a postmortem cerrado, sin tocar consolas.

Cada paso queda registrado: en Git (PR), en ServiceNow (RFC), en PostgreSQL (incidente) y en Grafana (métricas). 100 % auditable, 100 % reversible.

Detección → Restart → PR → RFC → Aprobación → Merge → ArgoCD → Verificación → Postmortem

9 pasos · ~10 minutos · 1 punto humano

1
👁
Detección
Raphael · 60s
2
Rollout restart
Raphael · auto
3
📝
PR Bitbucket
Camael
4
📋
RFC ServiceNow
Camael · ITIL
5
Aprobar
Humano · WhatsApp
6
🔀
Merge
Bitbucket
7
🚀
Deploy
ArgoCD · GitOps
8
Verificar
Raphael · T+10m
9
📄
Postmortem
Raphael · LLM
Arquitectura técnica

Cómo funciona el loop autónomo por dentro.

Raphael implementa un loop Observe → Detect → Diagnose → Decide → Act → Report que corre cada 60 segundos con APScheduler. Cada fase es determinista y está instrumentada con métricas Prometheus. El LLM entra solo en la fase de diagnóstico, con RAG sobre runbooks en Qdrant y fallback determinista si falla.

Infraestructura

Así se ve la plataforma dentro del cluster.

MicroK8s single-node con GPU NVIDIA RTX 5070 dedicada a Ollama. Cuatro namespaces segregan apps, observabilidad, secretos y GitOps. Todo on-prem, todo vía Git, todo auditable.

Externo · fuera del cluster
🌐 Cloudflare Tunnel DNS + TLS
📘 Bitbucket source of truth
📋 ServiceNow ITIL v4 · RFC
📱 WhatsApp Web aprobación
↓ HTTPS · cert-manager · Let's Encrypt ↓
Ingress Layer · NGINX + cert-manager
/ → frontend-next:3000 /api → agentic-backend:8000 /llm → llm-adapter:80 /poc → poc-presentation grafana.* → grafana:80 argocd.* → argocd-server
↓ Service mesh interno · DNS cluster.local ↓
namespace: amael-ia
amael-agentic-backend FastAPI · LangGraph · orquestador
raphael-service SRE · standalone · v1.0.0
camael-service GitOps + ITIL · standalone · v1.0.0
frontend-next Next.js 14
whatsapp-bridge Puppeteer
llm-adapter OpenAI proxy
productivity-service Gmail/Calendar
poc-presentation nginx
PostgreSQL incidents · chat · postmortems
Redis dedup · counters · cache
Qdrant RAG · runbooks
MinIO S3 objects
Ollama qwen3:14b · GPU RTX 5070
day-planner cron 7:00 MX
github-runner self-hosted
↓ OTel exports · Prometheus scrape · Vault K8s Auth ↓
namespace: observability
Prometheus métricas · rw receiver
Grafana 11 dashboards
Tempo v2.9 traces · service map
OTel Collector OTLP 4317
DCGM exporter GPU metrics
namespace: argocd
ArgoCD sync ← Bitbucket main
application-controller
namespace: vault
HashiCorp Vault Raft · StatefulSet
K8s Auth Method TokenReview
Plano de control · cluster-wide
sre-agent-observer ClusterRole · read-only
sre-agent-healer Role · ns amael-ia
K8s Lease leader election
ServiceAccounts per-pod JWT
NetworkPolicies + TLS mTLS interno
Apps Observabilidad Datos / Control GitOps / GPU Secretos Ingress
Diagrama técnico de arquitectura

Blueprint completo — servicios, namespaces, flujos de datos.

Layout tipo drawio con los componentes reales del cluster, sus conexiones y los puertos internos. Útil para planear cambios o explicar el sistema en una pizarra.

EXTERNAL · INTERNET 🌐 Cloudflare 📘 Bitbucket 📋 ServiceNow 📱 WhatsApp Web HTTPS ◆ MICROK8S CLUSTER · node: lab-home GPU: NVIDIA RTX 5070 · Registry: registry.richardx.dev ns: amael-ia Ingress NGINX + cert-manager · TLS agentic-backend FastAPI + LangGraph orquestador :8000 · v1.10.94 raphael-service Raphael · SRE Loop 60s · standalone :8002 · v1.0.0 llm-adapter OpenAI-compat proxy :80 · v1.0.8 frontend-next Next.js 14 :3000 · v1.4.5 whatsapp-bridge Puppeteer · WA Web :3000 · v1.5.8 productivity-service :8001 · Gmail · Calendar camael-service Camael · GitOps + ITIL · :8003 standalone · v1.0.0 day-planner cron 7:00 MX · Mon–Fri poc-presentation nginx + ConfigMap ◈ DATA PLANE · StatefulSets · PVCs PostgreSQL incidents · chat postmortems · RFCs :5432 Redis dedup · counters cache · sessions :6379 Qdrant RAG vectors sre_runbooks :6333 MinIO S3 objects backups · files :9000 Ollama qwen3:14b + nomic-embed-text ⚡ GPU · :11434 / /api /llm / /wa infer() RAG ns: observability Prometheus :9090 · rw receiver Grafana :3000 · 11 dashboards Tempo v2.9 traces · service map OTel Collector OTLP :4317 DCGM exporter GPU metrics observe_metrics() /metrics · OTLP ns: vault Vault v1.21.2 · Raft StatefulSet · PVC K8s Auth TokenReview SA → policy secrets ns: argocd ArgoCD GitOps · sync ← Bitbucket/main App Controller StatefulSet reconcile loop POST /handoff Camael: open_pr() · create_rfc() sync kubectl apply ◆ CONTROL PLANE · cluster-wide sre-agent-observer · ClusterRole (read-only) sre-agent-healer · Role (ns amael-ia) K8s Lease · leader election ServiceAccounts · per-pod JWT NetworkPolicies · mTLS interno LEYENDA: HTTP/REST Data/SQL GitOps/Infer Observe/Metrics Secrets (Vault) Camael → Bitbucket Internal HTTP ⚙ Todos los Services son ClusterIP · expuestos vía Ingress NGINX con TLS (cert-manager + Cloudflare DNS challenge) ⚙ Storage: PVCs sobre MicroK8s hostpath-provisioner · Registry privado: registry.richardx.dev ⚙ Single-node cluster · GPU asignada exclusivamente a Ollama (nvidia.com/gpu: 1) · Rollouts Recreate para evitar lock de GPU
Scrollea horizontalmente en pantallas chicas · Todo lo mostrado está desplegado hoy · 4 namespaces · 1 nodo · 1 GPU
Recorrido de un incidente

Cómo fluyen los datos entre namespaces durante un fix.

  • 1. Prometheus (ns observability) scrapea métricas de amael-agentic-backend y detecta container_memory_usage_bytes > 85% del limit.
  • 2. Raphael (ns amael-ia) consulta Prometheus cada 60s, detecta anomalía HIGH_MEMORY y hace RAG sobre Qdrant usando Ollama para recuperar el runbook relevante.
  • 3. Raphael solicita ServiceAccount token → Vault (ns vault) valida vía K8s Auth Method → obtiene credenciales de Bitbucket.
  • 4. Raphael ejecuta ROLLOUT_RESTART usando Role sre-agent-healer (restringido a ns amael-ia) y dispara handoff a Camael en daemon thread.
  • 5. Camael lee el YAML del Deployment desde Bitbucket, calcula memory × multiplier, abre PR y crea RFC en ServiceNow.
  • 6. Humano aprueba desde WhatsApp → backend hace merge en Bitbucket → ArgoCD (ns argocd) sincroniza → nuevo pod arranca con el límite corregido.
  • 7. Raphael verifica a T+10min: si pod healthy → postmortem LLM + runbook auto-indexado en Qdrant. Si falla + deploy reciente → rollout undo.
  • 8. OTel Collector captura los spans del flujo; Tempo construye el service map; Grafana dashboard #8 muestra la línea de tiempo.
1
Observe
observe_cluster() · observe_metrics()
  • K8s API — pods, nodes, events, deployments (read-only ClusterRole)
  • Prometheus — CPU, memoria, 5xx, error rate por endpoint
  • Predictivopredict_linear y deriv para tendencias
  • Infra proactiva (P7) — disco de nodo, PVC, certificados TLS
2
Detect
detect_anomalies() · correlate()
  • Reglas estructurales — CrashLoop, OOM, ImagePullErr, HighRestarts
  • Thresholds configurables — via ConfigMap sre-agent-policy
  • Correlación multi-pod — agrupa anomalías relacionadas (P4-B)
  • Dedup en Redis — TTL evita alertar el mismo incidente dos veces
3
Diagnose
diagnose_with_llm()
  • LLM — qwen3:14b vía Ollama, timeout 30s
  • RAG — Qdrant sre_runbooks + nomic-embed-text
  • Confidence score — 0.0–1.0 por diagnóstico
  • Fallback determinista — si el LLM falla, decide por reglas
  • Blending histórico — 70% LLM / 30% éxitos pasados (P3-B)
4
Decide
decide_action()
  • Policy guardrailsROLLOUT_RESTART solo si confianza ≥ umbral
  • Restart limits — máximo N reinicios por deployment/hora
  • Maintenance windows — Redis TTL, pausa el loop
  • Severity gating — LOW/MEDIUM notifican, HIGH actúan
5
Act
execute_sre_action() · handoff
  • ROLLOUT_RESTART — Role sre-agent-healer namespace-scoped
  • NOTIFY_HUMAN — WhatsApp vía whatsapp-bridge
  • Handoff a Camael — daemon thread abre PR + RFC
  • Verificación T+10min — job diferido con APScheduler
6
Report
store_incident() · postmortem
  • PostgreSQL — tabla sre_incidents con timeline completo
  • Postmortem LLM — generado al cerrar cambio exitoso (P5-D)
  • Auto-runbook — si el fix funciona, se indexa en Qdrant (P4-D)
  • Métricasamael_sre_* a Prometheus + dashboard Grafana #8
Patrón multi-agente

Cómo se coordinan los agentes.

LangGraph orquesta. El registry explícito permite auditar qué tools tiene cada agente. Redis coordina state compartido. PostgreSQL es la bitácora auditable.

🧩
AgentRegistry explícito
Cada agente se registra con @AgentRegistry.register. La carga se hace en register_all_agents() al arrancar. Skills y tools están desacoplados — cualquier agente puede pedir una skill por nombre.
🔒
Leader election
Kubernetes Lease asegura que solo una instancia del SRE loop actúe, incluso con múltiples réplicas del raphael-service. Evita double-actions en HA (P3-D).
🔁
Handoff Raphael → Camael
Tras un ROLLOUT_RESTART exitoso, Raphael dispara un daemon thread que llama a handoff_to_camael(). Camael analiza el YAML, decide el multiplier y abre PR en Bitbucket + RFC en ServiceNow.
🗃️
Estado compartido
Redis — dedup (sre:incident:*), counters (sre:restarts:*), handoff (sre:gitops:*), PR tracking (bb:pending_pr:*). PostgreSQL — incidents, postmortems, SLOs.
📊
Traza distribuida
OpenTelemetry spans desde backend → raphael-service → Ollama. Tempo genera el service map automáticamente (metricsGenerator + prometheusRemoteWrite).
📱
Canal humano
WhatsApp Bridge expone /sre <cmd> bidireccional. Estado de pods, SLOs, incidentes, postmortems y aprobación de PRs desde el móvil — sin abrir kubectl.
Cobertura

18 tipos de anomalías — qué detecta y cómo reacciona.

Agrupadas por fuente de observación. ✓ auto-heal significa que Raphael ejecuta ROLLOUT_RESTART y dispara el handoff a Camael. ⚠ notify significa que requiere juicio humano y solo notifica.

Kubernetes API observe_cluster()
CRASH_LOOP Pod reinicia en bucle — container termina con exit ≠ 0 repetidamente auto-heal
OOM_KILLED Container OOMKilled por exceder el memory limit auto-heal
IMAGE_PULL_ERROR ErrImagePull / ImagePullBackOff — imagen no existe o registry inaccesible notify
POD_FAILED Pod en fase Failed, sin recuperación automática del scheduler auto-heal
POD_PENDING_STUCK Pod Pending > threshold (falta CPU/GPU, taints, PVC sin bind) notify
HIGH_RESTARTS Restart count por encima del umbral en ventana corta auto-heal
NODE_NOT_READY Nodo en NotReady — kubelet desconectado o condition taint notify
Prometheus métricas observe_metrics() · P4-A
HIGH_CPU Uso CPU por pod sostenido > threshold en ventana notify
HIGH_MEMORY Memoria > 85% del limit sin OOM aún — previene caída inminente auto-heal
HIGH_ERROR_RATE 5xx rate elevado por endpoint — degradación de servicio notify
SLO_BUDGET_BURNING Error budget quemándose más rápido que el rate target (P5-C) notify
Predictivo observe_trends() · P5-A
DISK_EXHAUSTION_PREDICTED predict_linear proyecta saturación de disco en ≤ N horas notify
MEMORY_LEAK_PREDICTED deriv positiva sostenida en heap — leak confirmado auto-heal
ERROR_RATE_ESCALATING deriv de errores creciente — escalada detectada antes del breach notify
Infra proactiva observe_node_resources / pvc / certs · P7
NODE_DISK_HIGH Disco de nodo > 80% — node_filesystem_avail_bytes notify
NODE_MEMORY_HIGH RAM de nodo > 90% — node_memory_MemAvailable_bytes notify
PVC_CAPACITY_HIGH PVC > 80% — kubelet_volume_stats_used_bytes notify
CERTIFICATE_EXPIRING TLS cert de cert-manager expira en ≤ 14 días notify
Guardrails

Seis frenos que evitan que el agente rompa producción.

Autonomía sin guardrails es un riesgo. El diseño asume que el LLM puede equivocarse, que el cluster puede estar en mantenimiento, y que el fix puede fallar.

🔐
RBAC segmentado
sre-agent-observer (ClusterRole, read-only) separado de sre-agent-healer (Role, namespace amael-ia). Nunca puede actuar fuera del alcance autorizado.
🎯
Confidence threshold
Solo actúa si el diagnóstico LLM supera el umbral configurado (default 0.7). Confianza baja = NOTIFY_HUMAN automático.
Circuit breaker
Si falla N veces seguidas, se autopausa por ventana configurable. Evita tormentas de reinicios ante bugs recurrentes.
🔒
Leader lease
K8s Lease garantiza una sola instancia activa del loop. HA sin double-actions.
Maintenance windows
Redis TTL key pausa el loop durante despliegues grandes o ventanas de cambio. Se activa vía /sre maintenance on.
↩️
Auto-rollback
Verificación T+10min: si el deployment sigue unhealthy y hubo deploy reciente, rollout undo automático (P5-B).

¿Dónde empujar esto más? Más anomalías predictivas (saturación de sockets, cache miss rate), aprendizaje activo con feedback del postmortem para re-tunear thresholds, y ampliar el handoff a otros tipos de cambio (configmaps, HPA, PDBs) más allá de ajustes de recursos.

Operativo hoy

No es prototipo. Es producción on-premise.

Todo lo que se muestra ya está desplegado, integrado y monitoreado. Cluster propio, GPU propia, modelos propios — sin dependencia de APIs externas.

11
Dashboards Grafana
18
Anomalías cubiertas
15+
Runbooks indexados
6
Agentes registrados
Agentes & LLM
amael-agentic-backend
FastAPI · LangGraph
v1.10.94
Orquestador multi-agente con registry explícito de skills, tools y agentes.
raphael-service (Raphael)
SRE Autónomo · standalone
v1.0.0
Loop 60s con 6 fases (P0–P5) + P7 infra proactiva. Pod independiente con RBAC propio. Leader election vía K8s Lease.
camael-service (Camael)
DevOps · standalone
v1.0.0
Handoff HTTP desde Raphael. Abre PR en Bitbucket + crea RFC en ServiceNow. Fallback Redis si el pod está caído.
Ollama
LLM Inference · GPU
qwen3:14b
Razonamiento on-prem sobre NVIDIA RTX 5070. Embeddings con nomic-embed-text.
GitOps · ITIL · Aprobaciones
ArgoCD
GitOps · Deploy
activo
Sincroniza cambios desde Bitbucket. Sin kubectl directo, todo vía Git.
Bitbucket
Source of Truth
activo
Camael abre PR con diff exacto. Trazable, revisable, reversible.
ServiceNow
ITIL v4 · RFC
integrado
RFC autogenerado con flujo Draft → Assess → Scheduled → Implement → Closed.
WhatsApp Bridge
Aprobación humana
v1.5.8
Comandos /sre bidireccionales. Aprobación de PR sin abrir consolas.
Observabilidad & Storage
Prometheus + Grafana
Métricas
11 dashboards
Golden signals, RAG, REASONING, supervisor, security, SRE, service map.
Tempo + OTel
Traces · Service Map
v2.9.0
Traza distribuida entre agentes con grafo de servicios autogenerado.
PostgreSQL · Redis
Estado · Cache
activo
Incidentes, postmortems, SLOs, dedup de alertas y maintenance windows.
Qdrant · MinIO
RAG · Object Storage
activo
Vector DB por usuario para RAG. Runbooks SRE indexados con auto-generación.
HashiCorp Vault
Secrets
v1.21.2
Auth Kubernetes nativo. Tokens OAuth y credenciales por servicio.
cert-manager · Cloudflare
TLS · Tunnel
activo
Certificados automáticos vía DNS challenge. Acceso externo seguro.
Demo en vivo

4 escenarios. ~10 minutos cada uno. Cero kubectl.

El loop completo se observa en tiempo real desde 6 ventanas. Mientras un escenario corre, cada herramienta muestra su parte del flujo: detección, PR, RFC, deploy y cierre.

Escenarios reproducibles

Cada uno simula un fallo real de producción y dispara el loop SRE → GitOps → ITIL completo.

Escenario A
OOM Kill
Stress 32M, límite 64Mi → pod muere por memoria insuficiente.
→ fix 64Mi → 128Mi
Escenario B
CrashLoop
Stress 40M, límite 16Mi → reinicios constantes.
→ fix 16Mi → 48Mi
Escenario C
High Memory
Stress 90M sobre 100Mi → alerta predictiva sin caída aún.
→ fix 100Mi → 200Mi
Escenario D
Deployment Degraded
2 réplicas, ambas en OOM → servicio degradado.
→ fix 20Mi → 40Mi
Centro de mando

Las 6 ventanas que muestran el loop en vivo

Abre estas pestañas antes de iniciar el demo. Cada herramienta es la evidencia independiente de un paso del flujo.

⚙ Cómo correr el demo
  1. Abrir las 6 ventanas de arriba en pestañas separadas
  2. Ejecutar bash poc-reset.sh — limpia Redis, PostgreSQL y declina PRs abiertos
  3. Ejecutar bash poc-demo.sh A — guía paso a paso del escenario OOM (recomendado)
  4. Aprobar el PR desde el chat de Amael o WhatsApp escribiendo APROBAR
  5. Esperar T+10min para verificación automática y postmortem generado por LLM