Microsoft lança hosted agents no Foundry Agent Service

Introdução

A Microsoft lançou os hosted agents no Foundry Agent Service em prévia pública, com foco em computação segura e escalável para agentes de IA que rodam em produção. A palavra‑chave hosted agents Foundry Agent Service não é detalhe, é a base do anúncio e do movimento que transforma assistentes em sistemas que realmente executam tarefas.

O destaque técnico é o novo modelo de sessão isolada com persistência de filesystem, identidade dedicada por agente e endpoints estáveis com versionamento. Além disso, há suporte a BYO VNet para controlar tráfego de saída, integração com frameworks como LangGraph e Microsoft Agent Framework e compatibilidade com o protocolo Responses, o que facilita a adoção em ambientes corporativos.

Este artigo analisa o que muda na prática, por que o desenho de hosted agents importa para segurança e custo, onde essa abordagem se encaixa no portfólio Azure e como começar com passos realistas, evitando armadilhas comuns de migração. As referências oficiais nascem do anúncio técnico e da documentação do Microsoft Learn, além de material de suporte publicado nas últimas semanas.

O que são hosted agents e por que importam

Hosted agents são agentes de IA que rodam como serviços gerenciados no Foundry Agent Service. Cada sessão do usuário ganha um ambiente isolado em nível de hypervisor com filesystem persistente, o que permite que o agente leia e escreva arquivos, execute código com segurança e retome o trabalho exatamente de onde parou após um scale‑to‑zero. Isso difere de computação tradicional baseada em containers compartilhados por múltiplas sessões, reduzindo riscos de vazamento de estado entre clientes.

Na prática, esse isolamento por sessão com persistência de disco evita o padrão de recriar contexto a cada interação e elimina boa parte da cola de infraestrutura que times precisavam montar. O serviço entrega cold start previsível, escala para zero quando o agente está ocioso e volta rápido mantendo o diretório de trabalho da sessão, o que reduz custos sem sacrificar estado.

Outro ponto crítico é a identidade. Cada agente recebe uma identidade de Entra própria desde o deploy. Isso simplifica governança e auditoria, já que o agente age como ele mesmo, com rastreabilidade completa, e pode também operar em nome do usuário via OBO quando apropriado. Em conjunto com private networking e guardrails da plataforma, esse desenho atende exigências de segurança comuns em setores regulados.

Principais capacidades do anúncio

Isolamento por sessão com sandbox dedicado e filesystem persistente, garantindo que cada conversa e execução de código ocorra separadamente de outras sessões.
Escala para zero com retomada íntegra do estado de disco, reduzindo custo em períodos ociosos sem perder contexto.
Identidade dedicada por agente, com auditoria contínua e atuação em nome do usuário quando necessário, além de endpoints estáveis com versionamento e rollouts ponderados.
Suporte multi‑modelo e multi‑framework, incluindo LangGraph, Microsoft Agent Framework, OpenAI Agents SDK, Claude Agent SDK e GitHub Copilot SDK, todos mapeados ao protocolo Responses para interoperabilidade.
BYO VNet e trilha de rede privada no serviço, incluindo extensão do escopo privado para conexões de ferramentas MCP, Azure AI Search e agentes de dados do Fabric. Isso fecha superfícies de exposição de dados sensíveis.
Integração com observabilidade baseada em OpenTelemetry, avaliações de qualidade e red teaming, centralizadas no Foundry Control Plane, com GA anunciado em março de 2026.

![Corredor de racks de data center com iluminação azul]

Como hosted agents se comparam a outras opções Azure

Até aqui, muitos times colocaram agentes em produção usando funções serverless, apps web ou containers. Funciona no começo, mas ferramentas que leem e escrevem estado, executam código e mantêm memórias demandam um runtime com abstrações de agente, não apenas um serviço HTTP. Materiais recentes da Microsoft comparam Hosted Agents a Functions, App Service, Container Apps e AKS, posicionando Hosted Agents como caminho de baixa complexidade operacional quando se quer trazer código e framework próprios sem abrir mão de um serviço gerenciado.

Vale notar uma nuance temporal. Em 15 de abril de 2026, um guia de escolha de hospedagem ainda listava Hosted Agents com limitações de rede privada. Em 22 de abril de 2026, os anúncios atualizaram o quadro, incluindo suporte a BYO VNet e reforçando a trilha de rede privada de ponta a ponta no Agent Service. Para decisões de arquitetura, considere essas datas e recursos já presentes na prévia atual.

Em termos de escolha prática, o desenho é o seguinte:

Azure Functions e App Service: melhor para agentes leves orientados a eventos ou simples web backends, com baixo controle de execução e sem abstrações nativas de agente.
Azure Container Apps e AKS: ótimo quando se precisa de controle de orquestração, malha de serviços e redes avançadas, aceitando maior esforço operacional.
Foundry Agents e Hosted Agents: quando a prioridade é um runtime feito para conversas, ferramentas e memória, com observabilidade e governança nativas, reduzindo o trabalho de infraestrutura. Hosted Agents entram quando é necessário trazer o próprio código e framework, mantendo simplicidade operacional.

O que muda para times que já testaram a prévia antiga

A Microsoft publicou um guia de migração para a prévia renovada, que substitui o backend inicial por um novo modelo baseado em sessão. Pontos de atenção com datas claras: o backend da prévia inicial será suportado somente até 22 de maio de 2026 e não haverá migração automática, portanto é necessário redeploy seguindo o novo modelo.

As principais mudanças incluem:

Sessão com isolamento forte e filesystem persistente, escalonando automaticamente após 15 minutos de inatividade.
Bibliotecas de protocolo substituem adaptadores de framework, com suporte aos protocolos Responses, Invocations, Activity e A2A.
Identidade dedicada por agente desde a criação, em vez de identidade gerenciada do projeto. Ajuste de RBAC é obrigatório.
Endpoint dedicado por agente, eliminando o roteamento via endpoint compartilhado do projeto e parâmetro agent_reference no corpo da requisição.
Cobertura completa de ciclo de vida via REST e SDKs atualizados, com novos comandos azd para inspecionar, monitorar e invocar agentes.

Passo a passo rápido para iniciar

Um quickstart oficial mostra como provisionar, testar localmente e fazer deploy do primeiro hosted agent usando Azure Developer CLI e a extensão do Foundry para VS Code. Requisitos incluem Python 3.10+, azd 1.24.0+ e a extensão azd ai agent. O documento sinaliza explicitamente a necessidade de versões pré‑lançamento das ferramentas e lembra que hosted agents estão em prévia.

Resumo operacional prático:

Instalar e configurar a extensão azd ai agent.
Inicializar o projeto e provisionar recursos, incluindo Foundry Project, modelo, ACR e monitoramento.
Testar o agente localmente com o servidor HTTP padrão na porta 8088, incluindo comando de invocação local.
Fazer deploy com azd deploy, observando que a identidade do agente receberá papéis necessários no runtime.
Conferir o Agent Playground no portal ai.azure.com, o endpoint dedicado e, após testes, limpar recursos para evitar custos.

Segurança e rede, do jeito que o time de risco espera

A linha mestra do Foundry Agent Service em GA inclui redes privadas fim a fim, integração com MCP com amplo leque de autenticação e observabilidade corporativa. Para Hosted Agents, o anúncio de prévia pública detalha BYO VNet para controlar o tráfego de saída do agente e manter caminhos de dados dentro das fronteiras da organização. Esses recursos respondem diretamente a exigências de DLP, auditorias e políticas de tráfego interno que antes barravam agentes em produção.

Do ponto de vista de governança, o Control Plane reúne avaliações de groundedness, segurança e qualidade, além de tracing baseado em OpenTelemetry e integração com Azure Monitor para pipelines contínuos de avaliação. Para ambientes críticos, é possível desativar features em prévia e padronizar em capacidades GA.

![Corredor espelhado de racks e dutos de ventilação]

Produtividade de desenvolvedores, hoje, não amanhã

Um ponto subestimado é a interoperabilidade via protocolo Responses. Várias equipes já constroem agentes com esse protocolo, então levar o mesmo agente para o Foundry tende a exigir poucas mudanças. Em troca, a equipe herda segurança empresarial, rede privada, observabilidade e controles de versão do serviço. O anúncio de GA oficializou essa base comum e deixou claro que prompt agents estão em GA, enquanto hosted agents seguem em prévia com expansão regional.

A plataforma também empacota componentes que aceleram o que realmente dói em produção, como memória gerenciada em prévia, que extrai, consolida e recupera preferências e fatos relevantes entre sessões sem banco de embeddings customizado. Para times que evitavam criar um subsistema de memórias por conta própria, essa peça reduz escopo e tempo de entrega.

Aplicações práticas e recomendações de adoção

Quando escolher Hosted Agents: necessário trazer seu próprio framework, executar ferramentas que leem e escrevem arquivos, executar código em runtime controlado e manter estado entre interações, com baixa carga de SRE.
Quando escolher Container Apps ou AKS: exigência de malha de serviços, sidecars, rede avançada já estabelecida e times prontos para operar clusters, aceitando overhead operacional.
Quando escolher Functions ou App Service: agentes simples, orientados a eventos e custos mínimos por execução, sabendo que terá de construir manualmente persistência de estado e parte da observabilidade.

Para iniciar com baixo risco, uma abordagem por estágios funciona bem:

Prove o valor do fluxo agentic com prompt agents e ferramentas gerenciadas, colhendo métricas de uso.
Evolua componentes críticos para Hosted Agents quando precisar de código customizado, testes de carga com escala para zero e memória de sessão.
Ative BYO VNet e RBAC refinado para dados sensíveis, garantindo que chamadas de ferramentas MCP, Azure AI Search e Fabric ocorram em rede privada.
Implemente avaliações contínuas e tracing desde o primeiro piloto para acelerar correções e evitar regressões.

Armadilhas comuns e como evitar

Confiar na prévia antiga: há um prazo objetivo, 22 de maio de 2026, para descontinuação do backend inicial da prévia. Planeje a migração, atualize SDKs, troque adaptadores por bibliotecas de protocolo e refaça o deploy com endpoints dedicados.
Ignorar identidade dedicada do agente: papéis e permissões agora pertencem ao agente, não mais à identidade gerenciada do projeto. Ajuste RBAC e testes de acesso a recursos downstream.
Subestimar custos ociosos: configure escala para zero onde possível e use retomada com filesystem para conter gasto sem perder produtividade.
Usar documentação desatualizada: um post comparativo de 15 de abril de 2026 mencionava ausência de rede privada para Hosted Agents, atualizado pelos anúncios de 16 e 22 de abril. Sempre verifique datas e notas de versão antes de decidir.

Conclusão

Hosted agents no Foundry Agent Service aceleram a travessia do protótipo para a operação diária. Com isolamento forte, persistência, identidade dedicada e rede privada, a plataforma ataca as dores reais de levar agentes de IA para ambientes corporativos. A escolha do desenho hosted agents Foundry Agent Service reduz a sobrecarga de infraestrutura e libera o time para investir no comportamento do agente e no resultado de negócio.

O recado final é pragmático. Use o que já funciona, o protocolo Responses e seus frameworks preferidos, e traga o agente para um runtime feito para agentes. Migre do backend antigo até 22 de maio de 2026, habilite BYO VNet e coloque avaliações contínuas na linha do tempo do projeto. Com isso, dá para crescer com segurança e previsibilidade, sem travar a entrega de valor.