Stacks que podemos operar
Los stacks que usamos para enviar IA a producción, y las decisiones que nos hacen elegir uno sobre otro.
Cómo elegimos
State of the art es una decisión operativa, no una lista de logos.
La pregunta no es qué nube o framework está de moda. La pregunta es dónde el sistema puede ser evaluado, desplegado, observado, auditado y transferido al equipo que lo va a operar.
Orquestación de agentes
LangGraph cuando el workflow necesita estado, replay, retries, checkpoints humanos y rutas explícitas de escalación.
Enterprise y documentos
Azure cuando identidad Microsoft, Office, tenant boundaries, procurement y cumplimiento son parte del camino crítico.
Runtime gobernado
Google Cloud cuando GKE, sandboxes, NetworkPolicy, entornos por PR o runtimes de agentes deciden el producto.
Control operativo
AWS cuando el cliente ya opera IAM, VPCs, colas, logs, seguridad y cuentas auditadas como sistema nervioso de producción.
El estándar que no cambia por stack
- El stack no se decide por preferencia de vendor. Se decide por eval, seguridad, operación, costo y el equipo que recibirá el handover.
- Cada stack necesita el mismo kit: permisos, trazas, model routing, presupuesto de costo, runbook y rollback.
- No abstraemos multi-cloud por estética. Abstraemos solo cuando reduce riesgo real o protege portabilidad que el negocio necesita.
Stack notes
Dónde encaja cada stack
AWS
Google Cloud
LangGraph
Microsoft Azure
¿El stack ya está decidido?
Perfecto. En la primera llamada revisamos si el stack elegido puede sostener evals, tool use, observabilidad, costos, seguridad y handover sin inventar una plataforma paralela.