Bem-vindos a mais uma Pila de Conhecimento. Imagine que você dirige uma empresa e contrata uma equipe de especialistas brilhantes, um planejador de viagens de classe mundial, um especialista em integração de funcionários e um profissional de suporte de TI. Mas nenhum deles se fala. Toda vez que uma tarefa precisa de dois deles, você tem que andar entre as mesas e levar a informação você mesmo. Exatamente assim que a maioria dos agentes de ar funcionam agora. Eles operam isolados, mesmo quando o problema claramente exige trabalho em equipe. Então hoje vamos falar sobre como os agentes podem se comunicar, transferir tarefas e agir como equipes reais. Eu sou o Mico Pedro. Isso não é um conceito futurista. A orquestração multiagente já está acontecendo e é impulsionada por um protocolo chamado AESA. Começaremos pelo problema, detalharemos esse protocolo peça por peça e viremos como a Microsoft o utiliza no Copilot Studio e no Azure AI.

Pegue seu café e vamos começar. Então qual é o problema real? Os agentes de A de hoje são exatamente como aqueles especialistas em isolar. Cada um tem seu próprio conhecimento, ferramentas e objetivos. Um agente de clima conhece a previsão. Um agente de hotel conhece a disponibilidade de quartos, mas eles não compartilham nada. Agora imagine um usuário pedindo uma viagem para Seattle na próxima semana com um hotel perto do escritório. Um único agente precisaria ser especialista em clima, viagens e negócios locais, tudo ao mesmo tempo. Isso significa prompt gigantes e condensam todas as capacidades possíveis em um sistema e esses prompt quebram constantemente. A solução antiga era o código personalizado. Você escreveria uma ponte entre o agente de clima e o de hotel, depois outra entre o de hotel e o de voo, e outra por de calendário e outra por de calendário. Funciona no início, mas cada vez que você adiciona um novo agente você cria outra integração.

Logo você tem um pesadelo de conexões ponto a ponto onde uma única mudança quebra tudo, os ganhos de produtividade que sua IA deveria entregar são consumidos pelo trabalho de manutenção. Vamos analisar a verdadeira de cabeça. Sua organização já possui processo com transferência de tarefa. Um ticket é criado, alguém faz a triagem, alguém resolve, alguém registra e cada passo é uma transferência. No mundo antigo, você automatiza cada passo com um agente separado e passa semanas conectando-os. Mas e se houvesse um protocolo que permitisse aos agentes descobrir uns aos outros e cooperar sem pontes personalizadas? É exatamente isso que o A2A faz. Em termos simples, o A2A é uma maneira padrão para agentes conversarem entre si, passarem tarefas e realizarem um trabalho como um time. A2A. A definição simples. A2A significa agente para agente. É um protocolo aberto que permite que agentes e IA conversem diretamente entre si, independentemente de quem os criou.

Você pode pensar nisso como um HTTP para agentes. O HTTP é a linguagem que navegadores e servidores usam para se comunicar, e o A2A faz o mesmo para agentes. Um agente criado pela sua equipe de TI no Microsoft Copilot Studio pode falar com um agente criado por outra empresa no Google Cloud, desde que ambos falem A2A. Este também não é um projeto pequeno. O A2A é patrocinado por oito grandes empresas, incluindo Google, Microsoft, Cisco, Salesforce, SAP e outras e é hospedado pela Linux Foundation. A versão 1.0 é estável e pronta para uso real, o que significa que nenhum fornecedor controla o protocolo sozinho. Não é algo do Google ou da Microsoft. É algo da indústria. O design é intencionalmente simples. O A2A baseia-se em padrões web existentes como HTTP e JSON-RPC, coisas que todo desenvolvedor já conhece. Nada é de exótico proprietário ali. Isso torna fácil para as empresas adotarem sem remover sua infraestrutura existente.

Bem, talvez você tenha ouvido falar de outro protocolo chamado MCP, o Model Context Protocol. Aqui está isso. O MCP é agente para ferramentas, significando que conecta um agente a fontes de dados externos e APIs. O A2A é agente para agente, conectando agentes diretamente uns aos outros. Eles não são concorrentes, são complementares. Pense no MCP como a conexão vertical de um agente até suas ferramentas e no A2A como a conexão horizontal entre agentes lado a lado. Mais uma escolha de design. O A2A trata os agentes como opaco. Quando um agente fala com o outro, ele não vê o raciocínio interno, as ferramentas ou os dados privados do outro agente, e só vê a tarefa que enviou e o resultado que recebe de volta. Isso preserva a privacidade e a propriedade intelectual. Um agente de clima não precisa saber como um agente de hotel reserva quartos, ele só precisa entregar a previsão. Agora, vamos olhar para a primeira peça do quebra-cabeça.

Cartão do agente. Cartão do agente, o currículo. Todo agente compatível com o A2A publica algo chamado cartão do agente. Esse cartão é um documento legível por máquina que reside em um URL padrão no domínio do agente, especificamente no caminho Well-Know Agent Card, Jason. Se você sabe onde um agente mora, pode buscar seu cartão e aprender tudo o que precisa para trabalhar com ele. Pense no cartão do agente com um currículo ou um cartão de visita. Ele diz aos outros agentes quem você é e o que você pode fazer. O cartão contém o nome do agente, uma descrição simples de suas capacidades e tags de habilidades que ajudam na descoberta. Ele também lista o URL do endpoint onde aceita as solicitações, seus requisitos de autenticação e os formatos de entrada e saída aceitos. Aqui está um exemplo concreto. Digamos que você tenha um agente especialista em... Seu cartão de agente diz possa fornecer o clima atual e uma previsão de 5 dias para qualquer cidade.

Ele lista seus endpoints de API, pois aceita o nome de uma cidade e retorna a temperatura e as condições em formato JSON. É só isso. É apenas uma declaração clara do que ele pode fazer, sem segredos ou lógica interna exposta. A descoberta funciona assim. Um agente orquestrador possui uma lista de URLs de agentes conhecidos, ou você pode configurá-lo com elas. Quando uma tarefa chega, o orquestrador busca os cartões dos agentes e lê as inscrições e decide qual agente é o mais adequado. O cartão de clima diz clima, então tarefas de clima vão pra lá. O cartão de hotel diz hotéis, então tarefas de hotel vão pra lá. Note que não é necessário um registro central. Os agentes não precisam se registrar em diretório global. Eles apenas publicam seu cartão em um local conhecido, e qualquer outro agente que saiba o URL pode encontrá-lo. Essa é uma escolha de design deliberada que mantém o sistema descentralizado e flexível.

Você pode adicionar o especialista à sua rede fornecendo o orquestrador. A descoberta acontece automaticamente, e a descoberta acontece automaticamente. Então o orquestrador sabe quem está disponível. Mas como eles realmente transferem o trabalho? Como funciona a comunicação a 2A? Portanto, o orquestrador sabe quais agentes estão disponíveis por meio do cartão de agente. Mas como esses agentes realmente transferem trabalho um pro outro? A resposta é simples. Toda comunicação ocorre via HTTP usando mensagens JSON-RPC, o mesmo protocolo que alimenta a maioria dos serviços web hoje. Nada personalizado ou complicado, apenas tráfego web padrão fluindo entre dois agentes. Aqui está o ponto. Nem todas as tarefas são iguais. O A2A suporta três padrões de interação diferentes, dependendo do que você precisa. A resposta instantânea lida com consultas rápidas, onde o agente remoto pode responder imediatamente.

Se envia uma solicitação, ele responde na hora e pronto. Pedir a previsão de hoje a um agente climático funciona exatamente assim, resposta assíncrona entra e sai, entra e sai. O streaming lida com tarefas mais longas. Talvez o agente especialista precise pesquisar vários bancos de dados ou executar uma análise complexa. Em vez de fazer você esperar por uma única resposta, o agente envia atualizações de status conforme trabalha usando eventos enviados pelo servidor. Você recebe relatórios de progresso ao longo do caminho, então o resultado final chega ao final. Rastrear a entrega de um pacote funciona maneiro. Você vê cada passo conforme ele acontece. A notificação assíncrona lida com tarefas de longa duração, onde o agente remoto pode levar minutos, horas ou até dias. A integração de novos funcionários é um bom exemplo. Um especialista provisiona contas de TI, enquanto outro cuida da inscrição em benefícios ao longo de vários dias.

O agente-cliente envia uma solicitação, recebe um ID de tarefa e continua seu trabalho. Mais tarde, o agente remoto envia o resultado por meio de um webhook. O cliente também pode verificar o progresso a qualquer momento consultando esse ID de tarefa. Toda a interação segue a minha estrutura, tudo organizado como uma tarefa. Quando o cliente envia uma solicitação, o agente remoto cria uma tarefa e retorna um ID de tarefa. Esse ID se torna um identificador de rastreamento para tudo que se segue. As mensagens dentro dessa tarefa possuem uma função indicando quem a enviou e partes que podem ser textos simples, dados binários como imagens ou documentos, payloads JSON ou URLs apontando para arquivos armazenados em outros locais. A autenticação segue convenções padrão da web, ou ALF, chave de API e token de portador. Os métodos usuais nada novo para aprender aqui. E o cartão do agente informa o cliente qual método de autenticação usar, e o cliente lida com isso da mesma forma que faria para qualquer outra chamada de API.

Veja como isso funciona na prática. Digamos que o orquestrador precise de dados meteorológicos para enviar. Ele envia uma tarefa para o especialista em clima. O especialista em clima reconhece a solicitação, inicia o processamento e transmite atualizações de progresso. Busca dados. Analisando resultados. Em seguida, ele envia a previsão final. O orquestrador nunca vê as ferramentas internas, a chave de API ou o processo de raciocínio do agente climático. Ele vê apenas o resultado. Esse é o princípio de design fundamental. Fronteiras claras entre agentes e nenhum vazamento de estado interno. Mas a comunicação entre agentes a dois ápices só no básico. Você precisa de um chefe inteligente para coordenar todos os especialistas. Isso nos leva ao padrão de orquestrador especialista. Padrão de orquestrador especialista. É aqui que tudo se conecta. O padrão de orquestrador especialista é a arquitetura mais comum em sistemas multiagentes de produção hoje.

Pense nisso como uma empresa com departamentos TI, RH, finança cada um cuidando de sua própria área. Você tem um tomador de decisão central que encaminha o trabalho para equipes especializadas e cada equipe foca no que faz de melhor. O orquestrador mantém a visão geral. Ele recebe a solicitação do usuário, descobre o que precisa ser feito e decide qual especialista pode lidar com cada parte. Se o usuário pedir, planeja uma viagem para Seattle na próxima semana. O orquestrador não reserva voos nem verifica hotéis por conta própria. Ele sabe que existe um especialista em voos, um em hotéis e um em clima. Ele divide a solicitação nessas partes e delega cada uma delas. Cada especialista tem um foco restrito. Um agente cuida da reserva de voos, outro da busca de hotéis e um terceiro da triagem incidentes. Eles não precisam os domínios uns dos outros. O especialista em voos conhece companhias aéreas, rotas e preços.

Ele não precisa saber nada sobre tipos de quarto de hotel ou políticas de cancelamento. Esse foco restrito mantém cada agente simples, fácil de manter e fácil de testar. Aqui está a parte importante. O orquestrador não executa as tarefas. Ele encaminha o trabalho e mexe com os resultados. Esse é o seu único trabalho. O papel do orquestrador é ser um despachante inteligente e não um superagente que tenta fazer tudo. Quando você deixa o orquestrador começar a fazer o trabalho de especialista, perde todo o benefício do padrão. Isso torna uma bagunça monolítica, não tá bem? Cuidado com o erro comum. Algumas equipes criam domínios de especialistas sobrepostos. Dois agentes afirmam que podem lidar com o suporte ao cliente ou consulta de dados, o que gera confusão no roteamento. O orquestrador não sabe qual escolher. Os usuários obtêm resultados inconsistentes. A solução é direta. Cada especialista possui um domínio claramente delimitado, sem sobreposição.

Se dois agentes podem fazer a mesma coisa, mescla e usa o divido do domínio de forma mais linda. O Copilot Studio da Microsoft usa esse padrão nativamente. Seu Copilot principal atua como orquestrador, enquanto agentes filhos e conectados atuam como especialistas. Quando um usuário pede algo que abrange vários domínios, o Copilot principal delega os especialistas certos, via 2A. Tá integrada a plataforma, então você não precisa programar. Lógica de orquestração do zero. O grande benefício aqui é a modularidade. Precisa trocar seu provedor de reserva de hotel? Substitua especialista em hotel sem mexer no orquestrador ou em qualquer outro agente, adicionando uma nova capacidade. Crie um novo especialista, registre-o no orquestrador e pronto. Cada agente permanece pequeno, gerenciável e implantável de forma independente. Esse é o objetivo principal de mudar de agentes monolíticos para um sistema multiagente.

Então temos o protocolo, os cartões de agente e o padrão. Vamos ver em ação os cenários reais. Exemplos reais de A2A em ação. Então, como a A2A realmente se parece no mundo real, vamos começar com exemplos simples. Se diz ao seu assistente de IA, planeje, uma viagem para Seattle na próxima semana. Na maneira antiga de fazer as coisas, aquele único assistente teria que saber tudo. Clima, voos, hotéis, restaurantes, tudo ao mesmo tempo. É muito pedir para um único prompt. Com a A2A, o orquestrador divide a tarefa. Ele envia uma tarefa para um especialista em clima perguntando a previsão para aqueles dias específicos. Ao mesmo tempo, ele pede a um especialista em voos que encontre voos com chegada na terça de manhã e retorno na quinta noite. E é um especialista em hotéis que busca locais próximos ao centro de Seattle por três noites. Cada especialista trabalha de forma independente e não precisa conversar com os outros agentes, pois cada um possui suas próprias fontes de dados, ferramentas e experiência.

O orquestrador coleta todos os resultados e os une em uma única resposta. O usuário vê uma única resposta. Aqui está a previsão. Estas são as suas opções de voo e aqui estão três hotéis perto do escritório. Nos bastidores, três agentes distintos trabalharam juntos sem qualquer código de integração personalizado. Foram sem negócio. Digamos que chegue um chamado. Meu notebook não conecta a VPN. O orquestrador identifica que se trata de um problema de rede. Ele encaminha o chamado para um especialista em runbooks que conhece os passos padrão. Verificar o status do cliente VPN, validar as credenciais de rede e iniciar o serviço. Esse especialista retorna os passos. Então o orquestrador passa o resultado para um especialista em registros chamados que documenta a resolução do sistema. Tudo isso acontece em segundos, sem intervenção humana. E a equipe de TI só é envolvida se os passos automatizados não resolverem o problema.

A integração de funcionários é outro exemplo, mas este leva dias, não segundos. O novo contratado é na empresa. O orquestrador aciona um especialista de TI para criar contas e atribuir hardware, o que pode levar algumas horas. Ao mesmo tempo, ele aciona um especialista de RH para formulários de benefícios e, depois, um especialista de instalações para acesso à mesa e crachá. Cada especialista executa sua própria tarefa de longa duração de forma independente. E o orquestrador acompanha o progresso usando aqueles IDs de tarefa mencionados anteriormente. Portanto, se o especialista de TI terminar, o orquestrador fica sabendo. E se o especialista de instalações estiver atrasado, ele pode fazer um acompanhamento. O usuário vê um fluxo de integração fluido, mas nos bastidores trata-se de uma equipe coordenada trabalhando ao longo de vários dias. E isso não é apenas teoria. A Coca-Cola Beverages África já está usando agentes do Copilot Studio com o Dynamics 365 para automatizar ciclos de planejamento.

Seus planejadores costumavam gastar até uma hora e meia por dia em tarefas repetitivas. Com a orquestração multiagente, esses ciclos rodam sozinhos. O orquestrador delega para especialistas que lidam com diferentes partes do processo de planejamento da cadeia de suprimentos. O resultado é uma economia de mais de uma hora por pessoa por dia, apenas permitindo que os agentes conversem entre si em vez de fazer com que humanos transportem informações entre sistemas. Portanto, o padrão mesmo em todos esses exemplos. Cada agente é um especialista autônomo que conhece seu próprio domínio e possui suas próprias ferramentas sem precisar saber nada sobre os outros agentes. O A2A oferece uma camada de comunicação simples para que eles possam cooperar sem código personalizado. Você obtém um protocolo padrão, um orquestrador inteligente, sem ponte, sem integrações ponto a ponto e sem dores de cabeça, com manutenção.

A Microsoft é totalmente comprometida com um ver onde o Copilot Studio e a Azure AI se encaixam. O ecossistema da Microsoft, Copilot Studio e Azure AI. Então, onde a Microsoft se posiciona em tudo isso? Bem no centro. O Copilot Studio agora suporta o A2A nativamente e está disponível ao público desde abril de 2026. Isso não é uma prévia ou versão beta. Está pronto para produção e qualquer cliente elegível pode usar hoje mesmo. Aqui está o ponto. Você pode conectar agentes externos ao seu orquestrador do Copilot Studio. Quando digo externo, quero dizer verdadeiramente externo. Agentes criados no Google Cloud, AWS ou qualquer outra plataforma que suporte o protocolo A2A. O orquestrador não se importa onde o agente reside ou com qual framework ele foi criado. Desde que ele falha A2A, ele pode entrar na equipe. A configuração é simples. No Copilot Studio você cria algo chamado agente conectado.

Você cola a URL do endpoint do agente. O Copilot Studio busca automaticamente o cartão do agente a partir dessa URL, que é o arquivo JSON bem conhecido que mencionamos. Ele lê as capacidades, os requisitos de autenticação e os formatos de entrada e saída do agente. Então, ele cria um conector personalizado nos bastidores e seu orquestrador pode começar a delegar tarefas imediatamente. Então, não precisa de trabalho de integração manual ou código personalizado. Basta colar o URL e pronto. No lado do Azure, Azure AI Foundry Agent Service também suporta o A2A. Ele possui um endpoint de API A2A dedicado que permite que orquestradores open source como AutoGen, LinkedIn e Semantic Kernel invoquem agentes do Foundry. Portanto, se você criou agentes usando esses frameworks, pode conectá-los ao ecossistema Microsoft sem reescrever nada. É uma vira em um do. A Microsoft segue o mesmo padrão de orquestrador especialista que descrevemos.

O agente principal no Copilot Studio atua como orquestrador, enquanto agentes secundários e conectados são os especialistas. Cada um lida com seu próprio domínio e o orquestrador roteia e mescla os resultados. É a mesma arquitetura, apenas rodando a plataforma da Microsoft. Mas aqui está o detalhe. Há algumas limitações que você precisa conhecer. Primeiro, cada salto extra de orquestração adiciona... Se o seu agente principal chama um agente conectado, e esse agente conectado chama outro especialista, cada salto adiciona tempo de rede. Para conversas em tempo real, muitos saltos podem tornar a experiência lenta. Segundo, o excesso de delegação cria um caos de roteamento. Se você tiver muitos especialistas com domínios sobrepostos, o orquestrador começa a tomar decisões de roteamento ruins. Portanto, mantenha o número de especialistas gerenciáveis seus domínios claramente separados. Em terceiro lugar, há uma limitação específica com os agentes de dados do FAB.

Eles não funcionam quando o agente principal é implantado no Microsoft 305 Copilot. Se sua implantação tem como alvo o M3D5 e 5 Planets de Acu. Essas restrições são reais, mas gerenciáveis. A plataforma está madura o suficiente para a produção, e a Microsoft trabalha ativamente para fechar essas lacunas. Agora vamos conectar os pontos e o panorama geral. Sessão de conexão, como tudo se encaixa. Vamos dar um passo atrás e ver como essas peças se conectam. A2A é o sistema telefônico que os agentes usam para ligar uns para os outros. Os cartões de agentes são só listas de telefone. Eles mostram quem ligar e o que cada agente trata. O orquestrador é o recepcionista que encaminha cada chamada para o departamento certo. Nenhuma dessas peças funciona sozinho. Você precisa das três. Sem uma lista telefônica, você não sabe a quem ligar. Sem um recepcionista, ninguém direciona o tráfego. E sem um sistema telefônico, um recepcionista não consegue conectar ninguém.

Ele só funciona como uma equipe. É aí que entra a modularidade. Quando seus especialistas são modulares, você pode adicionar novos recursos sem quebrar o que já funciona. Digamos que você queira adicionar um especialista em aluguel de carros ao seu assistente de viagem, você o cria, publica seu cartão de agente, fornece o cartão de agente e fornece o orquestrador. O especialista em voos e o especialista em hotéis permanece exatamente igual. O orquestrador também não muda. Ele simplesmente conecta uma nova peça e o sistema se adapta. Como o protocolo é aberto, você nunca fica preso a um único fornecedor. Seu orquestrador pode rodar no Copilot Studio. Seu agente de clima pode viver no Google Cloud. Seu agente de hotel pode estar na AWS. Seus sistemas internos podem permanecer no Azure. Todos eles falam a mesma língua. Essa é a beleza de um padrão aberto. Ele evita a dependência de fornecedor e permite escolher a melhor ferramenta para cada um.

A 2A não é sobre construir um agente super inteligente que sabe tudo. É sobre construir uma força de trabalho flexível de especialistas que você pode reorganizar conforme suas necessidades. Você não substitui seus agentes, você os reorganiza. Você adiciona novos. Você troca os antigos. O sistema cresce com você, em vez de se tornar um gargalo. Então o que você pode fazer com esse conhecimento hoje? Missões práticas. Um SPQ. Escolha um processo repetitivo em sua organização que envolva múltiplos sistemas. Resolução de tickets, integração de funcionários ou relatórios de despesas, por exemplo. Algo com transferências claras entre as etapas. Então, construa um protótipo com um orquestrador e dois especialistas. Você não precisa de uma grande arquitetura. Você só precisa de um exemplo funcional do qual possa aprender. Use as ferramentas que já oferecem suporte a isso. O Cupboard Studio tem suporte A2A integrado e o Azure AI Foundry também.

Você não precisa criar o protocolo do zero ou escrever códigos de integração personalizados. Cole uma URL e configure seus agentes e comece a delegar. Fique atento às armas de escuta. Evite que as especialidades dos seus agentes se sobreponham. Se dois agentes fazem a mesma coisa, mescre o uso ou divida o domínio com mais clareza. Deixe o orquestrador cuidar do roteamento, não da execução. E fique atento à latência causada pelo salto de orquestração. Se o tempo de resposta começar a subir, talvez você tenha camadas demais de delegação. O melhor primeiro passo é simples. Mapeie as transferências no seu fluxo de trabalho atual. Onde as informações são passadas entre pessoas ou entre sistemas. Esses são os pontos onde os agentes podem assumir o controle. Cada transferência é uma oportunidade. Esse é o sistema A2A, em poucas palavras. Três peças simples trabalhando juntas. Os agentes deixam de ser isolados e começam a atuar como uma equipe real.

Escolha um fluxo de trabalho com transferências claras e comece por lá. Inscreva-se para mais explicações simples e deixe um comentário se algo fez sentido.