¡Hola Devs! Se acabó el matrimonio con un solo modelo
Fíjate en esto: hasta hace poco, la mayoría de los equipos elegía un modelo al inicio del proyecto y se casaba con él. Y en cuanto salía un release nuevo, tu agente de código ya estaba corriendo con el cerebro de ayer, y cambiar significaba reconstruir orquestación, evals y wiring de herramientas desde cero. Un dolor.
Microsoft Foundry apuesta a que la elección de modelo ya no es una decisión de proyecto, sino una decisión continua. La idea: mantener tus sistemas empresariales, conocimiento, herramientas y controles intactos mientras cambias el motor por debajo. Es la misma lógica de repensar el retraining como una decisión de respecify-o-hold en vez de un refit reflejo—el modelo es variable, no cimiento.
Esta semana entraron a Foundry la familia GPT-6 completa (Sol y Luna) y Claude Opus 5.5 de Anthropic. Lo interesante no es un modelo específico—es que varios proveedores frontier están publicando sobre la misma superficie de evaluación.
Lo que realmente salió
1. Voice Agents como tipo nativo de agente
Antes, voz significaba colgar STT/TTS encima de un agente de texto y rezar para que el turn-taking no se rompiera. Ahora Foundry Agent Service trata la voz como ciudadana de primera clase:
# Ejemplo: creando un voice agent vía SDK de Foundry (ilustrativo)
from foundry.agents import VoiceAgent, RealtimeModel
agente = VoiceAgent(
name="soporte-voz",
model=RealtimeModel.GPT_REALTIME, # o AZURE_REALTIME, MAI
instructions="Resuelve reembolsos con empatía.",
tools=[consultar_pedido, emitir_reembolso],
languages=["es-MX", "en-US", "pt-BR"],
)
agente.deploy(channel="teams_phone")
Preview pública con 80+ idiomas, 140+ locales, recuperación de interrupciones y voces/avatares custom. También puedes traer tu propio modelo realtime.
2. Resiliencia para tareas largas en hosted agents
El trabajo real no cabe en una sola request. Un agente de investigación puede recorrer 40 fuentes en 20 minutos. La nueva resiliencia de Foundry hace que los hosted agents sobrevivan desconexiones y restarts, retomando desde el último checkpoint durable vía Microsoft Agent Framework.
3. Toolboxes + Tool Search
El número que importa: en un benchmark interno con 44,000+ herramientas y 7,000 queries, tool search redujo tokens de entrada en 60% para una toolbox de 50 herramientas y 97%+ para una de 1,000, comparado con cargar el catálogo completo. Eso no es micro-optimización—es la diferencia entre un agente viable y un pozo sin fondo de costos.
4. El loop de mejora continua
Esta es la feature que nadie está mirando todavía. Foundry está cosiendo:
- Insights (preview): encuentra problemas recurrentes en producción que ni sabías buscar
- Rubric evaluator: convierte requisitos en criterios medibles
- Traces-to-dataset: construye tests desde tráfico real
- Agent optimizer: prueba cambios de instrucción/herramienta/skill/modelo antes de shipear
Vuelve a producción. Repite. Cada pasada queda mejor.
Tabla de trade-offs
| Capacidad | Status | Qué resuelve | Ojo con |
|---|---|---|---|
| Familia GPT-6 + Claude Opus 5.5 | GA | Amplitud de elección | Eval sprawl—cada modelo pide su rubric |
| Voice agents | Preview pública | Orquestación de voz nativa | SLA de preview; costo de telefonía sube rápido |
| Resiliencia para tareas largas | Preview pública | Sobrevivir disconnect/restart | El diseño de checkpoint es tuyo |
| Tool search | GA | Explosión de costo en tokens | No arregla descripciones malas de herramientas |
| Protocolo A2A | GA | Llamadas agente-a-agente | La gobernanza se complica conforme crece el grafo |
| Agent optimizer | GA este mes | Tuning manual de performance | Eval mala entra, optimización mala sale |
| Controles de egress de red | GA | Sandbox de salida | Modo audit primero, enforce después |
Limitaciones que no puedes ignorar
- Preview ≠ producción. Voice agents y resiliencia larga son preview pública. Ok para piloto, riesgoso para workloads regulados.
- Foundry sigue teniendo forma de Azure. Model-agnostic es real en la capa de API, pero gobernanza, identidad y red dependen de Entra, APIM y Application Insights. La portabilidad tiene límites.
- El optimizer es tan bueno como tus evals. Rubric vaga = vas a shipear el cambio equivocado con toda confianza.
- La latencia de voz es física. Los modelos realtime ayudan, pero cobertura de 80+ idiomas no significa 80+ experiencias igual de buenas.
Por dónde seguir
Si ya estás en Foundry, empieza por tool search—es GA, es medible y se paga solo. Si estás construyendo voz, prototipa en preview pero mantén un fallback de texto. Si haces investigación agentic o workflows largos, configura checkpoints antes de necesitarlos.
Para quienes están batallando con cuándo cambiar de modelo versus cuándo aguantar, el framework refit-vs-respecify es una lente útil. Y si estás construyendo UIs event-driven para agentes, vale la pena leer la comparación entre pseudo-clases y event listeners JS antes de over-engineer el lado cliente.
Resumiendo la ópera
El mensaje de Foundry es simple: deja de reconstruir alrededor del modelo, empieza a mejorar alrededor del resultado. El loop del optimizer—observa, evalúa, optimiza, valida, repite—es el producto de verdad. Los modelos son inputs intercambiables.
Dicho esto, 'model-agnostic' es un espectro, no un binario. Foundry reduce lock-in de forma significativa, pero no elimina la gravedad de Azure. Para quienes ya están en el stack Microsoft, es un upgrade claro. Para todos los demás, es una señal fuerte de que la guerra de plataformas de agentes ahora es sobre ops, no solo sobre modelos.
Fuentes: Anuncio de Microsoft Foundry