Microsoft Azure AI agent runtime: o que mudou no Foundry
TL;DR
O “runtime” de agentes no ecossistema Microsoft se consolidou no Foundry Agent Service, com Hosted Agents executando cada sessão em sandbox isolada de compute, memória e filesystem. Na prática, isso reduz o trabalho de infraestrutura e deixa a lógica do agente mais portátil entre SDKs e frameworks, sem obrigar reescritas do núcleo do agente.
O ponto mais relevante para times de engenharia é que esse runtime já nasce ligado a observabilidade e avaliação: chamadas de modelo, tool calls, sub-agent hops e handoffs passam por OpenTelemetry, e o deploy segue um fluxo containerizado com `azd`. Para quem trabalha com Azure em empresas brasileiras, isso conversa bem com governança, auditoria e operação em ambiente corporativo.
O que a Microsoft está chamando de runtime de agentes
Nas fontes do lançamento, o termo aparece materializado como Foundry Agent Service / Hosted Agents, não como um “server” isolado e genérico. O desenho é de um runtime gerenciado que recebe o agente, cria a sessão, isola a execução e entrega os protocolos para orquestração e telemetria (fonte).
Isso importa porque muda o centro de gravidade da implementação. Em vez de o time montar manualmente isolamento, lifecycle, tracing e avaliação, o Foundry assume essas camadas e libera o time para focar em tools, grounding e fluxo de negócio (fonte).
Sandbox por sessão, e não por aplicação inteira
O detalhe técnico mais importante é o isolamento por sessão. Cada execução roda em sandbox com recursos dedicados, incluindo compute, memória e filesystem, o que reduz acoplamento entre interações e ajuda a evitar vazamento de estado entre runs (fonte).
Na prática, esse modelo muda a forma de pensar testes e produção. Um agente que conversa com dados internos, chama APIs e escreve artefatos temporários fica mais fácil de operar quando a unidade de isolamento é a sessão, porque o comportamento fica mais previsível e auditável (fonte).
Framework-agnostic de verdade operacional
Outro ponto é a promessa de portabilidade operacional. As fontes citam suporte para agentes feitos com Microsoft Agent Framework, GitHub Copilot SDK, LangGraph e outros SDKs, todos hospedados no mesmo runtime sem exigir reescrita estrutural do agente (fonte).
Isso é útil para times que já têm decisões anteriores de stack. Em vez de abandonar a lógica do agente por causa do runtime, o time pode manter a camada de orquestração no seu framework preferido e deixar o Foundry cuidar de sessão, hosting e protocolo (fonte).
Protocolos, sessão e orquestração
O runtime não é só um contêiner com um processo rodando. Ele conversa por protocolos compatíveis com a Responses API e orquestra tool calls, sub-steps e handoffs como parte do fluxo do agente (fonte).
Isso a aproxima de um modelo de execução stateful, no qual a sessão e o histórico operacional têm valor de primeira classe. Para aplicações reais, isso facilita cenários como agentes que consultam dados, tomam passos intermediários, pedem confirmações e transferem a próxima etapa sem perder contexto (fonte).
Deploy containerizado com azd
Na trilha prática da Microsoft, o hosting do agente passa por container image e rollout via `azd`. O guia para LangGraph mostra o pacote de hosting exposto pelo langchain_azure_ai.agents.hosting e o deploy como parte do fluxo de publicação do agente (fonte).
Esse ponto é relevante porque alinha o runtime de agentes ao padrão que muitos times já conhecem em Azure: empacotar, publicar e operar. Para o dev que já vive em pipelines com infraestrutura como código, isso reduz a distância entre protótipo e produção (fonte).
Esta seção descreve a versão atual do modelo Hosted Agents no Foundry. APIs e fluxos de agentes em nuvem mudam rápido — confira as páginas oficiais antes de adotar em produção.
Observabilidade e avaliação deixam de ser “extras”
Uma mudança importante desse release é o acoplamento entre runtime e telemetria. O material do Build 2026 descreve que chamadas de modelo, invocações de ferramentas, saltos entre subagentes e handoffs passam por um pipeline de OpenTelemetry, e que as avaliações se conectam às traces geradas na produção (fonte).
Isso resolve um problema conhecido: medir um agente sem enxergar a cadeia de eventos costuma produzir diagnósticos incompletos. Quando a telemetria já nasce dentro do runtime, fica mais simples responder perguntas como “qual tool causou a falha?”, “em que passo o contexto se perdeu?” ou “qual sessão gerou custo fora do esperado?” (fonte).
OpenTelemetry como base para auditoria
Para times corporativos, isso conversa diretamente com revisão de incidentes e auditoria. O Foundry oferece configuração explícita de exportação de telemetria para OpenTelemetry, o que permite integrar o runtime a dashboards e pipelines já existentes no stack de observabilidade (fonte).
Na prática, o ganho não é só técnico. Ele também organiza a conversa entre engenharia, segurança e produto, porque o trace vira um artefato compartilhado para explicar comportamento do agente em produção (fonte).
O que isso significa para quem já usa Azure
Se você já opera em Azure, esse lançamento encaixa bem em uma trajetória de adoção incremental. O times podem manter modelos, recursos e integrações na mesma família de serviços, enquanto o runtime cuida do isolamento e do ciclo de execução do agente (fonte).
O efeito prático é reduzir a quantidade de cola operacional entre o código do agente e a camada de hospedagem. Em vez de gastar energia montando serviços auxiliares para sessão, tracing e handoff, o time concentra o diferencial em dados, ferramentas e regras de negócio (fonte).
Onde o Azure AI agent runtime faz mais sentido
Esse modelo tende a ser mais útil quando o agente depende de contexto persistente, integração com sistemas internos e rastreabilidade fina. Exemplos comuns incluem triagem de chamados, criação de tarefas, consulta a bases documentais, automação de backoffice e suporte a fluxos moderadamente complexos, com várias etapas e permissões (fonte).
Já para um chatbot simples e sem estado, um runtime tão completo pode ser mais do que o necessário. A escolha faz sentido quando o custo de se expor a falhas de orquestração, falta de rastreabilidade ou multi-step flows compensa a adoção do managed runtime (fonte).
Por que isso importa pro dev brasileiro
No Brasil, um detalhe concreto pesa bastante: muitas empresas operam com orçamento em BRL, mas consomem cloud e modelos cobrados em moeda estrangeira. Quando o runtime reduz retrabalho de infraestrutura, observabilidade dispersa e experimentação mal instrumentada, isso ajuda a controlar custo de operação e tempo de engenharia, dois pontos sensíveis em times que precisam justificar cada sprint para negócio e finanças.
Há também o aspecto regulatório. Em projetos que tratam dados pessoais, a LGPD exige cuidado com finalidade, minimização e rastreabilidade do tratamento. Um runtime com sessões isoladas e traces associadas a avaliações facilita explicações internas sobre o que o agente acessou, por quanto tempo e em qual etapa do fluxo (fonte).
Em cidades como São Paulo, Rio e Florianópolis, é comum ver times distribuídos entre produto, engenharia e segurança, com pressão para entregar rápido sem perder governança. Um runtime gerenciado que já embute telemetria e isolamento por sessão pode reduzir a dependência de “processos manuais” para aprovar um agente em ambiente corporativo.
Como estudar isso sem perder tempo
Se você quer comparar esse modelo com a sua stack atual, foque em três perguntas. Primeiro: o seu agente precisa de sessão persistente ou apenas inferência pontual? Segundo: hoje você consegue reconstruir uma falha de ponta a ponta com traces? Terceiro: o deploy do agente está acoplado ao framework ou à lógica de negócio?
Se as respostas apontam para muito retrabalho operacional, o Hosted Agents do Foundry merece atenção. Se a sua necessidade é mais estreita, talvez a melhor decisão seja copiar só os princípios — isolamento, observabilidade e rollout controlado — em vez de adotar a plataforma inteira de imediato (fonte).
Conclusão
O release mostra que a Microsoft está tratando agente como uma unidade operacional completa, não apenas como um prompt com ferramentas. O valor está na combinação de sandbox por sessão, compatibilidade com frameworks, observabilidade em OpenTelemetry e deploy containerizado, tudo embalado como runtime gerenciado (fonte).
Para um time brasileiro, a decisão prática é avaliar se esse modelo ajuda a diminuir custo de manutenção, acelerar auditoria e organizar o uso de Azure em um cenário de LGPD e orçamento em BRL. A melhor próxima ação é abrir o guia oficial de hosted agents, seguir o caminho de LangGraph ou Microsoft Agent Framework e reproduzir um agente simples com telemetria ligada em menos de uma hora (fonte).
Conteúdos da DIO para quem quer aprofundar
- Microsoft - Foundry Agentic Engineer — trilha prática para criar agentes no Microsoft Foundry e levar a implementação até fluxos de engenharia com GitHub Enterprise.
- Aceleração Microsoft - Azure AI Agents — evento focado em criar, orquestrar e governar agentes de IA no ecossistema Microsoft.
- Aceleração Microsoft AI Agents — conteúdo prático sobre agentes e ferramentas de IA aplicadas ao desenvolvimento.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
