TL;DR: Este artigo analisa o preview do Hosted Agents no Microsoft Foundry Agent Service, um runtime containerizado que executa agentes em VMs por sessão em infraestrutura gerenciada pela Microsoft. Para empresas brasileiras, isso reduz a carga operacional de gerenciar clusters de agentes, mas exige atenção aos custos por sessão e dependência de provedor único. A principal conclusão: ideal para times que priorizam velocidade de deploy sobre controle total da infra.
A Microsoft anunciou a prévia do Hosted Agents no Foundry Agent Service — um runtime baseado em containers que permite aos desenvolvedores trazerem seu próprio código de agente, escrito em qualquer framework (LangChain, Semantic Kernel, entre outros), e implantá-lo diretamente em infraestrutura gerenciada pela Microsoft. Cada agente é executado em uma VM isolada por sessão, simplificando o ciclo de deploy e operação.
O que são Hosted Agents no Foundry Agent Service e como funcionam?
Hosted Agents é uma evolução do modelo de execução de agentes no ecossistema Microsoft Foundry. Em vez de você gerenciar clusters Kubernetes, containers ou VMs para rodar seus agentes, a Microsoft provisiona uma VM Linux efêmera para cada sessão de agente. O container com seu código é iniciado, processa a requisição e, ao final, o recurso é liberado.
Isso elimina tarefas operacionais como scaling manual, patches de sistema e monitoramento de health checks — tudo fica sob responsabilidade da plataforma. Na prática, seu time foca no código do agente e nas regras de negócio, enquanto a Microsoft cuida da infraestrutura.
Como isso impacta o desenvolvimento de agentes de IA em empresas brasileiras?
Para times de engenharia no Brasil, o grande benefício é a redução de complexidade operacional. Montar e manter um ambiente para agentes de IA — especialmente com requisitos de baixa latência e alta disponibilidade — demanda expertise em Kubernetes, rede e autoscaling. Com Hosted Agents, startups e empresas de médio porte podem colocar agentes em produção em dias, sem precisar de uma equipe dedicada de SRE.
Outro ponto crítico é a escalabilidade sob demanda. Como cada sessão gera uma nova VM, picos de requisição não exigem provisionamento prévio. Para aplicações de chatbot, recomendações em tempo real ou automação de processos, isso é um diferencial. Porém, o custo por sessão pode se tornar imprevisível se o volume de interações for alto e constante — algo que times brasileiros, muitas vezes com budgets enxutos, precisam monitorar de perto.
Quais os riscos e pontos de atenção ao adotar Hosted Agents?
A prévia traz riscos inerentes: SLA não garantido, possíveis mudanças de API e limitações de região. Empresas brasileiras que dependem de baixa latência para usuários finais precisam verificar se a Microsoft Foundry está disponível em data centers no Brasil (atualmente, Azure tem regiões em São Paulo, mas o Foundry Agent Service pode ainda não ter suporte local na preview).
Outro ponto é o vendor lock-in. Ao adotar Hosted Agents, você fica vinculado ao ecossistema Microsoft para execução. Se no futuro precisar migrar para outro provedor ou para on-premises, o container pode ser portável, mas as integrações com IAM, monitoring e billing são proprietárias.
Por fim, o modelo per-session VM pode não ser ideal para agentes que exigem estado persistente entre requisições ou que precisam de GPUs dedicadas (embora a VM por sessão possa ter GPU, isso depende da configuração e custos adicionais).
Hosted Agents ou self-hosted: o que considerar?
A escolha depende do perfil da sua aplicação:
- Hosted Agents: recomendado para equipes que querem acelerar o time-to-market, têm cargas imprevisíveis e não querem se preocupar com operação de infraestrutura. Ideal para MVPs, protótipos e aplicações com picos sazonais.
- Self-hosted: mais adequado para aplicações com volume constante, requisitos rigorosos de privacidade de dados (LGPD) ou necessidade de controle fino de performance e custo. Exige time de operações maduro e investimento em automação (Kubernetes, CI/CD, observability).
Uma abordagem híbrida também é válida: usar Hosted Agents para cargas não críticas e manter self-hosted para workloads core.
Perguntas Frequentes
-
O Hosted Agents suporta qualquer framework de agentes?
Sim, como o runtime é containerizado, você pode empacotar agentes escritos em qualquer framework (LangChain, Semantic Kernel, etc.) desde que o container seja compatível com o ambiente Linux da VM por sessão. A Microsoft não impõe um framework específico, mas é necessário ajustar o entrypoint e a comunicação com o agente service. -
Quais são as principais limitações da versão preview?
A preview pode ter SLAs reduzidos, limitação de escalabilidade e ausência de recursos como auto-scaling avançado ou integração completa com Azure Monitor. Também não há garantia de que todas as regiões estarão disponíveis — times brasileiros devem verificar a cobertura no Brasil (Sul ou Sudeste). -
Hosted Agents é mais barato que gerenciar nossa própria infraestrutura de agentes?
Depende do volume. Para cargas variáveis com picos esporádicos, o modelo por sessão pode ser mais econômico que manter VMs dedicadas. Porém, para workloads constantes e previsíveis, um cluster self-hosted bem otimizado pode ter custo total menor. É fundamental modelar o custo por agente/sessão antes de decidir. -
O que acontece com a latência se minha aplicação estiver no Brasil e o agente rodar em um data center nos EUA?
A latência pode ser um problema significativo para agentes que exigem respostas em tempo real. A Microsoft Foundry tem data centers em São Paulo, mas o Hosted Agents ainda pode não estar disponível localmente na preview. Recomendamos monitorar a região de deploy e, se necessário, usar proxies ou manter um self-hosted em cloud brasileira. -
Posso migrar agentes self-hosted para Hosted Agents sem refatorar o código?
Provavelmente sim, desde que o agente esteja containerizado e use APIs padrão (HTTP, gRPC). A migração exige apenas ajustar o entrypoint para o ambiente da VM por sessão e configurar as variáveis de ambiente. Frameworks como LangChain ou Semantic Kernel geralmente funcionam sem grandes mudanças.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
