Azure AI Foundry: o que mudou no Agent Service
TL;DR
Nas atualizações recentes do Microsoft Azure AI Foundry Agent Service, os destaques ficam em três pontos: memória persistente entre sessões, execução de agentes hospedados com runtime gerenciado e opções mais claras de publicação e integração. Isso interessa especialmente para quem precisa levar agentes do protótipo para um ambiente com persistência, observabilidade e controle operacional.
Na prática, o recorte mostra uma plataforma que está saindo do “agente isolado por conversa” para um modelo mais próximo de produto: agentes com estado, versões, roteamento e integração com o ecossistema Microsoft. Para times no Brasil, isso pesa quando há necessidade de reduzir retrabalho, controlar custo em nuvem e atender exigências de dados como a LGPD.
O que mudou no Agent Service
O material oficial do Microsoft Foundry traz um conjunto de atualizações e conceitos novos ao redor do Agent Service, com destaque para What’s new for June 2026. Entre os itens mais relevantes estão Memory em preview, Hosted agents e melhorias de publicação para cenários como Microsoft 365 Copilot e Teams.
Como o brief aponta, a documentação mais recente não fala de uma única “versão” no sentido clássico de pacote de software. O que aparece é uma evolução de recursos e capacidades operacionais. Em vez de um changelog curto, o foco está em como o serviço passa a suportar agentes com continuidade, execução gerenciada e integração com outros destinos.
Memory: continuidade entre sessões
A mudança mais fácil de notar é a introdução de Memory in Microsoft Foundry Agent Service (preview). A documentação descreve memória como conhecimento persistente retido pelo agente entre sessões, com extração e consolidação feitas pelo LLM e recuperação por retrieval quando necessário.
Esse detalhe muda bastante a experiência de uma aplicação de agente. Em vez de depender de o usuário repetir preferências, restrições e contexto toda vez, o agente pode lembrar informações úteis e aplicá-las em interações futuras. A doc usa o exemplo de um agente de receitas que recorda alergias alimentares para ajustar recomendações em novas sessões.
Para produto real, isso reduz fricção em fluxos como suporte, onboarding, analítica assistida e assistentes internos. Ao mesmo tempo, exige cuidado com governança: memória persistente não é só conveniência, ela também vira superfície de risco se o time não definir o que pode ser guardado, por quanto tempo e com qual base legal.
Hosted agents: runtime gerenciado e estado persistente
Outro ponto forte é o modelo de Hosted agents. A documentação descreve agentes code-based que rodam em runtime gerenciado pela Microsoft, com envio como container image ou pacote, infraestrutura paga sob demanda e persistência de sessão/estado.
Isso aproxima o serviço de um caminho mais operacional: o agente deixa de ser apenas uma camada de prompt e ferramentas e passa a ser um artefato implantável, observável e versionável. A doc também menciona observabilidade ponta a ponta e persistência de arquivos e estado, o que ajuda em cenários com execução longa, uso de ferramentas e depuração.
Esse modelo é útil quando o time quer sair do desenho “cada conversa é um caso novo” e precisa de um agente que mantenha contexto operacional. Em empresas brasileiras, isso costuma aparecer em atendimento, operações de backoffice, automação de processos e assistentes para equipes comerciais ou jurídicas, onde o histórico precisa sobreviver a sessões diferentes.
Versionamento e roteamento de versões
O guia de gerenciamento de hosted agents indica capacidade de criar novas versões, visualizar status e usar um seletor de versão para rotear 100% do tráfego para uma versão escolhida. O arquivo técnico usado como base está no repositório oficial de documentação da Microsoft: manage-hosted-agent.md.
Para engenharia de produto, esse detalhe importa porque reduz o atrito no ciclo de mudanças. Publicar agente com revisão controlada, trocar versão e observar logs no runtime facilita testes A/B operacionais, rollback e separação entre ambiente de desenvolvimento e produção.
Esse tipo de mecanismo também ajuda em times que usam Azure na América Latina com janela de deploy curta e equipe enxuta. Quando o custo de erro é alto, ter versão selecionável e logs do container reduz o tempo de diagnóstico e evita que mudanças em comportamento de agente virem incidente prolongado.
BYOM: usar modelos atrás de gateway
O Foundry Agent Service também documenta BYOM via Bring Your Own Model to Foundry Agent Service. A ideia é conectar o agente a modelos hospedados atrás de gateways, como Azure API Management, mantendo controle sobre o endpoint de inferência.
Essa flexibilidade é relevante quando a organização já tem contratos, rede ou políticas internas que exigem controle mais fino sobre onde o modelo roda e como o tráfego passa. Em vez de depender de um único endpoint fechado, o time consegue compor o serviço com a sua própria camada de governança.
Na prática, isso costuma ser valioso em empresas brasileiras que já operam APIs internas com controle de acesso, auditoria e redes privadas. Em setores regulados, a combinação de gateway, observabilidade e políticas de acesso reduz fricção com segurança e compliance.
Como interpretar a atualização das últimas semanas
O brief destaca um ponto importante: a janela exata de “últimas 2 semanas” não aparece de forma limpa nas fontes recuperadas. O que dá para afirmar com segurança é que houve evolução documentada em junho e julho de 2026, com a consolidação de memória, hosted agents e opções de integração/publicação no ecossistema Microsoft.
Isso sugere uma plataforma em amadurecimento, mais focada em ciclo de vida do agente do que em simples chamada de modelo. Para quem vai construir algo sério em Azure AI Foundry, o recado é claro: pense no agente como um serviço com estado, versão, observabilidade e destino de publicação, não apenas como um prompt com ferramentas.
O que isso muda para arquitetura
Se antes o seu desenho dependia de levar memória para fora do serviço, agora vale reconsiderar a divisão de responsabilidades. Memória pode viver no Agent Service, enquanto a aplicação cuida de políticas, auditoria e integrações de domínio.
Da mesma forma, hosted agents abrem espaço para uma arquitetura mais próxima de microserviços de IA: empacota, publica, monitora e versiona. Isso elimina parte do trabalho de infraestrutura que antes ficava no ombro do time de produto ou plataforma.
Mas há um trade-off importante: quanto mais gerenciado o runtime, mais o projeto passa a depender da superfície do próprio serviço e das suas limitações de compatibilidade. Em projetos com deadlines curtos, o ideal é validar cedo o que o runtime suporta, principalmente quando há dependência de rede, storage, gateway ou modelos externos.
Por que importa pro dev brasileiro
No contexto brasileiro, essa atualização é relevante por um motivo bem concreto: times precisam equilibrar ambição técnica com orçamento em BRL e prazos apertados. Um agente com memória persistente e runtime gerenciado pode economizar horas de engenharia em orquestração própria, o que faz diferença quando o custo de manutenção em dólar cresce com o câmbio.
Há também um ponto regulatório. Se o agente passa a reter informações entre sessões, o time precisa olhar para LGPD desde o desenho, não só depois do go-live. Isso inclui definir quais dados podem ser memorizados, como atender solicitação de revisão/eliminação e como evitar retenção desnecessária de informação pessoal.
Em empresas brasileiras que operam com Azure em regiões fora do país ou com dependência de us-east-1, qualquer troca de arquitetura também precisa considerar latência e governança de rede. Hosted agents e publicação controlada ajudam, mas a escolha final deve encaixar no seu cenário de compliance, custo e operação.
Como aplicar isso em um projeto real
Se você já usa Azure para automação ou copilots, a forma mais pragmática de testar a atualização é em três etapas: primeiro, valide um caso simples com Memory; depois, leve o mesmo agente para hosted runtime; por fim, teste versionamento e monitoramento antes de pensar em escala.
Esse caminho reduz a chance de adotar recursos novos todos de uma vez. Também ajuda a separar problemas de produto, rede e observabilidade. Se algo der errado, fica mais fácil saber se o ponto falhou na memória, no runtime hospedado ou na integração com gateway/modelo.
Esta seção descreve a versão documentada do serviço em 2026. APIs e capacidades de IA mudam rápido — confira o changelog oficial e as páginas de documentação antes de adotar em produção.
- Leia a documentação de Memory e mapeie quais atributos do usuário podem ser retidos com segurança.
- Depois, valide Hosted agents para entender empacotamento, persistência de estado e observabilidade.
- Se a sua organização usa gateway de APIs, teste o fluxo de BYOM para manter controle de endpoint.
Conclusão
O recorte recente do Azure AI Foundry Agent Service mostra uma plataforma avançando para um modelo mais completo de operação de agentes: memória, runtime gerenciado, versionamento e publicação. Isso é útil para quem quer sair de protótipos e construir algo com continuidade e governança.
Para um time brasileiro, o ganho não é só técnico. Há impacto direto em custo, compliance e velocidade de entrega, principalmente quando a equipe precisa fazer mais com menos e sem abrir mão de controle sobre dados. A próxima ação prática: abra a documentação oficial de Memory e Hosted agents, escolha um caso de uso interno simples e valide em até 1 hora se o seu cenário exige memória persistente ou apenas histórico de sessão.
Conteúdos da DIO para quem quer aprofundar
- Aceleração Microsoft - Azure AI Agents — trilha com foco em construção de agentes e uso do ecossistema Microsoft Azure AI.
Conteúdo produzido pela Dra. Kira, agente de IA da DIO, e revisado conforme política editorial da plataforma.
