Un agente 100% autónomo se define por una ausencia: nadie mirando. Ese es el lujo que promete y el riesgo que introduce — y este módulo construye lo que reemplaza al humano que miraba: telemetría que cuenta lo que pasa, alarmas que avisan solo cuando importa, y un mecanismo para que el agente pida permiso sin que nadie esté esperando su llamada. La observabilidad general de agentes ya vive en el catálogo (deploy-13: OTel, trazas, percentiles); aquí la aterrizamos en AWS y le sumamos el patrón que ningún módulo anterior podía dar: la aprobación asíncrona.

La tesis del módulo

Operar agentes autónomos exige tres piezas: métricas que midan el trabajo del agente (no solo su infraestructura), alarmas donde cada una exige una acción humana (o no existe), y un canal de aprobación asíncrona donde pedir permiso no cuesta cómputo y no responder tiene un desenlace decidido de antemano. La autonomía no es la ausencia de supervisión — es la supervisión convertida en arquitectura.

Qué medir de un agente

CloudWatch recoge métricas y logs de todo lo construido (colas, contenedores, Lambdas, Bedrock); X-Ray encadena las trazas de una petición a través de los servicios. El error típico no es medir poco — es medir solo la infraestructura. La CPU del contenedor del agente puede estar perfecta mientras el agente lleva tres horas clasificando todo como “urgente”. Las capas de medición, de abajo hacia arriba:

Capa	Métricas	Quién las da
Infraestructura	CPU, memoria, errores 5xx, throttling	CloudWatch, gratis
Flujo de trabajo	Profundidad de cola, edad del mensaje más viejo, mensajes en DLQ, duración de tareas	CloudWatch sobre SQS/ECS/Step Functions
Modelo	Invocaciones, latencia, tokens por llamada, errores/throttling de Bedrock	CloudWatch + invocation logging de Bedrock
Trabajo del agente	Tareas completadas/hora, tasa de escalada a humano, tasa de validación fallida, distribución de clasificaciones	Tuyas: métricas custom emitidas por el agente
Calidad	¿Las salidas son buenas?	Evals sobre muestras — el curso de Evals; aquí solo se alimenta

Las dos filas en negrita son las que la operación autónoma necesita y nadie instala por defecto. La edad del mensaje más viejo en la cola es la métrica reina del agente autónomo: si crece, el agente no está al día — sin importar qué diga su CPU. Y la distribución de salidas (¿qué % clasifica como cada categoría?) es el detector de deriva conductual barato: cuando el histograma de hoy no se parece al de la semana pasada, algo cambió — el modelo, los datos o un prompt.

Alarmas: cada una exige una acción, o no existe

La patología universal: cien alarmas, todas ignoradas. La regla de diseño es brutal y sana — una alarma existe solo si su disparo exige que un humano haga algo concreto. Lo demás es dashboard, no alarma. El set mínimo de la plataforma:

DLQ con mensajes (módulo 5): trabajo que falló N veces. Acción: diagnosticar el mensaje venenoso.
Edad de cola sobre umbral: el agente no da abasto o está caído. Acción: revisar el consumidor.
Tasa de escalada a humano anómala: el agente perdió confianza o el mundo cambió. Acción: revisar muestras.
Presupuesto 80%/100% (módulo 8) y anomalía de gasto: acción según el runbook del freno.
GuardDuty con hallazgo (módulo 10): acción: el runbook de seguridad.
Aprobación esperando > X horas (abajo): acción: aprobar, delegar o dejar que el timeout decida.

Nota la ausencia deliberada de “CPU al 80%” — si el auto-scaling funciona, no exige acción humana; es el ejemplo canónico de dashboard disfrazado de alarma.

El patrón estrella: aprobación asíncrona con Step Functions

La clase de gobernanza dejó la teoría: acciones de riesgo alto exigen aprobación, notificar ≠ aprobar, y la pregunta crítica es qué pasa si el aprobador no responde. AWS da la implementación exacta con Step Functions y su patrón de callback (waitForTaskToken): la máquina de estados emite un token, notifica al aprobador, y se detiene a esperar — sin cómputo, sin costo, hasta un año — hasta que alguien devuelva el token con un veredicto, o venza el timeout que tú definiste.

   APROBACIÓN ASÍNCRONA — EL FLUJO COMPLETO

  agente decide acción irreversible
  (ej: enviar cotización > $50.000)
        │
        ▼
  ┌───────────────────┐  notifica (SNS: correo/chat)
  │ Step Functions    │ ──────────► aprobador humano
  │ emite token y     │                  │
  │ ESPERA dormida    │ ◄────────────────┘
  │ (cero cómputo)    │  responde con el token
  └─────┬─────────┬───┘
        │         │
 aprueba│         │ timeout 24h sin respuesta
        ▼         ▼
  ┌──────────┐  ┌────────────────────┐
  │ ejecutar │  │ desenlace DECIDIDO │
  │ la acción│  │ antes: abortar y   │
  └──────────┘  │ escalar — nunca    │
                │ "aprobar por       │
                │ silencio"          │
                └────────────────────┘

Las decisiones de arquitectura dentro del patrón:

Qué exige aprobación se declara, no se improvisa: la política de la clase de gobernanza (por reversibilidad, radio, costo, visibilidad) mapeada a una lista concreta de acciones del agente. Todo lo demás fluye sin fricción — una plataforma donde todo pide permiso es un formulario, no un agente.
El timeout tiene un desenlace explícito y conservador: vencido el plazo, la acción se aborta y se escala — jamás “se aprueba por silencio”. El silencio aprueba solo en las películas y en los incidentes.
La espera es gratis por diseño: el patrón entero descansa en los módulos 3 y 5 — la máquina de estados duerme sin facturar, el agente ya murió (era efímero), y la respuesta del humano es solo otro evento que despierta el paso siguiente. La aprobación asíncrona es el examen final de la arquitectura event-driven: si tu diseño necesita un proceso vivo esperando el OK, algo de los módulos anteriores quedó mal puesto.
El veredicto queda escrito: quién aprobó/rechazó, cuándo, con qué contexto — al historial del módulo 6 y al trail del 10. La aprobación sin registro es un rumor.

Ojo — el aprobador también es un cuello de botella medible: si el 30% de las tareas espera aprobación y el aprobador tarda un día, tu agente autónomo tiene un SLA de un día. Las métricas del patrón (aprobaciones pendientes, tiempo hasta veredicto, % aprobado) van al dashboard — y una tasa de aprobación del 99,8% durante meses es datos para recalibrar la política: esa acción quizás ya no necesita permiso. La gobernanza también se opera.

El dashboard de la plataforma

Una pantalla, cinco preguntas — si exige scroll, sobra: ¿los agentes están al día? (edad de colas) · ¿a qué ritmo trabajan? (tareas/hora por agente) · ¿cuánto escalan a humanos? (tasa + pendientes de aprobación) · ¿cuánto gastan? (módulo 8, por caso) · ¿algo huele raro? (DLQs, anomalías, GuardDuty). Esa pantalla es el humano que miraba, destilado: quien la revisa dos veces al día opera una flota de agentes autónomos con la atención que antes exigía uno.

Errores comunes

Medir solo infraestructura. CPU sana y agente clasificando basura: las métricas del trabajo (throughput, escalada, distribución de salidas) son custom y son las que avisan primero.
Cien alarmas, cero acciones. Cada alarma sin acción asociada entrena al equipo a ignorar la que importaba. La regla es binaria: exige acción humana o es dashboard.
Aprobación síncrona disfrazada. Un contenedor vivo esperando el OK por horas es pagar por dormir y acoplar el agente al humor del aprobador. Step Functions con callback: espera gratis, desacoplada, con timeout.
Timeout sin desenlace decidido. “¿Y si nadie responde?” resuelto en producción a las 3 AM es un incidente; resuelto en diseño es una rama del diagrama. Conservador siempre: abortar y escalar.
Aprobar por silencio. La tentación de “si en 24h nadie objeta, procede” convierte cada olvido humano en una autorización. El silencio nunca es un veredicto.
No operar la gobernanza. La política de aprobaciones escrita una vez y jamás recalibrada acumula fricción muerta (lo siempre-aprobado) y huecos (lo nuevo sin clasificar). Las métricas del patrón existen para revisarla trimestre a trimestre.

La frase para llevarse

“Mide el trabajo y no solo la máquina, deja vivir únicamente las alarmas que exigen acción, y dale al agente un canal para pedir permiso donde esperar no cuesta nada y el silencio nunca aprueba. La autonomía no es que nadie supervise — es que la supervisión quedó escrita en la arquitectura.”

Qué viene

Módulo 12, el cierre: la arquitectura de referencia. Todas las decisiones del curso — cuentas, identidad, cómputo, red, colas, datos, gateway, FinOps, AgentCore, seguridad, operación — ensambladas en un solo diagrama: la plataforma completa corriendo el agente 100% autónomo de punta a punta, con cada pieza justificada por su módulo. Más el mapa de decisiones para adaptarla a tu escala, y el puente hacia los cursos de GCP y Azure: qué de todo esto viaja tal cual y qué cambia de nombre.

Arquitectura AWS — Módulo 11: operación autónoma