Durante meses, la única forma de construir agentes en Azure fue la Assistants API de Azure OpenAI. Funcionaba, pero tenía sus límites: solo modelos de OpenAI, sin multi-agente nativo, sin integración directa con el ecosistema de datos de Microsoft, y con una arquitectura que Microsoft fue dejando atrás poco a poco.
Hoy en día, eso cambió. Azure AI Foundry Agent Service alcanzó disponibilidad general en marzo de 2026 y se convirtió en la plataforma oficial para construir, desplegar y escalar agentes de IA en Azure. La Assistants API clásica sigue funcionando por ahora, pero tiene fecha de retiro: el 31 de marzo de 2027. Si estás empezando un proyecto nuevo, o pensando en migrar uno existente, el destino es Foundry Agent Service.
Este artículo explica qué es, cómo se organiza, qué podés construir con él y qué decisiones técnicas importan al momento de diseñar un agente para producción.
Qué es un agente y qué no es
Antes de entrar en el servicio, vale la pena ser preciso con el término porque se usa de formas muy distintas dependiendo del contexto.
Un agente en el ecosistema de Microsoft Foundry es una aplicación de IA que usa un modelo del catálogo de Foundry para razonar sobre solicitudes del usuario y tomar acciones autónomas para resolverlas. A diferencia de un chatbot que solo genera texto, un agente puede llamar herramientas, acceder a datos externos y tomar decisiones a través de múltiples pasos para completar una tarea. En algunos casos, los agentes ni siquiera tienen una interfaz de chat: trabajan en segundo plano, activados por eventos del sistema, completando tareas de forma autónoma.
Los tres componentes básicos de cualquier agente son el modelo, que provee razonamiento y capacidad de lenguaje; las instrucciones, que definen objetivos, restricciones y comportamiento; y las herramientas, que le dan acceso a datos o acciones concretas como búsqueda, operaciones con archivos o llamadas a APIs.
Los dos tipos de agentes en Foundry
Foundry Agent Service organiza los agentes en dos categorías principales, y la elección entre ellas determina cuánto código escribís y cuánto control tenés.
Prompt agents
Los prompt agents son agentes que vos definís con instrucciones, herramientas y configuración, y Foundry los ejecuta sin que tengas que escribir ni mantener código de aplicación. No hay compute que pagar, ni contenedores que optimizar, ni infraestructura que escalar. Definís el agente desde el portal de Foundry o mediante SDK, y el servicio se encarga del resto.
Son la opción correcta cuando el caso de uso está bien definido, las herramientas disponibles en Foundry cubren lo que necesitás, y no requirís lógica de orquestación compleja escrita a mano. Para la mayoría de los casos de automatización empresarial, atención al cliente o análisis de datos, los prompt agents son suficientes y mucho más rápidos de implementar.
Hosted agents
Los hosted agents te permiten traer tu propio código de agente, empaquetado como contenedor, y dejar que Foundry lo ejecute con un endpoint administrado, escalado automático, identidad y observabilidad incorporados. Podés escribir ese código con Agent Framework, LangGraph, el OpenAI Agents SDK, el Anthropic Agent SDK, el GitHub Copilot SDK, o cualquier framework que elijas.
Este tipo es el camino cuando necesitás lógica de orquestación que no se puede expresar solo con instrucciones, integraciones muy específicas con sistemas propios, o control total sobre el comportamiento del agente en cada paso. Los hosted agents están en disponibilidad general a partir de principios de julio de 2026.
La base técnica: Responses API
Foundry Agent Service está construido sobre la Responses API de OpenAI. Esto tiene una implicación práctica importante: si ya tenés código que corre contra la Responses API directamente, migrarlo a Foundry requiere cambios mínimos. Lo que ganás al hacerlo es seguridad empresarial, networking privado, control de acceso con Entra ID, trazabilidad completa y evaluación, sobre tu lógica de agente existente.
Los SDKs están disponibles para Python, JavaScript, TypeScript, Java y .NET. La versión estable es la 2.0.0, publicada en marzo de 2026. A partir de esa versión, el paquete incluye openai y azure-identity como dependencias directas, así que no necesitás instalarlos por separado.
import os
from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition
credential = DefaultAzureCredential()
client = AIProjectClient(
endpoint=os.environ["AZURE_AI_FOUNDRY_ENDPOINT"],
credential=credential
)
agent = client.agents.create_agent(
model="gpt-4o",
name="agente-soporte",
instructions="Sos un asistente de soporte técnico. Respondé preguntas usando la base de conocimiento disponible.",
)
thread = client.agents.threads.create()
client.agents.messages.create(
thread_id=thread.id,
role="user",
content="¿Cómo reinicio el servicio de autenticación?"
)
run = client.agents.runs.create_and_process(
thread_id=thread.id,
agent_id=agent.id
)
messages = client.agents.messages.list(thread_id=thread.id)
for msg in messages:
if msg.role == "assistant":
print(msg.content[0].text.value)
Herramientas disponibles
La utilidad real de un agente depende de qué herramientas puede invocar. Foundry Agent Service tiene un conjunto amplio de herramientas integradas y soporte para herramientas externas vía MCP.
Herramientas integradas
File Search permite al agente buscar en archivos subidos al servicio, útil para bases de conocimiento internas.
Code Interpreter ejecuta código Python en un entorno sandbox aislado, ideal para análisis de datos y generación de gráficos.
Bing Search permite al agente buscar en la web para responder preguntas que requieren información actualizada.
SharePoint es ahora una herramienta de conocimiento de primera clase, integrada directamente en el servicio. Los agentes pueden acceder a documentos de SharePoint sin construir una pipeline RAG personalizada.
Microsoft Fabric a través de Fabric IQ permite a los agentes consultar datos estructurados de la plataforma de datos de Microsoft, incluyendo modelos semánticos y ontologías.
Logic Apps abre acceso a más de 1,400 flujos de trabajo de Azure Logic Apps como herramientas para los agentes, lo que cubre un rango enorme de integraciones con sistemas externos.
Deep Research ejecuta un proceso de investigación de múltiples pasos usando el modelo o3-deep-research de Azure OpenAI con Bing Search como fuente de conocimiento.
Computer Use y Browser Automation están en preview. El primero permite al agente interactuar con interfaces de usuario de aplicaciones de escritorio. El segundo permite ejecutar tareas reales en el navegador mediante lenguaje natural, usando sesiones aisladas de Microsoft Playwright.
MCP y Toolboxes
Model Context Protocol es el estándar abierto que Foundry adoptó como mecanismo principal para conectar agentes con herramientas externas. Podés agregar servidores MCP remotos directamente desde el catálogo del portal, incluyendo el Azure DevOps MCP Server en preview público. También podés exponer herramientas propias hosteadas en Azure Functions mediante el endpoint de webhook MCP.
Toolboxes, disponible en preview público desde Build 2026, permite definir un conjunto curado de herramientas una sola vez, gestionarlas centralmente en Foundry, y exponerlas a través de un único endpoint compatible con MCP. Cualquier agente o cliente MCP puede consumir un Toolbox, independientemente del framework que use. El Toolbox incluye versionado explícito para controlar cuándo los cambios entran en efecto en producción.
Multi-agente: Connected Agents
Cuando una tarea es demasiado compleja para un solo agente, Foundry Agent Service soporta workflows multi-agente a través de Connected Agents, disponible en preview.
Los Connected Agents permiten interacciones punto a punto, donde un agente puede llamar a otros agentes como herramientas para delegar tareas especializadas. El agente principal coordina y el agente secundario ejecuta la subtarea sin necesitar un orquestador externo.
Para workflows más complejos, Foundry integra con el runtime convergente de Semantic Kernel y AutoGen, que combina los patrones de orquestación dinámica de AutoGen con la arquitectura modular de Semantic Kernel. El resultado es una API unificada para definir, encadenar y gestionar workflows tanto de un solo agente como multi-agente, con comportamiento consistente entre el entorno local y el cloud.
Seguridad para entornos empresariales
Un agente que accede a datos internos, ejecuta acciones en sistemas de producción y toma decisiones autónomas necesita controles de seguridad muy distintos a los de un chatbot público.
Entra Agent ID le da a cada agente una identidad de Microsoft Entra propia. Esto significa que los agentes se autentican como entidades con permisos propios, no como el usuario que los invoca, lo que permite aplicar el principio de mínimo privilegio a nivel de agente.
Networking privado es soporte a nivel GA. Podés traer tu propia red virtual (BYO VNet) para un entorno completamente aislado, sin egreso público, con inyección de contenedores y subredes en tu red. El networking privado se extiende a la conectividad de herramientas, incluyendo servidores MCP, Azure AI Search y Fabric data agents.
Content safety integrado incluye guardarraíles para reducir outputs inseguros y mitigar riesgos de prompt injection, incluyendo Cross-Prompt Injection Attacks (XPIA).
Observabilidad en producción
Operar un agente en producción sin visibilidad de qué está haciendo es inviable. Foundry Agent Service tiene observabilidad integrada que alcanzó disponibilidad general en marzo de 2026.
El tracing captura el camino completo de ejecución de extremo a extremo: requests, invocaciones de herramientas y responses, con semántica OpenTelemetry para workloads de IA que incluyen memoria, estado y planificación. Los resultados de evaluación se vinculan directamente al trace que los produjo, así que cuando aparece una regresión podés ir del score al trace exacto de producción que lo causó.
Los evaluadores integrados cubren coherencia, relevancia, fundamentación, calidad de recuperación y seguridad, tanto para generación directa como para escenarios RAG. Los evaluadores personalizados, en preview, permiten definir lógica de evaluación basada en LLM-as-a-judge alineada a requisitos de negocio específicos.
Distribución: dónde viven los agentes
Un agente sin un canal de distribución no llega a ningún usuario. Foundry soporta múltiples formas de publicar agentes.
La más directa es un REST endpoint que cualquier aplicación puede consumir. Para entornos Microsoft, los agentes se pueden publicar directamente en Microsoft Teams y Microsoft 365 Copilot, con identidad, permisos y políticas que fluyen automáticamente a través de los canales de la plataforma. Esta funcionalidad estaba planificada para disponibilidad general en junio de 2026.
El Entra Agent Registry centraliza el registro y descubrimiento de agentes en la organización, para que los equipos puedan encontrar y reutilizar agentes existentes en lugar de reconstruirlos.
El protocolo A2A (agent-to-agent), en preview, habilita comunicación entre agentes de distintos sistemas.
Lo que no debes usar hoy
Si venís de Azure OpenAI y usás la Assistants API clásica (la que existía antes de Foundry), sabé que está deprecada y se retira el 31 de marzo de 2027. El servicio clásico se documenta ahora bajo /azure/foundry-classic/agents/ en Microsoft Learn. El nuevo servicio vive en /azure/foundry/agents/.
La migración desde la Assistants API clásica al nuevo Agent Service no es trivial pero tampoco es compleja: la guía oficial de migración está disponible en Microsoft Learn.
¿Por dónde empiezo?
El Foundry Toolkit para VS Code alcanzó disponibilidad general en Build 2026. Te permite crear agentes desde plantillas o usando GitHub Copilot directamente en el IDE, depurar runs localmente con visualización de traces, conectar Toolboxes, y desplegar a Foundry Agent Service sin salir de VS Code.
Si querés experimentar y no instalar nada, el portal de Azure AI Foundry en ai.azure.com permite crear, configurar, depurar y probar agentes en modo no-code, ver threads de conversación, agregar herramientas e interactuar con el agente directamente desde la interfaz.
Si querés explorar la documentación oficial y los quickstarts:
👉 https://learn.microsoft.com/azure/ai-foundry/agents/?wt.mc_id=studentamb_510930
Construir agentes en Azure ya no requiere armar infraestructura desde cero ni depender de APIs que van a desaparecer. Foundry Agent Service cubre el runtime, la identidad, el networking, las herramientas, la memoria y la observabilidad como partes del servicio. Lo que queda del lado del developer es decidir qué hace el agente, con qué herramientas, y cómo distribuirlo. Que es, en realidad, la parte interesante.