Microsoft-Foundry | The .NET Blog

Foundry Toolboxes: Un único endpoint para todas las herramientas de tus agentes

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

Esta publicación fue traducida automáticamente. Para la versión original, haz clic aquí.

Aquí hay un problema que parece aburrido hasta que lo sufres en carne propia: tu organización está construyendo múltiples agentes de IA, cada uno necesita herramientas, y cada equipo las conecta desde cero. La misma integración de búsqueda web, la misma config de Azure AI Search, la misma conexión al servidor MCP de GitHub — pero en otro repositorio, por otro equipo, con otras credenciales y sin ninguna gobernanza compartida.

Microsoft Foundry acaba de lanzar Toolboxes en preview pública, y es una respuesta directa a ese problema.

¿Qué es un Toolbox?

Un Toolbox es un bundle de herramientas con nombre, reutilizable, que defines una vez en Foundry y expones a través de un único endpoint compatible con MCP. Cualquier runtime de agente que hable MCP puede consumirlo — no estás bloqueado en Foundry Agents.

La propuesta es simple: build once, consume anywhere. Define las herramientas, configura la autenticación de forma centralizada (OAuth passthrough, identidad administrada de Entra), publica el endpoint. Cada agente que necesite esas herramientas se conecta al endpoint y las obtiene todas.

Sin configuración por herramienta. Sin gestión de credenciales por agente.

Los cuatro pilares (dos disponibles hoy)

Pilar	Estado	Qué hace
Discover	Próximamente	Encuentra herramientas aprobadas sin buscar manualmente
Build	Disponible hoy	Agrupa herramientas en un bundle reutilizable
Consume	Disponible hoy	Un único endpoint MCP expone todas las herramientas
Govern	Próximamente	Auth centralizada + observabilidad en todas las llamadas

Hoy el foco está en Build y Consume. Suficiente para eliminar la fricción más inmediata.

Empezando en la práctica

El SDK es Python primero por ahora. Comienzas creando un AIProjectClient y luego construyes un toolbox:

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

Luego creas una versión del toolbox con las herramientas que quieres agrupar:

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="Buscar en documentación y responder a issues de GitHub.",
 tools=[
 {"type": "web_search", "description": "Buscar documentación pública"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

Una vez publicado, Foundry te da un endpoint unificado que cualquier runtime MCP puede consumir. Un punto de conexión, todas las herramientas.

No estás bloqueado en Foundry Agents

Los Toolboxes se crean y gestionan en Foundry, pero la superficie de consumo es el protocolo MCP abierto. Puedes usarlos desde agentes personalizados con Microsoft Agent Framework o LangGraph, GitHub Copilot y otros IDEs compatibles con MCP, o cualquier runtime que hable MCP.

Por qué importa ahora

La ola de multi-agentes está llegando a producción. Los equipos están construyendo 5, 10, 20 agentes — y el problema de la configuración de herramientas escala rápido. Cada nuevo agente es una nueva superficie para configuración duplicada, credenciales desactualizadas y comportamiento inconsistente.

Los Toolboxes no resuelven la gobernanza y el discovery todavía (esos pilares están por venir), pero la base de Build + Consume es suficiente para empezar a centralizar. Cuando llegue el pilar Govern, tendrás una capa de herramientas observable y controlada centralmente para toda tu flota de agentes.

Conclusión

Esto es pronto — preview pública, SDK Python primero, con Discover y Govern todavía por llegar. Pero el modelo es sólido, y el diseño nativo de MCP significa que funciona con las herramientas que ya estás construyendo. Echa un vistazo al anuncio oficial para empezar.

¿Dónde deberías alojar tus agentes de IA en Azure? Una guía práctica de decisión

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

Este post fue traducido automáticamente. Para la versión original, haz clic aquí.

Si estás construyendo agentes de IA con .NET ahora mismo, probablemente hayas notado algo: hay muchas formas de alojarlos en Azure. Container Apps, AKS, Functions, App Service, Foundry Agents, Foundry Hosted Agents — y todos suenan razonables hasta que realmente necesitas elegir uno. Microsoft acaba de publicar una guía completa sobre alojamiento de agentes IA en Azure que aclara esto, y quiero desglosarlo desde la perspectiva práctica de un desarrollador .NET.

Las seis opciones de un vistazo

Así es como yo resumiría el panorama:

Opción	Ideal para	Tú gestionas
Container Apps	Control total de contenedores sin complejidad K8s	Observabilidad, estado, ciclo de vida
AKS	Cumplimiento empresarial, multi-clúster, redes personalizadas	Todo (ese es el punto)
Azure Functions	Tareas de agentes cortas y dirigidas por eventos	Casi nada — serverless puro
App Service	Agentes HTTP simples, tráfico predecible	Despliegue, configuración de escalado
Foundry Agents	Agentes sin código vía portal/SDK	Casi nada
Foundry Hosted Agents	Agentes con framework personalizado e infra gestionada	Solo tu código de agente

Las primeras cuatro son computación de propósito general — puedes ejecutar agentes en ellas, pero no fueron diseñadas para eso. Las dos últimas son nativas de agentes: entienden conversaciones, llamadas a herramientas y ciclos de vida de agentes como conceptos de primera clase.

Foundry Hosted Agents — el punto ideal para desarrolladores .NET de agentes

Esto es lo que me llamó la atención. Foundry Hosted Agents se sitúan justo en el medio: obtienes la flexibilidad de ejecutar tu propio código (Semantic Kernel, Agent Framework, LangGraph — lo que sea) pero la plataforma gestiona infraestructura, observabilidad y gestión de conversaciones.

La pieza clave es el Hosting Adapter — una capa de abstracción fina que conecta tu framework de agentes con la plataforma Foundry. Para Microsoft Agent Framework, se ve así:

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

Esa es toda tu historia de hosting. El adapter gestiona traducción de protocolos, streaming vía server-sent events, historial de conversación y trazado OpenTelemetry — todo automáticamente. Sin middleware personalizado, sin plomería manual.

Desplegar es genuinamente simple

He desplegado agentes en Container Apps antes y funciona, pero terminas escribiendo mucho código de pegamento para gestión de estado y observabilidad. Con Hosted Agents y azd, el despliegue es:

# Instalar la extensión de agente IA
azd ext install azure.ai.agents

# Inicializar desde una plantilla
azd ai agent init

# Construir, subir, desplegar — listo
azd up

Ese único azd up construye tu contenedor, lo sube a ACR, provisiona el proyecto Foundry, despliega endpoints de modelo e inicia tu agente. Cinco pasos colapsados en un solo comando.

Gestión de conversaciones integrada

Esta es la parte que ahorra más tiempo en producción. En lugar de construir tu propio almacén de estado de conversación, Hosted Agents lo gestionan nativamente:

# Crear una conversación persistente
conversation = openai_client.conversations.create()

# Primer turno
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# Segundo turno — el contexto se preserva
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Sin Redis. Sin almacén de sesiones Cosmos DB. Sin middleware personalizado para serialización de mensajes. La plataforma simplemente lo gestiona.

Mi framework de decisión

Después de revisar las seis opciones, aquí está mi modelo mental rápido:

¿Necesitas cero infraestructura? → Foundry Agents (portal/SDK, sin contenedores)
¿Tienes código de agente personalizado pero quieres hosting gestionado? → Foundry Hosted Agents
¿Necesitas tareas de agente cortas dirigidas por eventos? → Azure Functions
¿Necesitas máximo control de contenedores sin K8s? → Container Apps
¿Necesitas cumplimiento estricto y multi-clúster? → AKS
¿Tienes un agente HTTP simple con tráfico predecible? → App Service

Para la mayoría de desarrolladores .NET que construyen con Semantic Kernel o Microsoft Agent Framework, Hosted Agents es probablemente el punto de partida correcto. Obtienes scale-to-zero, OpenTelemetry integrado, gestión de conversaciones y flexibilidad de framework — sin gestionar Kubernetes ni montar tu propia pila de observabilidad.

Para terminar

El panorama de alojamiento de agentes en Azure está madurando rápido. Si estás empezando un nuevo proyecto de agente IA hoy, consideraría seriamente Foundry Hosted Agents antes de recurrir a Container Apps o AKS por costumbre. La infraestructura gestionada ahorra tiempo real, y el patrón de hosting adapter te permite mantener tu elección de framework.

Echa un vistazo a la guía completa de Microsoft y al repositorio de ejemplos de Foundry para ejemplos funcionales.