Bienvenido al Curso de Deploy de Agentes. La meta es clara: tomar ese agente que funciona en tu notebook — un script que llama a un LLM, usa un par de tools y responde bonito en tu terminal — y convertirlo en un producto en producción, siguiendo el flujo real de una empresa. No el flujo de tutorial, el de verdad: Git y convenciones de equipo, testing, CI/CD (integración y entrega continuas), evaluación de brechas, contenedores, Terraform/IaC (infraestructura como código), deploy en la nube, observabilidad y rollout controlado. Si todavía no tienes claro qué es un agente por dentro, pasa antes por Cómo funciona un agente; y si ya llevaste un grafo de LangGraph al borde de producción, este curso retoma justo donde quedó LangGraph a producción. Este primer módulo pone el mapa sobre la mesa: qué cambia cuando tu agente deja de ser tuyo y pasa a ser de la empresa.

La tesis del módulo

Un prototipo demuestra que algo puede funcionar; un producto garantiza que sigue funcionando aunque el mundo se porte mal. El salto no es más código: es fiabilidad, costo, seguridad y observabilidad, sostenidos por un pipeline que cualquiera del equipo puede correr.

El demo vive en el “camino feliz”

Cuando armas un agente en tu máquina, sin darte cuenta lo pruebas siempre igual: inputs razonables, buena conexión, la API key en una variable, tú mirando la terminal. Eso es el camino feliz (happy path): el escenario donde todo sale bien. Y en el camino feliz, tu agente es impecable.

Producción es el resto del mundo. Ahí tu agente enfrenta cosas que en tu notebook nunca pasan:

El LLM falla o alucina. Devuelve un JSON roto, inventa un dato, ignora la instrucción. En tu demo lo reintentas a mano; en producción son mil usuarios a la vez.
Timeouts. La API del modelo tarda 40 segundos o no responde. ¿Tu agente espera para siempre? ¿Reintenta? ¿Cuántas veces?
Costos que se disparan. Un loop mal cerrado que llama al modelo en bucle puede quemar cientos de dólares en una noche mientras duermes.
Inputs maliciosos. Alguien intenta un prompt injection (texto diseñado para secuestrar las instrucciones de tu agente) o te manda basura para romperlo.
La necesidad de saber qué pasó. Un usuario reclama que “el agente respondió cualquier cosa”. Sin registros, no tienes cómo saber qué entró, qué pensó el modelo ni qué salió.

Ninguno de estos problemas se arregla escribiendo un prompt más ingenioso. Se arreglan con ingeniería alrededor del agente: reintentos, límites, validación, registros. Eso es producción.

Los cuatro ejes de un agente en producción

Todo lo que veremos en el curso se ordena en cuatro ejes. Tenlos siempre presentes; son el criterio con el que se juzga si un agente está listo.

Eje	La pregunta que responde	Cómo se ataca en el curso
Fiabilidad	¿Sigue funcionando cuando algo falla?	Tests, evals, reintentos, rollout gradual
Costo	¿Cuánto cuesta cada respuesta y cómo lo controlo?	Límites, caché, elección de modelo, monitoreo de gasto
Seguridad	¿Puede alguien romperlo, filtrar datos o abusarlo?	Secretos fuera del código, validación de inputs, permisos
Observabilidad	¿Sé qué pasó cuando pasó?	Logs, trazas, métricas, alertas

Fiabilidad es que el agente responda bien no una vez, sino siempre, incluso cuando el LLM o la red fallan.
Costo importa porque cada token se paga: un agente sin control de gasto es una fuga con forma de app.
Seguridad cubre desde no filtrar tu API key hasta que un usuario no pueda hacer que el agente haga algo que no debe.
Observabilidad es poder responder “¿qué pasó?” con datos, no con suposiciones. Sin esto, depurar producción es adivinar a ciegas.

Ojo: estos cuatro ejes no se agregan al final, “cuando haya tiempo”. Se construyen desde la primera línea de infraestructura. Un agente al que le atornillas la observabilidad después ya perdió los datos de todo lo que falló antes.

El pipeline completo del curso

Este es el recorrido de una línea de código, desde tu editor hasta un usuario real. Es el mapa de todo el curso: cada etapa es uno o varios módulos.

 CÓDIGO
   │  escribes y commiteas
   ▼
 ┌──────────────────────────────┐
 │ Git + Pull Request           │  módulos 2-4
 └──────────────┬───────────────┘
                ▼
 ┌──────────────────────────────┐
 │ CI: tests + evals + checks   │  módulos 6-9
 └──────────────┬───────────────┘
                ▼
 ┌──────────────────────────────┐
 │ Build de imagen (Docker)     │  módulo 5
 └──────────────┬───────────────┘
                ▼
 ┌──────────────────────────────┐
 │ IaC + Deploy (Terraform)     │  módulos 10-12
 └──────────────┬───────────────┘
                ▼
 ┌──────────────────────────────┐
 │ Observabilidad + Seguridad   │  módulo 13
 └──────────────┬───────────────┘
                ▼
 ┌──────────────────────────────┐
 │ Rollout + Confiabilidad      │  módulo 14
 └──────────────┬───────────────┘
                ▼
              USUARIO

Fíjate en el orden: primero el código entra por Git, con convenciones que todo el equipo respeta. Ahí lo revisa una persona en un Pull Request (propuesta de cambio que se revisa antes de fusionar). Recién cuando pasa, entra a CI — un servidor que corre tus tests, tus evals y otros chequeos automáticos. Si CI aprueba, se construye una imagen de contenedor (un paquete con tu app y todo lo que necesita para correr igual en cualquier parte). Esa imagen se despliega con infraestructura como código, se observa en producción y se libera de a poco con rollout controlado. Ninguna etapa se salta.

Prototipo vs producción

La tabla que resume el salto completo. Guárdala: cada fila es un problema que el curso resuelve.

Dimensión	Prototipo (tu notebook)	Producción (la empresa)
Dónde corre	Tu máquina, tu Python	Contenedor en la nube
Config y secretos	Hardcodeados o en un `.env` suelto	Variables de entorno + secret manager
Cuando el LLM falla	Lo reintentas a mano	Reintentos y fallbacks automáticos
Costo	No lo miras	Monitoreado, con límites y alertas
Cambios	Editas y guardas	PR, review, CI, deploy
Pruebas	”Funcionó cuando lo probé”	Tests y evals que corren solos
Cuando algo falla	Miras la terminal	Logs, trazas y métricas centralizadas
Quién lo mantiene	Tú, que sabes dónde tocar	El equipo, con historia legible en Git

La columna de la izquierda no está mal — es un excelente comienzo. El curso completo es el viaje de la izquierda a la derecha.

Errores comunes

Creer que “funciona en mi máquina” es estar listo. Es el punto de partida, no la meta. Producción es todo lo que tu máquina te ocultaba.
Dejar la observabilidad para el final. Cuando la necesitas (un incidente), ya es tarde: los datos del fallo no existen porque no los registraste.
Ignorar el costo hasta que llega la factura. Un agente sin límites de gasto es el error más caro y silencioso de la lista.
Pensar que producción es “el mismo código pero en un servidor”. El código es una fracción; el resto es el pipeline, los tests, los secretos y la infraestructura alrededor.
Saltarse Git y las convenciones “porque trabajo solo”. El día que entra otra persona — o vuelves tú en seis meses — la historia legible es la diferencia entre avanzar y arqueología.

La frase para llevarse

“El prototipo prueba que la idea funciona; producción es toda la ingeniería que hace que siga funcionando cuando tú no estás mirando.”

Qué viene

Módulo 2: Git esencial. Los comandos del día a día que sostienen todo el pipeline — init, commit, push, branch, merge — y cómo deshacer con seguridad sin borrar el trabajo de nadie. Antes de hablar de equipo, tienes que dominar la herramienta.

Deploy de Agentes — Módulo 1: qué cambia en producción