Microsoft Foundry junta toolbox, skills y publicación a Teams/Copilot: menos demos aisladas y más ruta a producción

Una de las trampas más comunes en agentes enterprise es quedarse atrapado entre tres islas:

• una demo donde el agente funciona;
• una caja de tools mal gobernada;
• y un canal final donde nadie lo usa porque nunca aterrizó en la superficie de trabajo real.

Microsoft intentó cerrar ese hueco en su recap de Build 2026 del 2 de junio de 2026. La nota no trae una sola gran feature. Trae algo más útil: una ruta más continua entre desarrollo, catálogo de tools y distribución interna.

La pieza se entiende mejor si juntas tres capas que Microsoft presentó en el mismo movimiento:

1. Foundry Toolkit para VS Code ya en general availability;
2. Toolboxes in Foundry en public preview;
3. publicación de agentes a Microsoft Teams y Microsoft 365 Copilot, planificada para disponibilidad general en junio de 2026.

La idea importante: pasar de discovery a execution sin cambiar de planeta

Microsoft lo resume bien en su blog de toolboxes: el problema no es solo descubrir tools. También necesitas contexto de negocio, skills versionadas y una forma de ejecutar eso dentro de un runtime gobernado.

Ahí es donde Toolboxes se vuelve interesante. La tesis no es “otro catálogo más”. La tesis es un endpoint gestionado donde un agente puede descubrir tools, usar conectores ya provisionados como MCP gestionado y cargar skills versionadas sin cableado custom.

El post de Microsoft baja varios puntos concretos:

• conectores a SaaS y sistemas de negocio mediante managed MCP servers;
• skills adjuntas a la toolbox como catálogo reutilizable;
• guardrails para controlar inputs y outputs de llamadas a tools;
• y rutinas para disparar agentes por horario o evento cuando el caso no exige un workflow más complejo.

Eso ya se parece mucho menos a una demo suelta y mucho más a una plataforma de operación.

Por qué el Toolkit GA en VS Code sí importa

Hay mucha cobertura de plataformas que suena a portal bonito, pero ignora dónde trabaja el builder. Aquí Microsoft fue bastante explícito: Foundry Toolkit para VS Code ya es parte central de la historia.

La documentación de toolbox muestra que puedes:

• instalar la extensión;
• crear y publicar una toolbox desde la vista de tools;
• copiar el endpoint consumidor;
• y hasta scaffoldear un hosted agent ya conectado a esa toolbox.

Eso reduce una fricción muy concreta. En vez de diseñar herramientas en el portal y luego rearmar a mano el proyecto local, el flujo puede empezar donde el equipo ya escribe y prueba código.

La documentación del Microsoft Foundry Skill también da otra pista útil: Microsoft ya empaqueta skills específicas para la experiencia de VS Code, incluyendo onboarding, selección de modelos, despliegue de agentes, evaluación y manejo de toolboxes.

La lectura importante es esta: Foundry ya no quiere ser solo el backend del agente; quiere meterse también en la experiencia diaria del builder.

Donde Toolboxes cambia de verdad el trabajo

La parte más potente del blog de Microsoft no es el nombre. Es la separación entre:

• tools, que dicen qué puede hacer el agente;
• y skills, que dicen cómo debe hacerlo.

Ese detalle importa muchísimo. Muchos equipos ya tienen APIs, conectores o MCP. Lo que no tienen es una forma ordenada de:

• versionar conocimiento operativo;
• compartirlo entre agentes;
• y gobernarlo sin repartir scripts y prompts por cinco repos.

Toolbox intenta convertir eso en un activo gestionado.

Si funciona como promete, el beneficio para tráfico cualificado es claro. Las búsquedas buenas aquí no son “qué es Foundry”. Son más específicas:

• microsoft foundry toolbox
• foundry toolkit vscode
• managed mcp microsoft foundry
• publicar agente a teams

Ese tipo de intención vale mucho más para Agente IA que otra nota genérica sobre “plataformas de agentes”.

La última milla: publicar donde la gente ya trabaja

Aquí es donde Microsoft intenta cerrar el argumento.

Su recap dice que los agentes de Foundry podrán publicarse en Teams y Microsoft 365 Copilot, y la guía de Learn lo aterriza bastante bien: lo que se publica es el endpoint estable del agente, para que el usuario final vea una entidad consistente aunque el equipo vaya rotando versiones detrás.

Eso resuelve un problema bastante real. Muchos agentes enterprise mueren no porque el modelo falle, sino porque nunca salen de un panel técnico que nadie fuera del equipo visita.

Llevarlos a Teams o Copilot cambia la distribución, pero también mete restricciones y riesgos:

• la propia guía marca que es una preview temprana;
• hay límites en streaming y citas;
• y no todo el comportamiento se conserva igual entre superficies.

O sea: sí, hay una ruta de distribución. Pero todavía no es una excusa para soltar cualquier agente a usuarios finales sin pruebas ni revisión de permisos.

Mi lectura práctica

Esta historia importa porque Microsoft está intentando unir tres cosas que otras stacks suelen dejar separadas:

1. construir el agente desde el entorno del developer;
2. gobernar tools y skills como catálogo reutilizable;
3. publicar el agente donde ya vive el trabajo interno.

Si yo lo evaluara hoy, no arrancaría por un caso crítico. Haría una secuencia más sobria:

1. montar una toolbox pequeña con dos o tres tools útiles;
2. adjuntar una skill versionada;
3. probar el hosted agent desde VS Code;
4. publicar después un caso interno de bajo riesgo en Teams.

Si ese loop funciona, Foundry empieza a verse menos como un set de piezas sueltas y más como una ruta sería a producción.

Esta nota conversa bien con Microsoft Foundry Agent Optimizer, porque una pieza intenta mejorar el comportamiento del agente y esta otra intenta ordenar cómo descubre herramientas, cómo se construye y dónde termina usándose. Si todavía estás en una etapa más básica de tools, memoria y validación, el punto de entrada más limpio sigue siendo el curso gratis.