El agente endurecido vive en un laptop; los 12.000 correos viven en el mundo. Esta fase los junta aplicando lo que el catálogo ya dejó decidido: el flujo profesional del código a producción y la arquitectura de la serie de nubes. Elegimos AWS por continuidad con el curso fundacional — y porque la tabla tri-cloud garantiza que la traducción, si Finandes viviera en otra nube, sería un ejercicio y no un proyecto.

La tesis de la fase

El despliegue no inventa arquitectura: instancia la de referencia en la escala “producción” — el trabajo despierta cómputo efímero, el cómputo piensa por el punto único, actúa dentro de jaulas, y todo es código con la suite como gate — y su disciplina central es el checklist: las cuatro piezas no diferibles (identidad propia, cola con DLQ, tags, budget con freno) marcadas antes de que el primer correo real toque el sistema. Lo demás es Terraform aplicando decisiones que los módulos ya argumentaron.

La arquitectura instanciada

Los cuatro tiempos, con nombres del proyecto:

   EL AGENTE DE FINANDES EN PRODUCCIÓN (AWS)

  correo llega a soporte@finandes
       │  (integración del buzón → evento)
       ▼
  ┌─────────────┐   reintentos con tope;
  │ SQS:        │   lo venenoso → DLQ
  │ correos-in  │   con alarma
  │ (+DLQ)      │
  └──────┬──────┘
         ▼  KEDA-style: escala por la cola
  ┌───────────────────────────────────────┐
  │ AGENTE — job efímero (Fargate)        │
  │ rol: invocar SU perfil Bedrock, leer  │
  │ SU cola, escribir SU tabla — nada más │
  │ + mcp-finandes-soporte (fase 4) al    │
  │ lado, con SU rol de solo-CRM          │
  └───────┬───────────────────┬───────────┘
          │ pensar            │ estado
          ▼                   ▼
  ┌───────────────┐   ┌────────────────────┐
  │ Bedrock       │   │ DynamoDB (triaje)  │
  │ perfil        │   │ Aurora+pgvector    │
  │ "cap-agente"  │   │ (corpus, fase 2)   │
  │ + guardrail   │   │ S3 (borradores)    │
  └───────────────┘   └────────────────────┘

  red: subredes privadas · endpoints (Bedrock,
  SQS, S3) · egress = SOLO el API del buzón
  transversal: CloudTrail · tags cap=agente ·
  budget 80/100% con freno por rol

Las decisiones, con su módulo de origen en vez de re-argumento: cómputo efímero por cola (el agente es trabajo que despierta cómputo — aws-03; 12.000 correos/mes son ráfagas, no tráfico continuo), un rol por pieza con permisos que caben en una pantalla (aws-02 — el agente no puede leer el CRM: solo el servidor MCP puede, y solo lectura), la red que no negocia (privadas + endpoints + egress de exactamente un destino externo — aws-04: la trifecta rota por diseño), y Bedrock como gateway con el perfil de inferencia cap-agente que atribuye cada token y el guardrail de la fase 6 aplicado en el punto único (aws-07/08).

Todo como código, con la suite en la puerta

La infraestructura completa es Terraform en el repo del proyecto — revisable, reproducible, con dev y prod como workspaces — y el flujo de cambios cierra el círculo con la fase 5:

  PR (código, prompt, corpus o Terraform)
     │
     ▼
  CI: tests de código + LA SUITE COMPLETA
  (los gates de la fase 5 son gates de deploy)
     │ pasa
     ▼
  deploy a DEV → suite contra dev (humo)
     │ pasa
     ▼
  deploy a PROD (el rollout gradual llega
  en la fase 8 — por ahora, prod = piloto
  con 100% borrador a revisión)

La frase que importa: los gates de evaluación son gates de despliegue. El cambio de prompt que degrada la clasificación no llega a producción por el mismo mecanismo que el bug de código — la disciplina de CI — y las evals como tests — tratando al comportamiento del agente como lo que es: parte del sistema.

El checklist de las no diferibles — y el resto de la escala

Antes del primer correo real, la tabla de escalas exige su columna “producción” completa. El corte del proyecto:

Pieza	Estado
Rol propio por pieza (agente / MCP / pipeline)	✅ fase 7
Cola con DLQ y alarma	✅ fase 7
Tags (`cap=agente`) + perfil de inferencia	✅ fase 7
Budget 80/100% con freno selectivo por rol	✅ fase 7
Subredes privadas + endpoints + egress corto	✅ fase 7
Guardrails en el punto único	✅ fase 6→7
CMK sobre el historial de triaje	✅ fase 7
CloudTrail a la cuenta de seguridad	✅ (la landing zone cloud de Finandes — cuentas, CloudTrail, cuenta de seguridad — ya existía; la landing zone de IA de caso-06 es la que este proyecto construye en las fases 2, 6 y 7, y por eso el TCO del caso la carga)
Dashboard + alarmas + aprobación asíncrona	🔜 fase 8

Ojo — el CRM real recién ahora: las herramientas de la fase 4 corrieron contra datos sintéticos por una razón que esta fase revela: conectar el CRM real exigía exactamente lo que recién ahora existe — el rol de solo-lectura auditado, la red privada, el perímetro, el registro de cada consulta. El orden de las fases no fue estético: los datos reales llegan cuando las jaulas están puestas — y esa frase, generalizada, es de las mejores políticas de proyecto que este capstone puede enseñar.

El entregable: el agente en producción-piloto — correos reales entrando por la cola, borradores con cita saliendo a la bandeja de revisión del equipo, cada token atribuido, cada acción registrada, y el freno probado con un simulacro de presupuesto (el game day mínimo: se cruza el umbral sintéticamente, el rol pierde InvokeModel, la cola retiene, se restaura — 20 minutos que compran certeza).

Errores comunes

Inventar arquitectura en la fase de deploy. Las decisiones ya estaban argumentadas en doce módulos; el despliegue las instancia. El que diseña de nuevo aquí está dudando de su propio catálogo — o no lo leyó.
El servicio 24/7 para ráfagas. 12.000 correos/mes en un contenedor siempre vivo es el anti-patrón fundacional de la serie. Job efímero por cola; la cuenta lo agradece.
Un rol para todo el proyecto. El agente que puede leer el CRM directamente anula la arquitectura de la fase 4. Un rol por pieza — la pantalla de permisos de cada uno se lee en un vistazo.
Suite y deploy desacoplados. El CI que despliega sin correr los gates de la fase 5 deja la puerta por donde entra la regresión “que en local andaba”. Los gates son de despliegue o no son gates.
Datos reales antes que jaulas. El CRM conectado “para probar” en la fase 4 habría sido el incidente. El orden del capstone es la política: jaulas primero, datos después.
El freno sin simulacro. El kill switch que nunca se probó es una esperanza con nombre técnico. Veinte minutos de game day antes del piloto — y dormir mejor doce semanas.

La frase para llevarse

“Desplegar es instanciar decisiones ya tomadas: el trabajo despierta al job, el job piensa por el punto único con su perfil y su guardrail, todo enjaulado y todo como código — con la suite como gate de despliegue y las cuatro no diferibles marcadas antes del primer correo real. Y la política que el orden de las fases enseñó: los datos reales llegan cuando las jaulas están puestas.”

Qué viene

Fase 8: operar. El piloto corre; ahora hay que verlo sin mirarlo: las métricas del trabajo (edad de cola, tasa de derivación, distribución de categorías como detector de deriva), el dashboard de cinco preguntas, las alarmas que exigen acción, la aprobación asíncrona para el certificado — y el holdout del 20% empezando a medir lo único que al comité le importa: el desvío efectivo contra el baseline.

Capstone — Fase 7: desplegar