TL;DR: O artigo analisa os novos recursos de distribuição de agentes no Microsoft Foundry: publicação em Teams/Copilot, agentes autopilot com identidade própria e protocolo A2A. A conclusão é que a barreira não é mais construir agentes, mas governá-los e integrá-los aos fluxos de trabalho existentes. Para empresas brasileiras, isso significa repensar governança, identidade e operação de agentes em escala corporativa.
O último ano foi marcado pela experimentação e construção de agentes de IA. O próximo, no entanto, será sobre colocá-los para trabalhar de verdade. A Microsoft Foundry anuncia três movimentos que fecham a última milha entre o desenvolvimento e a operação corporativa: publicação nativa no Microsoft 365 Copilot e Teams (disponível no próximo mês), agentes autopilot (em preview público) e o protocolo Agent to Agent (A2A) (também em preview). Se você é responsável por infraestrutura cloud, DevOps ou governança de IA no Brasil, precisa entender o que muda.
Por que a distribuição de agentes é o novo gargalo?
Organizações já superaram a fase de provas de conceito e começam a rodar agentes que executam processos de negócio complexos e tarefas de longa duração. O gargalo mudou: não é mais a capacidade de construir — é a de colocar esses agentes nas mãos dos colaboradores dentro das ferramentas que eles já usam, com governança em escala.
Publicação no Microsoft 365 Copilot e Teams: mais que um chatbot
No Foundry, qualquer agente pode ser publicado em poucos cliques diretamente no Microsoft 365 Copilot e no Teams, sem a necessidade de recriar a experiência para cada superfície. Os agentes mantêm as mesmas capacidades que tinham em desenvolvimento e passam por um pipeline de publicação consistente e governado até ficarem disponíveis para toda a organização.
O modelo de interação proposto não é o tradicional "prompt → resposta", mas sim um modelo de delegação: Goal → Ongoing execution → Checkpoints → Collaboration. Em vez de fazer perguntas, o colaborador atribui um objetivo ao agente, que executa de forma contínua, reporta progresso, solicita aprovações e aciona humanos quando necessário — tudo dentro do Teams e do M365.
Agentes autopilot: identidade própria e atuação em equipe
A grande novidade é a categoria de autopilot agents (preview). Eles operam de forma autônoma com identidade própria — possuem conta de usuário com licença de produtividade, e-mail, calendário, OneDrive, acesso ao Teams e um lugar no organograma da empresa. Eles não servem apenas a um usuário individual: podem participar de grupos, reuniões, canais e assumir responsabilidades contínuas.
A Microsoft disponibilizou um exemplo prático: o Workstream Manager, um agente autopilot projetado para viver em chats de grupo do Teams. Ele extrai conhecimento do histórico de conversas, arquivos, links, PRs do GitHub e atas de reuniões, e é capaz de rastrear tarefas e prazos, resumir conversas em action items, cobrar atividades atrasadas, sinalizar riscos e coordenar atualizações entre stakeholders.
O agente inclui fluxos de onboarding gerenciados pelo manager, controle de acesso granular (quem pode interagir), rastreamento de compromissos com marcadores visuais, resumos sob demanda, Q&A sobre o workstream e integração com ferramentas Microsoft 365 como Word, Excel, Outlook e SharePoint. Em chats de grupo, ele responde apenas quando mencionado, evitando poluição visual.
Agent to Agent (A2A): a comunicação entre agentes
Distribuição não é só sobre levar agentes até as pessoas — é também sobre agentes se comunicarem entre si. O Foundry já permitia que agentes chamassem outros agentes remotos via A2A como uma ferramenta. Agora, com o preview de incoming A2A, qualquer agente Foundry pode ser exposto como um endpoint A2A, e outros agentes o descobrem através de seu agent card e o invocam via protocolo aberto, independente de framework ou cloud.
Isso significa que um agente pode delegar parte de uma tarefa a outro agente da mesma forma que chamaria qualquer outra ferramenta — e ser chamado de volta. Construído sobre um padrão aberto, o A2A permite interoperabilidade entre fornecedores, mantendo a autenticação via Microsoft Entra ID e sem acesso anônimo.
Governança desde o desenvolvimento
Cada agente Foundry recebe uma identidade Entra própria, governada com os mesmos controles aplicados a usuários, aplicativos e dispositivos. Ao ser criado, o agente é automaticamente registrado no Microsoft Agent 365, dando ao TI um painel único para ver, aprovar e gerenciar todos os agentes da organização.
A governança começa no desenvolvimento, não na implantação. Quando o agente está pronto para publicar, os administradores podem revisar e aprovar acessos, controlar quem pode descobri-lo e usá-lo, e gerenciá-lo lado a lado com todos os outros agentes. Isso vale tanto para agentes padrão quanto para autopilot agents — todos passam pelo mesmo pipeline governado.
Impactos para empresas brasileiras
Para times de engenharia e gestores de TI no Brasil, o anúncio reforça que a adoção de agentes de IA não é apenas uma questão de desenvolvimento, mas de operação e governança em escala. Publicar agentes nas ferramentas do dia a dia (Teams, Copilot) reduz o atrito de adoção, mas exige que a empresa tenha maturidade em identidade e controle de acesso (Entra ID, políticas de administrador).
Agentes autopilot com identidade própria levantam questões de segurança e compliance: como auditar ações de um agente? Como garantir que ele não acesse dados sensíveis? O modelo de governança do Foundry — com registro centralizado e approval pipeline — é um passo, mas a responsabilidade final é da organização.
O protocolo A2A abre caminho para ecossistemas multi-cloud e heterogêneos, permitindo que agentes construídos em diferentes plataformas colaborem. Para empresas que já operam em múltiplas nuvens (AWS, Azure, GCP), isso pode simplificar a orquestração de workflows, desde que os controles de segurança sejam mantidos.
Como começar?
- Publique seus agentes no Microsoft 365 e Teams seguindo a documentação oficial.
- Habilite incoming A2A no seu agente Foundry para permitir comunicação entre agentes.
- Crie seu primeiro autopilot agent a partir dos code samples disponibilizados.
Perguntas Frequentes
-
Como funciona a governança de agentes no Microsoft Foundry?
Cada agente recebe uma identidade Entra própria desde a criação, registrada automaticamente no Microsoft Agent 365. O administrador pode revisar e aprovar acesso, controlar descoberta e uso, e aplicar as mesmas políticas de governança usadas para usuários, aplicativos e dispositivos. -
Os agentes autopilot têm identidade própria? Quais são as implicações de segurança?
Sim, eles recebem uma conta de usuário com licença de produtividade, incluindo e-mail, calendário, OneDrive e acesso ao Teams. Isso significa que precisam ser gerenciados como qualquer outro colaborador, com políticas de acesso, monitoramento e auditoria aplicáveis. -
O protocolo A2A é aberto? Como ele se integra com outros provedores de nuvem?
Sim, o A2A é um protocolo aberto. Qualquer agente Foundry pode ser exposto como endpoint A2A e descoberto por outros agentes via agent card, independentemente do framework ou nuvem. A autenticação é feita com Microsoft Entra ID, garantindo que nenhum acesso anônimo seja permitido. -
Quais são os requisitos de licenciamento para publicar agentes no Teams e Copilot?
O artigo informa que a publicação estará disponível no próximo mês (GA). Para ambientes corporativos, é necessário ter licenças do Microsoft 365 Copilot e do Teams, além da plataforma Foundry. A Microsoft não detalha custos adicionais, mas a integração exige o ecossistema M365.
Artigo originalmente publicado por Amanda Foster em Azure Updates - Latest from Azure Charts.
