Si alguien te pregunta cuál es el freno principal para llevar agentes de IA a producción en empresas, la respuesta que más se repite no es el modelo ni el costo: es la infraestructura. Dónde corre el agente, cómo se conecta con los sistemas internos, quién controla los logs y quién responde cuando falla en producción a las 2 de la madrugada. Microsoft atacó ese problema esta semana: el runtime de agentes de Microsoft Foundry —antes conocido como Azure AI Foundry— llegó a disponibilidad general en julio 2026, con soporte nativo para LangGraph, CrewAI y otros frameworks sin necesidad de reescribir la lógica del agente.
Qué es el runtime de agentes de Microsoft Foundry
Cuando trabajas con APIs de OpenAI, Anthropic o cualquier LLM, eres tú quien decide dónde corre el agente: ¿en un servidor propio? ¿en Azure Container Apps? ¿en una función serverless? Esa decisión lleva semanas de setup, configuración de red, políticas de seguridad y troubleshooting. El runtime de Microsoft Foundry es la respuesta de Microsoft a ese problema: un entorno administrado donde cada sesión de agente corre en su propio sandbox, con compute dedicado, acceso a filesystem durable y aislamiento de red. Tú te encargas de la lógica del agente; Foundry se encarga de dónde y cómo corre.
Lo que cambia en julio 2026 es que ese runtime está en GA —general availability— y dejó de ser un preview experimental con las limitaciones que eso implica. Más importante todavía: es framework-agnostic. Si tienes un agente construido con LangGraph 1.0 o con CrewAI, puedes desplegarlo en Foundry sin tocar la lógica del agente. El SDK de Foundry actúa como capa de hosting. Para equipos en LATAM que ya invirtieron tiempo en aprender LangGraph o CrewAI, esto elimina el argumento de "no podemos pasar a producción sin cambiar todo el stack".
Lo que incluye la release de julio 2026
Los puntos que importan de la release, sin el marketing:
- ▸Runtime de agentes en GA: cada sesión corre en su propio sandbox con compute y memoria dedicada, filesystem durable para persistir archivos entre llamadas, y aislamiento de red por defecto
- ▸Framework-agnostic: LangGraph, CrewAI, Microsoft Agent Framework y GitHub Copilot SDK corren en el runtime sin rewrites del código del agente
- ▸Claude Sonnet 5 en GA dentro de Foundry: disponible como modelo hosted corriendo sobre infraestructura NVIDIA Blackwell Ultra de Azure, con el mismo contexto de 1M tokens que en la API directa
- ▸Fireworks AI para open models: Llama 4, Mistral Large 2 y otros modelos open-source disponibles vía un solo endpoint Azure con enterprise SLAs y sin contratos separados
- ▸Foundry Toolkit para VS Code en GA: extensión para desarrollar, testear y debuggear agentes sin salir del editor
Qué significa esto para un AI Engineer en LATAM
La pregunta que me hacen los devs cuando presentan un proyecto de agentes a un cliente corporativo es siempre la misma: '¿dónde va a correr esto y quién lo controla?' Con el runtime de Foundry, la respuesta es clara: en Azure, dentro del tenant de la empresa, con los controles de acceso de Azure Active Directory y los logs en Azure Monitor. No es la respuesta perfecta para todos los casos —hay escenarios donde conviene más un deploy propio— pero es una respuesta que el equipo de seguridad puede aprobar en días, no en semanas. En la práctica, eso acelera mucho el paso de prototipo a producción.
Para empresas que ya tienen Azure como plataforma de datos —que son muchas en LATAM, especialmente en banca, retail y manufactura— integrar el runtime de agentes en el mismo entorno de Azure Synapse, Azure Data Lake y Azure Databricks que ya usan es mucho más fácil de vender internamente que proponer una nueva plataforma. El argumento ya no es técnico: es "esto vive dentro de lo que ya aprobamos como empresa".
Lo que nadie te dice: el runtime de Foundry tiene un costo que escala rápido. Cada sesión de agente usa compute dedicado, y eso está bien para agentes de larga duración o con estado complejo, pero puede ser caro para workloads de alta frecuencia con tareas simples. Antes de comprometer todo el stack con Foundry para producción, haz el análisis de costo comparado con un deploy en Azure Container Apps. No siempre el runtime administrado es la opción más económica.
Foundry vs armar tu propio deploy en Azure
Foundry conviene cuando necesitas agentes con estado complejo, sesiones largas, acceso a filesystem, y un equipo de IT que ya trabaja sobre Azure y no quiere administrar contenedores de agentes por separado. También conviene cuando necesitas aislamiento de seguridad fuerte por sesión o cuando el modelo de pricing de Foundry (compute por sesión) se acomoda mejor a tu caso de uso que pagar por tokens en cada llamada.
No conviene cuando tienes workloads de alta frecuencia con tareas simples y rápidas (ahí Azure Container Apps o Azure Functions son más económicos), cuando necesitas control total sobre la red y los egress policies, o cuando tu agente no tiene estado complejo y puede correr perfectamente como una función serverless. El patrón que más veo funcionar en empresas LATAM es usar Foundry para los agentes de alto valor (los que automatizan procesos complejos o tienen acceso a datos sensibles) y deploys propios para los agentes de alta frecuencia. Los dos modelos coexisten.
Cómo prepararte para construir agentes en producción sobre Foundry
El prerequisito para aprovechar el runtime de Foundry no es entender Azure primero: es saber construir buenos agentes. Si tu agente tiene estados mal definidos, contexto desordenado o herramientas que fallan silenciosamente, moverlo a un runtime administrado solo va a exponer esos problemas más rápido. Empieza por dominar LangGraph o CrewAI —la estructura del agente— antes de preocuparte por el hosting.
En DataPath cubrimos exactamente ese path: el curso de Creación de Agentes con LangGraph te da la base de cómo construir agentes con estado real, y el curso de Sistemas Multi-Agentes con CrewAI cubre el diseño de sistemas con múltiples agentes coordinados. Para el contexto enterprise completo —incluyendo Azure como plataforma— está la ruta de AI Agentic Engineer, que conecta la construcción de agentes con los patrones de producción que están usando empresas reales.
El runtime de Foundry en GA no es el fin del camino: es el punto de llegada de lo que construyes con LangGraph o CrewAI. Si todavía estás en la fase de "entendiendo cómo funcionan los agentes", este anuncio te da más razones para aprenderlo bien ahora. La demanda de AI Agentic Engineers que saben llevar agentes a producción en entornos enterprise va a seguir subiendo en lo que queda de 2026.
