Chega de casar com um modelo só
Olha só, dev: até ontem, a galera escolhia um modelo no início do projeto e ficava preso nele. Aí saía um release novo e pronto—seu agente de código já estava rodando com o cérebro de ontem, e trocar significava reconstruir orquestração, evals e integração de ferramentas do zero. Um pesadelo.
O Microsoft Foundry está apostando que escolha de modelo não é mais uma decisão de projeto, e sim uma decisão contínua. A ideia é manter seus sistemas corporativos, conhecimento, ferramentas e controles intactos enquanto você troca o motor por baixo. É a mesma lógica de repensar retraining como uma decisão de respecify-ou-hold em vez de refit reflexivo—o modelo é variável, não fundação.
Nessa semana entraram no Foundry a família GPT-6 completa (Sol e Luna) e o Claude Opus 5.5 da Anthropic. O interessante não é um modelo específico—é que vários provedores frontier estão publicando na mesma superfície de avaliação.
O que realmente saiu
1. Voice Agents como tipo nativo de agente
Antes, voz significava pendurar STT/TTS em cima de um agente de texto e rezar pro turn-taking não quebrar. Agora o Foundry Agent Service trata voz como cidadã de primeira classe:
# Exemplo: criando um voice agent via SDK do Foundry (ilustrativo)
from foundry.agents import VoiceAgent, RealtimeModel
agente = VoiceAgent(
name="suporte-voz",
model=RealtimeModel.GPT_REALTIME, # ou AZURE_REALTIME, MAI
instructions="Resolva pedidos de reembolso com empatia.",
tools=[consultar_pedido, emitir_reembolso],
languages=["pt-BR", "en-US", "es-MX"],
)
agente.deploy(channel="teams_phone")
Preview público com 80+ idiomas, 140+ locales, recuperação de interrupção e vozes/avatares customizados. Dá pra trazer seu próprio modelo realtime também.
2. Resiliência para tarefas longas em hosted agents
Trabalho real não cabe em uma request. Um agente de pesquisa pode varrer 40 fontes em 20 minutos. A nova resiliência do Foundry faz hosted agents sobreviverem a desconexões e restarts, retomando do último checkpoint durável via Microsoft Agent Framework.
3. Toolboxes + Tool Search
O número que importa: num benchmark interno com 44.000+ ferramentas e 7.000 queries, o tool search cortou tokens de entrada em 60% para uma toolbox de 50 ferramentas e 97%+ para uma de 1.000, comparado a carregar o catálogo inteiro. Isso não é micro-otimização—é a diferença entre um agente viável e um sorvedouro de custo.
4. O loop de melhoria contínua
Essa é a feature que ninguém está olhando ainda. O Foundry está costurando:
- Insights (preview): acha problemas recorrentes em produção que você nem sabia procurar
- Rubric evaluator: transforma requisitos em critérios mensuráveis
- Traces-to-dataset: constrói testes a partir de tráfego real
- Agent optimizer: testa mudanças de instrução/ferramenta/skill/modelo antes do deploy
Volta pra produção. Repete. Cada passada fica melhor.
Tabela de trade-offs
| Capacidade | Status | Resolve o quê | Fica esperto com |
|---|---|---|---|
| Família GPT-6 + Claude Opus 5.5 | GA | Amplitude de escolha | Eval sprawl—cada modelo pede sua rubric |
| Voice agents | Preview público | Orquestração de fala nativa | SLA de preview; custo de telefonia sobe rápido |
| Resiliência para tarefas longas | Preview público | Sobreviver a disconnect/restart | Design de checkpoint é com você |
| Tool search | GA | Explosão de custo em tokens | Não conserta descrição ruim de ferramenta |
| Protocolo A2A | GA | Chamadas agente-a-agente | Governança fica mais difícil conforme o grafo cresce |
| Agent optimizer | GA este mês | Tuning manual de performance | Eval ruim entra, otimização ruim sai |
| Controles de egress de rede | GA | Sandbox de saída | Modo audit primeiro, enforce depois |
Limitações que você não pode ignorar
- Preview ≠ produção. Voice agents e resiliência longa são preview público. Ok pra piloto, arriscado pra workload regulado.
- Foundry ainda tem forma de Azure. Model-agnostic é real na camada de API, mas governança, identidade e rede dependem de Entra, APIM e Application Insights. Portabilidade tem limite.
- O optimizer é tão bom quanto suas evals. Rubric vaga = você vai shipar mudança errada com confiança.
- Latência de voz é física. Modelos realtime ajudam, mas cobertura de 80+ idiomas não significa 80+ experiências igualmente boas.
Por onde seguir
Se você já está no Foundry, comece pelo tool search—é GA, é mensurável e se paga. Se está construindo voz, prototipe no preview mas mantenha um fallback de texto. Se faz pesquisa agentic ou workflows longos, configure checkpoints antes de precisar deles.
Pra quem está batendo cabeça sobre quando trocar de modelo versus quando segurar, o framework refit-vs-respecify é uma lente útil. E se você está construindo UIs event-driven pra agentes, vale ler a comparação entre pseudo-classes e event listeners JS antes de over-engineer o lado cliente.
Resumindo a ópera
A mensagem do Foundry é simples: para de reconstruir em volta do modelo, começa a melhorar em volta do resultado. O loop do optimizer—observa, avalia, otimiza, valida, repete—é o produto de verdade. Modelos são inputs intercambiáveis.
Dito isso, 'model-agnostic' é um espectro, não um binário. O Foundry reduz lock-in de forma significativa, mas não elimina a gravidade do Azure. Pra quem já está no stack Microsoft, é upgrade claro. Pra todo mundo, é um sinal forte de que a guerra das plataformas de agente agora é sobre ops, não só sobre modelos.
Fontes: Anúncio do Microsoft Foundry