Colocar um agente de IA para rodar em produção sempre foi mais difícil do que construí-lo. O protótipo funciona no notebook, mas aí começam as perguntas: onde hospedar? como isolar cada sessão? como escalar, persistir estado, dar identidade segura e observabilidade? Os hosted agents no Microsoft Foundry (Foundry Agent Service) atacam exatamente essa lacuna: você traz o seu código, o Foundry cuida da infraestrutura.

No palco do Build Este é o tema que levo ao Microsoft Build Brasil 2026, ao lado de Fábio Christiano e baseado na documentação oficial do Microsoft Learn. Se você vai ao evento, vamos trocar ideia sobre agentes de IA em produção no Foundry.

O que são hosted agents?

Hosted agents são aplicações agênticas conteinerizadas que rodam sobre o Foundry Agent Service. Diferente dos prompt-based agents — definidos só por prompt e configuração de ferramentas no portal —, o hosted agent é o seu código empacotado como imagem de container. Você escolhe o framework, controla o comportamento em runtime e o Foundry executa isso em infraestrutura gerenciada, chamando os modelos do catálogo para o raciocínio enquanto o seu código faz a orquestração.

O problema que eles resolvem

Quando você sobe um agente por conta própria com um framework open-source, herda um monte de responsabilidades transversais: conteinerização, servidor web, segurança, persistência de memória, escalonamento, instrumentação e rollback de versão. Em ambientes de nuvem heterogêneos, isso vira um projeto de plataforma inteiro — antes mesmo de entregar valor de negócio. O hosted agent transfere essa carga para o Foundry e deixa você focar na lógica do agente.

Como funciona — passo a passo

1. Empacote o agente como imagem de container, usando o framework que preferir — Microsoft Agent Framework, Semantic Kernel, LangGraph ou código próprio em Python/C#.
2. Publique a imagem no Azure Container Registry.
3. Faça o deploy: o Agent Service puxa a imagem, provisiona o compute, atribui uma identidade do Microsoft Entra dedicada ao agente e expõe um endpoint próprio.
4. Em runtime, o seu código recebe as requisições e pode chamar os modelos do catálogo Foundry, ferramentas do Toolbox e serviços do Azure usando a identidade do agente.
5. A plataforma cuida de escalonamento, persistência de estado da sessão, observabilidade e ciclo de vida — provisionando quando há atividade e desprovisionando ao atingir o timeout de ociosidade.

Atualização 2026 No Build 2026, os hosted agents ficaram ainda mais completos: isolamento por sessão em nível de hipervisor (VM), filesystem persistente que sobrevive ao scale-to-zero por até 30 dias, cobrança scale-to-zero (você paga o compute só quando o agente executa), suporte a múltiplos protocolos (Responses, Invocations e A2A) e versionamento imutável com traffic splitting para deploys blue-green e canary.

Protocolos: Responses vs. Invocations

Um mesmo hosted agent pode expor mais de um protocolo ao mesmo tempo — você escolhe pela forma como os clientes vão conversar com o agente:

• Responses (comece por aqui): endpoint /responses compatível com OpenAI. A plataforma gerencia histórico da conversa, streaming e ciclo de vida da sessão. Ideal para chatbots, RAG com ferramentas, processamento assíncrono em background e canais Teams / Microsoft 365 (ponte automática via Activity).
• Invocations: JSON arbitrário na entrada e na saída — você define o schema e gerencia as sessões. Ideal para receptores de webhook (GitHub, Stripe, Jira), classificação/extração/batch, streaming custom (AG-UI) e pontes de protocolo. Há uma variante WebSocket para voz em tempo real.

Além desses dois, o agente ainda fala Activity (Teams/M365) e A2A (agent-to-agent) — tudo no mesmo container.

Sessões, estado e identidade: o modelo de runtime

Entender o runtime é o que separa uma demo de um agente confiável em produção:

• Sessões isoladas por VM: cada sessão roda em um sandbox isolado por hipervisor, com filesystem persistente em $HOME e /files.
• Scale-to-zero com retomada: o estado é restaurado automaticamente quando a sessão reativa. O timeout de ociosidade é de 15 minutos; após 30 dias sem atividade a sessão é excluída em definitivo.
• APIs de sessão: liste e encerre sessões e faça upload/download de arquivos por sessão.
• Identidade e endpoint dedicados: criados automaticamente no deploy. Use OAuth On-Behalf-Of para fluxos disparados por usuário e managed identity para cenários autônomos; atribua RBAC à identidade do agente para alcançar seus próprios recursos do Azure.
• Histórico durável: o Conversation ID mantém o histórico no Foundry, acessível entre canais (playground, API, Teams).

Hosted agents vs. agentes por prompt: quando usar cada um

Prefira hosted agents quando você precisar de:

• Trazer o seu código: qualquer framework (Agent Framework, LangGraph, Semantic Kernel) ou lógica custom, em vez de definição só por prompt.
• Protocolos personalizados: aceitar webhooks ou payloads não-OpenAI via protocolo Invocations.
• Controle de compute: definir CPU e memória do sandbox do agente.
• Cargas com estado: persistir arquivos e contexto entre turnos via $HOME e o endpoint /files.

Se o seu caso é um assistente simples, definível por prompt e ferramentas prontas, o prompt-based agent continua sendo o caminho mais rápido.

Recursos que fazem diferença

• Isolamento VM por sessão: cada sessão roda em um sandbox isolado por hipervisor — segurança de nível enterprise, sem vazamento de estado entre sessões.
• Estado que resume sozinho: o filesystem persistente permite scale-to-zero com retomada com estado e cold starts previsíveis.
• Identidade do agente: cada agente ganha uma identidade Entra dedicada — chamadas seguras com RBAC e delegação on-behalf-of, sem segredos no código.
• Observabilidade nativa: tracing com OpenTelemetry e logs de erro em runtime com configuração mínima.
• Economia real: nada de cluster sempre ligado — você paga o compute apenas durante a execução.

Casos de uso recomendados

• Assistentes conversacionais: chatbots multi-turno e RAG com ferramentas, publicados em Teams / Microsoft 365 via Responses + Activity.
• Automação orientada a eventos: receptores de webhook para GitHub, Stripe e Jira — processe o payload nativo de cada sistema via Invocations.
• Agentes de processamento de dados: classificação, extração e jobs em batch não-conversacionais — JSON estruturado entra, JSON sai.
• Voz em tempo real: agentes de voz bidirecional sobre WebSocket (Pipecat, LiveKit, Voice Live) rodando no seu container.

Como começar: do zero ao deploy

1. Pré-requisitos: uma assinatura do Azure e um projeto no Microsoft Foundry com um modelo publicado (ex.: gpt-4o).
2. Ferramentas: Azure Developer CLI (azd) com a extensão de agentes — azd ext install azure.ai.agents.
3. Frameworks: Python 3.10+ ou .NET 10, com os pacotes de hosting agnósticos de framework.
4. Declare os protocolos no serviço azure.ai.agent do azure.yaml (ou via protocol_versions no SDK) e faça o deploy.
5. Exemplos prontos: Microsoft Agent Framework, LangGraph e código custom no repositório microsoft-foundry/foundry-samples.

Boas práticas para produção

• Comece por container: mesmo em fase de dev, empacotar cedo evita surpresas de dependência no deploy.
• Use a identidade do agente para acessar Azure OpenAI, Storage e bancos — nunca chaves fixas no código.
• Instrumente desde o início: ative o tracing OTel para conseguir depurar comportamento agêntico não-determinístico.
• Versione e faça canary: use traffic splitting para validar uma nova versão com uma fração do tráfego antes de promover.
• Governança e RAI: content filters, avaliação contínua e revisão de qualquer integração com sistemas de terceiros e seus limites de dados/compliance.
• Right-sizing por telemetria: o sandbox é dimensionado por sessão (0,5–2 vCPU / 1–4 GiB) e a cobrança soma CPU + memória das sessões ativas — se os picos passam de ~70% da alocação, aumente; se ficam bem abaixo, reduza.
• Ferramentas via Toolbox: use o Foundry Toolbox (endpoint MCP) para conectar ferramentas — a injeção direta de ferramentas no agente não é suportada.
• Dados privados: para cargas sensíveis, faça deploy em um Foundry com isolamento de rede e a sua própria VNet para o tráfego de saída.

Perguntas frequentes (FAQ)

Preciso conteinerizar meu agente?

Não — o hosted agent é entregue como imagem de container publicada no Azure Container Registry. Isso que dá liberdade de framework e controle do runtime mas agora é possível delegar para o foundry realizar o deploy do source .zip também, onde ele baixa as deps do requirements e empacota o source e faz o deploy.

Pago pelo agente mesmo quando ele está ocioso?

Pelo compute, não. Com scale-to-zero, o sandbox é desprovisionado quando fica ocioso; você paga o compute apenas durante a execução. O armazenamento persistente permanece disponível para retomar a sessão com estado.

Consigo usar LangGraph, CrewAI ou o Semantic Kernel?

Sim. Os hosted agents são agnósticos de framework: Microsoft Agent Framework, Semantic Kernel, LangGraph e código próprio em Python/C# são suportados. Você escolhe; o Foundry hospeda.

Como o agente acessa outros serviços do Azure com segurança?

Cada agente recebe uma identidade do Microsoft Entra dedicada no deploy. Com ela, você concede RBAC e usa delegação on-behalf-of — sem segredos embutidos no código.

Conclusão

Os hosted agents no Microsoft Foundry transformam o difícil “colocar em produção” em uma questão de deploy. Você mantém a liberdade de framework e a lógica do seu agente, e ganha isolamento por sessão, identidade, estado persistente, escala-a-zero e observabilidade — a plataforma que separa um protótipo de um agente de verdade rodando com segurança e escala.

Se você está desenhando agentes de IA para produção — especialmente em cenários regulados —, este é o modelo de hospedagem que vale colocar na mesa. Quer trocar ideia sobre arquitetura de agentes no Foundry? Me chama no LinkedIn.