Producción

1. Del demo al producto

Existe una brecha enorme entre "el agente funciona en mi terminal" y "el agente atiende a 500 empleados sin supervisión". No es una brecha de inteligencia del modelo: es una brecha de ingeniería de sistemas. El código que orquesta al LLM es quizá el 20% del sistema productivo; el otro 80% es todo lo que este módulo cubre.

        DEMO (tu máquina)                    PRODUCCIÓN (Azure)
  ┌─────────────────────────┐        ┌──────────────────────────────────┐
  │ python main.py          │        │ API HTTP con autenticación       │
  │ API key en .env         │        │ Managed Identity + Key Vault     │
  │ historial en una lista  │        │ PostgreSQL (checkpoints)         │
  │ un usuario: tú          │        │ N usuarios concurrentes          │
  │ si falla, reinicias     │        │ retries, timeouts, fallbacks     │
  │ print() para depurar    │        │ OpenTelemetry → App Insights     │
  │ costo: invisible        │        │ presupuestos, alertas, dashboards│
  └─────────────────────────┘        └──────────────────────────────────┘

Cada fila de la derecha es una sección de este módulo. La buena noticia: casi nada de esto es exclusivo de la IA. Son prácticas estándar de sistemas distribuidos, aplicadas a un componente nuevo (el LLM) que tiene dos particularidades que lo cambian todo:

1. Es no determinista: la misma entrada puede producir salidas distintas, así que la evaluación continua del Módulo 9 se vuelve parte del pipeline de despliegue, no un paso opcional.
2. Cobra por uso con granularidad de token: cada request tiene un costo variable y medible, así que el costo deja de ser un tema de finanzas y se convierte en una métrica de ingeniería, al mismo nivel que la latencia.

2. Empaquetar el agente: FastAPI y Docker

La capa de API: FastAPI

Analogía: hasta ahora tu agente es como un motor montado en un banco de pruebas — potente, pero nadie puede conducirlo. FastAPI es el chasis: convierte el motor en un vehículo con puertas (endpoints), tablero (documentación automática) y cinturones de seguridad (validación de entrada).

FastAPI es el framework estándar de facto para exponer sistemas de LLM en Python, por tres razones concretas:

• Asíncrono nativo. Una llamada al LLM tarda segundos; con async/await el servidor atiende otras peticiones mientras espera, en lugar de bloquear un hilo por usuario. Para quien viene de Node: es exactamente el mismo modelo de event loop que ya conoces.
• Validación con Pydantic. Los mismos modelos Pydantic de los structured outputs (Módulo 1) validan aquí los requests entrantes: tipado en la frontera del sistema.
• Streaming integrado. Soporta Server-Sent Events, el mismo transporte del streaming de tokens (Módulo 1) y del transporte HTTP de MCP (Módulo 5).

El esqueleto mínimo de un agente detrás de una API:

# app/main.py
from fastapi import FastAPI
from fastapi.responses import StreamingResponse
from pydantic import BaseModel
 
app = FastAPI(title="Employee Assistant API")
 
class ChatRequest(BaseModel):
    thread_id: str      # identifica la conversación (checkpointer, Módulo 8)
    message: str
 
@app.post("/chat")
async def chat(req: ChatRequest):
    async def stream():
        async for chunk in agent.astream(req.message, thread_id=req.thread_id):
            yield f"data: {chunk}\n\n"          # formato SSE
    return StreamingResponse(stream(), media_type="text/event-stream")
 
@app.get("/health")
async def health():
    return {"status": "ok"}                      # usado por el orquestador

El endpoint /health parece trivial pero es obligatorio: los orquestadores de contenedores (siguiente sección) lo consultan periódicamente para decidir si tu servicio está vivo o hay que reiniciarlo.

Docker: el contenedor de transporte

Analogía: antes de los contenedores marítimos, cargar un barco era artesanal — cada mercancía con su forma, su embalaje, sus grúas especiales. El contenedor estandarizó la caja, y de pronto cualquier barco, tren o camión podía transportar cualquier cosa. Docker hace lo mismo con el software: empaqueta tu aplicación con su sistema operativo, su versión exacta de Python y todas sus dependencias en una imagen inmutable que se ejecuta idéntica en tu laptop, en el servidor de un colega y en Azure. "En mi máquina funciona" deja de ser un problema porque tu máquina viaja con el código.

Un Dockerfile de calidad productiva para el agente:

# ---- Etapa 1: instalar dependencias ----
FROM python:3.12-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir --prefix=/install -r requirements.txt
 
# ---- Etapa 2: imagen final, mínima ----
FROM python:3.12-slim
WORKDIR /app
COPY --from=builder /install /usr/local
COPY app/ ./app/
 
# Nunca ejecutes como root dentro del contenedor
RUN useradd --create-home appuser
USER appuser
 
EXPOSE 8000
CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000"]

Tres decisiones de ese archivo que distinguen un Dockerfile de tutorial de uno productivo:

• Multi-stage build: la etapa builder compila e instala; la imagen final solo copia el resultado. La imagen pesa 200 MB en lugar de 1 GB, y menos software instalado significa menos superficie de ataque.
• Usuario no root: si alguien compromete tu aplicación (por ejemplo, vía prompt injection que escala a ejecución de código), el atacante queda atrapado como usuario sin privilegios.
• Versiones fijadas: requirements.txt con versiones exactas (langgraph==0.4.2, no langgraph). Una imagen debe ser reproducible: construirla dos veces produce el mismo resultado.

El flujo completo hasta Azure:

  código ──► docker build ──► imagen local ──► docker push ──► Azure Container
                                                               Registry (ACR)
                                                                     │
                                                                     ▼
                                                          Azure Container Apps
                                                          descarga y ejecuta

3. Dónde ejecutarlo: Container Apps, AKS y Functions

Azure ofrece varios lugares donde ejecutar un contenedor. Elegir mal no rompe el sistema, pero te hace pagar de más o administrar de más. El criterio de decisión:

  ¿Qué tan largo y complejo es el trabajo?
 
  Tarea corta, disparada por evento          ──►  Azure Functions
  (procesar un correo, un timer, un webhook)
 
  API de agentes, conversaciones, streaming  ──►  Azure Container Apps  ★ default
  (el 90% de los sistemas de este curso)
 
  Decenas de servicios, requisitos K8s       ──►  AKS (Kubernetes)
  (equipos de plataforma dedicados)

Azure Container Apps: el default correcto

Analogía: Kubernetes es como ser dueño de un edificio — control total, pero tú pagas mantenimiento, seguridad y plomería. Azure Container Apps (ACA) es como rentar oficinas con servicios incluidos: traes tus muebles (el contenedor) y el edificio se encarga del resto.

ACA ejecuta contenedores sin que administres servidores, y sus tres capacidades encajan de forma natural con sistemas de agentes:

• Escalado a cero. Si nadie usa el asistente de madrugada, ACA apaga las réplicas y el costo de cómputo baja a cero. Con la primera petición de la mañana, arranca una réplica en segundos. Para un asistente interno de empresa (uso intenso 9 a 18 h, nulo de noche) esto reduce el costo de cómputo en más de la mitad.
• Escalado por reglas (KEDA). Define "una réplica por cada 20 peticiones concurrentes" y ACA crea y destruye réplicas solas. Las llamadas a LLM son lentas (segundos), así que la concurrencia se acumula rápido; el escalado horizontal es la respuesta.
• Revisiones. Cada despliegue crea una revisión nueva sin destruir la anterior, y puedes repartir el tráfico: 90% a la versión estable, 10% a la nueva. Es la infraestructura del canary deployment — y combinado con la evaluación del Módulo 9, permite probar un prompt nuevo con tráfico real acotado antes de comprometerse.

El despliegue esencial en CLI:

az containerapp create \
  --name employee-assistant \
  --resource-group rg-agents-prod \
  --environment aca-env-prod \
  --image acragents.azurecr.io/employee-assistant:v1.4.0 \
  --target-port 8000 \
  --ingress external \
  --min-replicas 0 \
  --max-replicas 10 \
  --system-assigned      # Managed Identity, sección de seguridad

Kubernetes y AKS: saber que existe, saber cuándo no usarlo

Kubernetes (K8s) es el orquestador de contenedores estándar de la industria, y AKS es su versión administrada en Azure. Conceptualmente, ACA es una capa de simplificación construida encima de tecnología Kubernetes: los conceptos se corresponden.

  Kubernetes            Container Apps          Idea
  ──────────            ──────────────          ────
  Pod                   Réplica                 instancia corriendo de tu contenedor
  Deployment            Container App           definición de qué correr y cuántas copias
  Service / Ingress     Ingress                 cómo llega el tráfico
  HPA / KEDA            Reglas de escalado      cuándo crecer y encoger

AKS se justifica cuando necesitas lo que ACA abstrae: GPUs dedicadas para modelos self-hosted, políticas de red muy finas, decenas de microservicios con service mesh, o un equipo de plataforma que ya opera Kubernetes. Para un sistema de agentes que llama a Azure OpenAI (el modelo vive en el servicio de Microsoft, no en tu clúster), esa potencia sobra: pagarías en complejidad operativa algo que no usas.

Azure Functions: el especialista en eventos

Azure Functions ejecuta código en respuesta a eventos, con facturación por ejecución. En una arquitectura de agentes ocupa los papeles cortos y disparados por algo:

• Un timer que cada noche reindexa los documentos de SharePoint en Azure AI Search (el pipeline de ingestión del Módulo 7).
• Un webhook que recibe notificaciones de Microsoft Graph ("llegó un correo nuevo") y encola trabajo para un agente.
• Tareas de mantenimiento: limpiar conversaciones viejas, agregar métricas de costo diarias.

Lo que Functions no debe hacer: sostener la conversación principal del agente. Los límites de timeout y el modelo de arranque en frío pelean contra conversaciones largas con streaming. Regla práctica: Functions para reaccionar, Container Apps para conversar.

4. Estado y memoria: PostgreSQL y Redis

El Módulo 1 estableció el hecho fundacional: el LLM es stateless, no recuerda nada entre llamadas. En el demo, la "memoria" era una lista de Python que moría al cerrar la terminal. En producción, donde hay N réplicas del contenedor y cualquiera puede atender la siguiente petición del mismo usuario, el estado tiene que vivir fuera del proceso — en almacenamiento compartido que todas las réplicas ven.

   usuario A ──► réplica 1 ─┐
   usuario B ──► réplica 2 ─┼──►  PostgreSQL  (estado durable: conversaciones,
   usuario A ──► réplica 3 ─┘                  checkpoints, auditoría)
        (siguiente mensaje,      │
         otra réplica)           └─►  Redis    (estado veloz: caché, sesiones,
                                               rate limiting)

La división del trabajo sigue una regla simple: PostgreSQL guarda lo que no puedes perder; Redis acelera lo que no quieres repetir.

PostgreSQL: la memoria durable

PostgreSQL es la base relacional de código abierto que se ha convertido en la navaja suiza de los sistemas de agentes, porque cubre tres necesidades con una sola pieza (en Azure: Azure Database for PostgreSQL Flexible Server):

Checkpoints del grafo. En el Módulo 8, LangGraph persistía el estado de la conversación con un checkpointer y un thread_id. En el demo era memoria o SQLite; en producción es el checkpointer de Postgres — mismo código, distinto backend:

from langgraph.checkpoint.postgres.aio import AsyncPostgresSaver
 
async with AsyncPostgresSaver.from_conn_string(DATABASE_URL) as checkpointer:
    graph = builder.compile(checkpointer=checkpointer)
    # Cualquier réplica puede retomar cualquier conversación:
    # el estado vive en la tabla, no en el proceso.

Este cambio de una línea es lo que hace posible el escalado horizontal de la sección anterior: si el estado viviera en la RAM de la réplica 1, el usuario quedaría "pegado" a esa réplica y el escalado a cero destruiría conversaciones.

Auditoría. Un asistente que envía correos y agenda reuniones en nombre de empleados necesita un registro inmutable: quién pidió qué, qué herramientas se ejecutaron con qué argumentos, qué respondió el modelo. Una tabla tool_executions con timestamp, usuario, herramienta, argumentos y resultado convierte "¿por qué el agente envió ese correo?" de un misterio en una consulta SQL.

Vectores, si el proyecto es pequeño. La extensión pgvector añade búsqueda vectorial a Postgres. Para el RAG del Módulo 7 a escala corporativa, Azure AI Search sigue siendo la opción correcta (búsqueda híbrida, re-ranking semántico); pero para un proyecto con miles — no millones — de fragmentos, pgvector evita un servicio entero.

Redis: la memoria veloz

Analogía: PostgreSQL es el archivero del sótano — todo está ahí, ordenado y a salvo, pero ir a buscarlo toma tiempo. Redis es la bandeja sobre tu escritorio: solo lo que usas ahora mismo, a un brazo de distancia. Es una base de datos en RAM con latencias por debajo del milisegundo (en Azure: Azure Managed Redis), y en sistemas de agentes juega cuatro papeles:

Caché de respuestas. Las preguntas de los empleados se repiten brutalmente: "¿cuántos días de vacaciones tengo?", "¿cuál es la política de home office?". Cachear la respuesta con un TTL corto convierte la segunda aparición de la pregunta en una lectura de milisegundos con costo cero de tokens. El impacto se calcula, no se intuye — con 10,000 preguntas al mes, 30% de repetidas exactas y un costo promedio de 0.8 centavos de dólar por respuesta:

  sin caché:  10,000 × $0.008              = $80.00 /mes
  con caché:   7,000 × $0.008 + 3,000 × ~0 = $56.00 /mes   (−30%)
  y las 3,000 respuestas cacheadas llegan en ~5 ms en vez de ~4 s

Para preguntas parecidas pero no idénticas existe el semantic caching (cachear por similitud de embeddings, Módulo 1), con una advertencia: un umbral de similitud laxo devuelve respuestas incorrectas a preguntas que solo parecen iguales ("vacaciones" vs "vacaciones no gozadas al renunciar"). Empieza con caché exacta; añade la semántica solo con evaluación (Módulo 9) que demuestre que no degrada la calidad.

Caché de embeddings. Antes de vectorizar un texto, consulta si su hash ya tiene embedding calculado. En pipelines de ingestión que se re-ejecutan (el indexador nocturno de SharePoint), esto elimina la mayoría de las llamadas al modelo de embeddings.

Rate limiting. Un contador por usuario con expiración (INCR + EXPIRE) implementa "máximo 30 mensajes por minuto por empleado" en dos operaciones atómicas. Sin esto, un script accidental — o un empleado creativo — puede consumir tu cuota de tokens de la hora en minutos.

Estado efímero compartido. Sesiones, locks distribuidos ("este documento ya lo está procesando otra réplica"), colas ligeras de trabajo entre agentes.

5. Seguridad: identidades, secretos y permisos

Un asistente de empleados productivo toca correo, calendario, SharePoint y SQL. Cada una de esas conexiones es una llave, y la pregunta de seguridad central es: ¿dónde viven las llaves y qué abre cada una?

Managed Identity: la mejor llave es la que no existe

En el demo, la API key de Azure OpenAI vivía en un archivo .env. En producción ese patrón es una bomba de tiempo: la clave termina en un commit, en un log, en un backup. La solución de Azure es la Managed Identity (Módulo 2, ahora en serio): el contenedor en ACA recibe una identidad de Entra ID administrada por la plataforma, y los servicios se autorizan entre sí por identidad, sin ningún secreto que guardar.

# Ni una sola clave en el código ni en variables de entorno
from azure.identity.aio import DefaultAzureCredential
from azure.ai.openai.aio import AsyncAzureOpenAI  # patrón del Módulo 2
 
credential = DefaultAzureCredential()
# En local usa tu 'az login'; en ACA usa la Managed Identity. Mismo código.

La autorización se otorga con roles RBAC de grano fino: la identidad del contenedor recibe Cognitive Services OpenAI User sobre el recurso de Azure OpenAI, lectura sobre la base de datos, y nada más. Si el contenedor es comprometido, el atacante hereda exactamente esos permisos — no una llave maestra.

Key Vault: para las llaves que sí tienen que existir

Los servicios externos a Azure (la API del clima, un SaaS de terceros) sí requieren claves. Estas viven en Azure Key Vault, y el contenedor las lee en runtime usando su Managed Identity — la única credencial que "posee" el contenedor es su propia identidad, que Azure rota y protege. ACA integra Key Vault directamente: la app referencia el secreto y la plataforma lo inyecta, con auditoría de cada acceso.

  Jerarquía de credenciales, de mejor a peor:
 
  1. Managed Identity        no hay secreto            ★ default para todo lo Azure
  2. Key Vault + MI          secreto centralizado,     para APIs externas
                             rotable, auditado
  3. Variable de entorno     visible en la config      solo para valores no sensibles
  4. Hardcodeado / .env      en el repo                nunca en producción
     en commit

El agente como usuario: permisos delegados y mínimo privilegio

La decisión de seguridad más importante del proyecto final no es criptográfica sino de diseño de permisos: cuando el asistente lee el correo de un empleado vía Microsoft Graph (Módulo 6), ¿con qué permisos actúa?

• Permisos de aplicación: el agente puede leer el correo de todos los empleados. Simple de implementar, catastrófico si algo sale mal — una prompt injection en un correo (Módulo 2) podría exfiltrar buzones ajenos.
• Permisos delegados (On-Behalf-Of): el agente actúa como el usuario autenticado, y Graph aplica los permisos que ese empleado ya tiene. El agente que atiende a María físicamente no puede leer el buzón de Pedro, porque María no puede.

La regla del Módulo 6 — las herramientas definen el perímetro de lo que el agente puede hacer — se completa aquí: el perímetro real es la intersección de las herramientas expuestas y los permisos de la identidad con que se ejecutan. El LLM puede ser engañado; los permisos, no. Por eso el diseño correcto asume que el modelo será manipulado alguna vez y hace que el radio de daño de esa manipulación sea mínimo: permisos delegados, identidades de mínimo privilegio, confirmación humana para acciones irreversibles (enviar correo, borrar) y Content Safety con Prompt Shields (Módulo 2) filtrando el contenido que entra desde documentos y correos.

6. Observabilidad: ver lo que el sistema hace

El Módulo 9 construyó la instrumentación: trazas OpenTelemetry que registran cada llamada al LLM, cada invocación de herramienta, cada paso del grafo. En producción esa instrumentación se conecta a su destino definitivo — Application Insights (parte de Azure Monitor) — y se le suman los otros dos pilares de la observabilidad:

  TRAZAS    "¿qué pasó en ESTA petición?"     el hilo detallado de una conversación:
                                              spans de LLM, tools, retrieval
  MÉTRICAS  "¿cómo se comporta el SISTEMA?"   números agregados en el tiempo:
                                              latencia, tokens, errores, costo
  LOGS      "¿qué dijo el código?"            eventos discretos con contexto

La conexión es configuración, no re-arquitectura — el trabajo duro ya se hizo en el Módulo 9:

from azure.monitor.opentelemetry import configure_azure_monitor
 
configure_azure_monitor()  # usa la Managed Identity; exporta trazas,
                           # métricas y logs a Application Insights

Qué medir en un sistema de agentes

Las métricas web clásicas (peticiones por segundo, errores 5xx) siguen aplicando, pero un sistema de agentes exige un tablero propio:

• Latencia por percentiles, no por promedio. El promedio miente: si 9 respuestas tardan 2 s y una tarda 40 s (un agente que entró en un bucle de herramientas), el promedio dice 5.8 s y parece tolerable. El p95 — el valor que el 95% de las peticiones no supera — expone la cola: p95 de 30 s significa que uno de cada veinte usuarios vive una experiencia inaceptable. Se monitorea p50 (la experiencia típica) y p95 (la experiencia en el borde).
• Tokens por conversación, separando prompt y completion. Un salto súbito en tokens de prompt suele delatar un bug de contexto (historial que no se poda, fragmentos RAG duplicados) — es la métrica de costo con capacidad de diagnóstico.
• Tasa de error por herramienta. Si buscar_sharepoint falla el 15% de las veces, el agente "alucina de rebote": responde sin la información que necesitaba. Las fallas de herramientas son la causa raíz silenciosa de muchas malas respuestas.
• Iteraciones del loop agéntico por petición. Un agente sano resuelve en 2-4 pasos; una distribución que se desplaza hacia 8-10 indica prompts de herramientas confusos (Módulo 6) o un modelo que da vueltas. Es la métrica de salud cognitiva del sistema.
• Calidad muestreada. La evaluación del Módulo 9 no termina en el despliegue: un job nocturno evalúa una muestra de las conversaciones reales del día (con LLM-as-judge sobre groundedness y relevancia) y publica el resultado como métrica. La calidad se convierte en una serie de tiempo con alertas, igual que la latencia.

Sobre esas métricas se definen alertas con presupuesto de atención realista: pocas y accionables. Tres que valen su ruido: p95 de latencia sobre umbral durante 15 minutos, tasa de error de herramientas sobre 5%, y gasto diario de tokens sobre el presupuesto (siguiente sección). Una alerta que dispara a diario y se ignora es peor que ninguna: entrena al equipo a no mirar.

7. Costos: la factura como métrica de ingeniería

En software tradicional el costo marginal de una petición es prácticamente cero. En sistemas de LLM cada petición cuesta dinero contante, y el costo escala con el uso, con la verbosidad de los prompts y con las decisiones de arquitectura. Tratarlo como métrica de ingeniería significa: modelarlo antes de desplegar, medirlo en producción y optimizarlo con los datos.

Modelar: el costo se calcula, no se descubre en la factura

El modelo de costo de una conversación promedio del asistente, con precios ilustrativos de un modelo de gama media (entrada $2.00 y salida $8.00 por millón de tokens):

  Conversación promedio (medida en el piloto, Módulo 9):
    system prompt + definiciones de tools     1,800 tokens  (entrada)
    historial + fragmentos RAG                2,700 tokens  (entrada)
    3 llamadas del loop agéntico              se re-envía el contexto 3 veces
    respuestas + tool calls generados           900 tokens  (salida)
 
  entrada:  (1,800 + 2,700) × 3 ≈ 13,500 tokens × $2.00/M  = $0.0270
  salida:                            900 tokens × $8.00/M  = $0.0072
                                                  ─────────────────
  costo por conversación                                   ≈ $0.034
 
  500 empleados × 4 conversaciones/día × 21 días  = 42,000 conversaciones/mes
  42,000 × $0.034                                 ≈ $1,430/mes  (solo tokens)

Dos lecciones saltan del cálculo. Primera: la entrada domina (79% del costo), y dentro de la entrada, el contexto fijo que viaja en cada iteración del loop — este es el "impuesto cuadrático" del Módulo 1 hecho factura. Segunda: el costo de tokens probablemente supera al de toda la infraestructura junta (ACA, Postgres y Redis de este sistema suman en torno a $150-300/mes) — optimiza primero donde está el dinero.

Las palancas, ordenadas por impacto

1. Caché (sección 4): la única palanca con costo marginal cero por respuesta. −20 a −40% en cargas con preguntas repetitivas.
2. Modelo por tarea: el supervisor del Módulo 8 clasificando intenciones no necesita el modelo insignia. Enrutar el 70% de tareas simples a un modelo económico (10-20 veces más barato por token) mientras las complejas van al grande recorta la factura a la mitad sin tocar la calidad — si la evaluación del Módulo 9 confirma que el modelo chico rinde en esas tareas. El Model Router del Módulo 2 automatiza esta decisión.
3. Dieta de contexto: podar historial (resumir turnos viejos en lugar de arrastrarlos), menos fragmentos RAG pero mejor rankeados (Módulo 7), definiciones de herramientas concisas (Módulo 6 — cada descripción viaja en cada llamada), max_tokens acotado.
4. Prompt caching del proveedor: Azure OpenAI descuenta los tokens de entrada que se repiten idénticos al inicio del prompt (el system prompt y las tools, justamente lo que nunca cambia). Requiere ordenar el prompt con lo estático primero — un cambio de estructura, no de contenido.
5. Batch API (Módulo 2) para todo lo que no es interactivo: la evaluación nocturna, la generación de reportes, el reindexado — a mitad de precio.

Gobernar: presupuestos y límites

• Azure Budgets con alertas al 80% y 100% del presupuesto mensual del resource group: la red de seguridad contra sorpresas.
• Cuotas de deployment (TPM, Módulo 2) como límite físico de gasto por minuto.
• Rate limiting por usuario (sección 4) como límite de equidad: ningún individuo consume el presupuesto de todos.
• Atribución: registrar tokens por usuario/departamento en cada traza permite responder "¿quién usa esto y cuánto cuesta?" — la pregunta que decide la renovación del proyecto.

8. Resiliencia: diseñar para el fallo

Azure OpenAI va a devolver errores 429 (throttling) en horas pico. La API del clima va a caer un martes. Una llamada al LLM va a colgarse 60 segundos. Nada de esto es hipotético: es el comportamiento normal de sistemas distribuidos, y la diferencia entre un asistente confiable y uno frustrante es cómo responde a ello.

  petición ──► timeout (30 s)  ──► retry con backoff exponencial + jitter
                                   (espera 1s, 2s, 4s... solo en errores
                                    transitorios: 429, 500, 503)
                                        │
                                        ▼  si sigue fallando
                                   fallback: deployment alterno en otra
                                   región, o modelo más pequeño
                                        │
                                        ▼  si todo falla
                                   degradación honesta: "No puedo consultar
                                   X ahora mismo" — nunca inventar

Los tres mecanismos, en corto:

• Timeouts en todo. Toda llamada de red (LLM, herramientas, DB) lleva timeout explícito. Sin él, una dependencia colgada acumula peticiones abiertas hasta tumbar la réplica.
• Retries con backoff exponencial y jitter, solo para errores transitorios. El jitter (aleatoriedad en la espera) evita que todas las réplicas reintenten al unísono y re-saturen el servicio. Los SDKs de OpenAI y Azure lo traen integrado; el trabajo es configurarlo consciente, no implementarlo.
• Fallbacks y degradación. Un segundo deployment en otra región cubre el throttling regional. Y cuando una herramienta falla definitivamente, el agente debe decirlo — el system prompt debe instruir explícitamente qué hacer ante resultados de error de las herramientas, porque la alternativa por defecto de un LLM es rellenar el hueco con plausibilidad (la alucinación del Módulo 1, versión productiva).

9. CI/CD: el despliegue con puerta de calidad

El pipeline de despliegue de un sistema de agentes tiene una etapa que el software tradicional no tiene — y es la síntesis de todo el curso:

  push a main
     │
     ▼
  tests unitarios          (las tools, los parsers — código determinista)
     │
     ▼
  EVALUACIÓN (Módulo 9)    corre el dataset de evaluación contra la
     │                     versión nueva; si groundedness o relevancia
     │                     caen bajo el umbral, el pipeline SE DETIENE
     ▼
  docker build + push a ACR
     │
     ▼
  deploy a ACA como revisión nueva con 10% del tráfico   (canary)
     │
     ▼
  monitoreo 24-48 h de métricas y calidad muestreada
     │
     ▼
  100% del tráfico  (o rollback a la revisión anterior con un comando)

La puerta de evaluación es el concepto clave: en software no determinista, "los tests pasan" no garantiza que un cambio de prompt no degradó la calidad en un caso que no imaginaste. El dataset de evaluación cumple el rol que los tests de regresión cumplen en el software clásico. Cambiar un prompt sin correr la evaluación es el equivalente exacto a mergear sin correr los tests: a veces sale bien, y ese es precisamente el problema.

En GitHub Actions, la puerta es un job ordinario que falla el workflow si las métricas no alcanzan el umbral; la autenticación del pipeline contra Azure usa OIDC federado (la versión CI/CD de Managed Identity: sin secretos guardados en GitHub).

10. Ejercicios

Ejercicio 1 — Contenerizar el agente (~45 min). Toma el asistente de RRHH del Módulo 3 (o su versión LangChain del Módulo 4), envuélvelo en FastAPI con los endpoints /chat (con streaming SSE) y /health, y escribe un Dockerfile multi-stage con usuario no root. Constrúyelo y córrelo local con docker run -p 8000:8000. Objetivo: comprobar que la imagen es autosuficiente — clona el repo en una carpeta limpia (o pásalo a otra máquina) y verifica que docker build + docker run es todo lo que hace falta.

Ejercicio 2 — Medir el impacto de la caché (~45 min). Añade Redis (local: docker run -p 6379:6379 redis) como caché exacta de respuestas, con el hash de (system prompt + pregunta) como clave y TTL de 1 hora. Lanza 50 preguntas donde 20 son repetidas y registra: tokens consumidos, latencia promedio y costo estimado, con y sin caché. Objetivo: producir la tabla comparativa — el hábito de demostrar el ahorro con números en lugar de suponerlo.

Ejercicio 3 — Desplegar a Azure Container Apps (~60 min). Publica la imagen del Ejercicio 1 en Azure Container Registry y despliégala en ACA con Managed Identity (sin API keys: rol Cognitive Services OpenAI User sobre tu recurso de Azure OpenAI), escalado 0-3 réplicas y Application Insights conectado. Objetivo: recorrer el flujo completo build → push → deploy y ver tus primeras trazas de producción; después, deja la app en reposo y observa el escalado a cero en acción.

11. Proyecto del módulo: el sistema multiagente, en producción

El proyecto lleva el sistema multiagente del Módulo 8 a un despliegue productivo completo — que se convierte, deliberadamente, en el esqueleto de infraestructura del proyecto final del curso.

                        ┌────────────────────────────────────────┐
   empleado ──HTTPS──►  │  ACA: employee-assistant (FastAPI)     │
                        │  Supervisor + agentes especialistas    │
                        │  Managed Identity (sin secretos)       │
                        └──────┬──────────┬──────────┬───────────┘
                               │          │          │
                     ┌─────────▼──┐  ┌────▼─────┐  ┌─▼──────────────┐
                     │ PostgreSQL │  │  Redis   │  │ Azure OpenAI   │
                     │ checkpoints│  │ caché +  │  │ 2 deployments: │
                     │ auditoría  │  │ rate lim │  │ grande + chico │
                     └────────────┘  └──────────┘  └────────────────┘
                               │
                     ┌─────────▼──────────────┐
                     │ Application Insights   │  trazas, métricas,
                     │ + Azure Budgets        │  alertas, costos
                     └────────────────────────┘

Entregables:

1. API productiva: el sistema del Módulo 8 detrás de FastAPI, contenerizado, desplegado en ACA con escalado 0-5 réplicas y Managed Identity para Azure OpenAI y PostgreSQL.
2. Estado durable: checkpointer de PostgreSQL para las conversaciones (verifica retomando un thread_id tras reiniciar la revisión) y tabla de auditoría de ejecuciones de herramientas.
3. Caché y límites: Redis con caché exacta de respuestas y rate limiting de 30 mensajes/minuto por usuario.
4. Observabilidad: trazas OpenTelemetry en Application Insights; tablero con p50/p95 de latencia, tokens por conversación, tasa de error por herramienta y costo diario estimado; tres alertas configuradas.
5. Resiliencia demostrada: timeouts y retries configurados; una prueba documentada donde apagas una dependencia (por ejemplo, la herramienta de clima) y el asistente responde degradándose honestamente.
6. Pipeline con puerta: GitHub Actions que corre tests, ejecuta el dataset de evaluación del Módulo 9 y solo despliega revisión canary si supera el umbral; documento breve del proceso de rollback.
7. Informe de costos: el modelo de costo proyectado (con el método de la sección 7), el costo real medido de la primera semana y las dos palancas que aplicarías primero.

Criterio de éxito: otra persona puede clonar el repositorio, ejecutar el pipeline y obtener el sistema corriendo en su propia suscripción — porque nada depende de tu máquina, de tus claves ni de tu memoria.

12. Resumen y cierre del curso

Producción no es un paso final: es una disciplina transversal que este módulo condensó en un mapa. FastAPI y Docker convierten el agente en una unidad desplegable inmutable; Azure Container Apps la ejecuta con escalado a cero y revisiones canary, con Functions para tareas por evento y AKS reservado para necesidades que un sistema de agentes rara vez tiene. El estado sale del proceso: PostgreSQL guarda lo que no se puede perder (checkpoints, auditoría) y Redis acelera lo que no se quiere repetir (caché, rate limiting). La seguridad se implementa en la capa determinista — Managed Identity, Key Vault, permisos delegados de mínimo privilegio — porque la capa probabilística siempre podrá ser manipulada. La observabilidad conecta la instrumentación del Módulo 9 a Application Insights y vigila las métricas propias de agentes: percentiles de latencia, tokens, errores de herramientas, iteraciones del loop y calidad muestreada. El costo se modela con aritmética de tokens, se gobierna con presupuestos y límites, y se optimiza con caché y enrutamiento de modelos validado por evaluación. Y el pipeline de despliegue incorpora la puerta que define a la ingeniería de sistemas no deterministas: ninguna versión llega a los usuarios sin pasar por el dataset de evaluación.

Con esto, los diez módulos forman el arco completo: entender el modelo (1), operarlo en Azure (2), orquestarlo (3, 4), conectarlo al mundo (5, 6), alimentarlo con conocimiento (7), coordinarlo en equipo (8), medirlo (9) y sostenerlo en producción (10). Queda el proyecto final — el Employee AI Assistant — donde todas las piezas se ensamblan en un solo sistema.