ari20089/limites-de-transferencia-entre-agentes-conectados

Limites de Transferência entre Agentes Conectados

A orientação da Microsoft para transferência no Microsoft Copilot Studio está espalhada por três páginas: delegação agente-para-agente, transferência para um agente ao vivo e transferência do agente de Auto-Atendimento do Funcionário. Uma quarta página define os níveis de decisão para as ações de um agente. Nenhuma página diz quem pode delegar qual tipo de ação para qual tipo de agente, ou afirma em um único lugar o que sobrevive à transferência. Este skill transforma a mecânica documentada em um padrão de limite de decisão por tipo de ação. É consultivo: nunca altere agentes, configurações, políticas ou credenciais.

Antes de Começar

Determine o seguinte antes de prosseguir. Se o usuário não os forneceu, peça os que faltam.

1. Plataforma ou produto — padrão, Microsoft Copilot (antigo GitHub Copilot) ou plataforma Conversa com Cliente no Copilot Studio, ou o agente de Auto-Atendimento do Funcionário no Microsoft Copilot. O comportamento difere por plataforma (veja Etapa 1); se o usuário não souber, pergunte como o agente foi criado e diga qual você assumiu.
2. Delegados — todo agente ou pessoa para quem o design transfere, e como: agente filho, agente Copilot Studio conectado, agente externo (A2A, Foundry, SDK de Agentes, agente de dados do Fabric, agente de loja de terceiros), agente ao vivo através de um hub de engajamento ou redirecionamento de tópico.
3. Inventário de ações — as ferramentas, fluxos e tópicos que cada agente pode acessar, com a autenticação de cada ferramenta (do usuário final ou fornecida pelo criador) e se a opção Perguntar ao usuário final antes de executar está ativada. Se for desconhecido, classifique a partir dos nomes das ferramentas e marque a classificação como provisória.
4. Delegadores — se o pai é acessado por usuários no chat, por um evento ou gatilho agendado, ou ambos.
5. Artefato desejado — matriz de limites (padrão), blocos de instrução, contrato de transferência, lista de verificação de revisão, plano de teste de locatário ou uma revisão de design do conjunto completo.
6. Data da documentação — se você tiver acesso à web, verifique novamente as páginas do Microsoft Learn na lista de Fontes do guia, compare o ms.date de cada página com a data listada e diga o que mudou. Caso contrário, diga que você está confiando nas datas dessa lista (última releitura em 5 de novembro de 2026).
7. Observações do locatário — quaisquer resultados que o usuário já tenha dos testes T1 a T10. Relate-os como observado no locatário, separados de documentado e não documentado, com o tipo de locatário e a data.

Estrutura de Saída

Produza, nesta ordem:

1. Mapa de transferência — uma linha por delegado: delegador, mecanismo, plataforma, delegado.
2. Fatos documentados que se aplicam — marcadores com a página do Microsoft Learn e sua data, usando a redação do guia, cobrindo o que cada mecanismo passa, o que retorna e as configurações que alteram qualquer um deles.
3. Observado no locatário — apenas se o usuário forneceu resultados; caso contrário, omita o título.
4. Matriz de limites — a tabela da seção 6.4 do guia, uma linha por delegado, com o tipo de ação mais alto (A1 a A6) e cada célula preenchida ou marcada como desconhecido.
5. Violações de limites — cada lugar onde o design quebra uma das sete regras na seção 6.3, com o número da regra e a correção.
6. Perguntas em aberto que se aplicam — as linhas relevantes de Q1 a Q10.
7. Suposições — uma linha listando os padrões que você aplicou (plataforma, classificação, artefato, data). Omita se o usuário forneceu tudo.
8. O artefato solicitado — construído a partir da seção correspondente do guia (Etapa 5).
9. Recomendação — uma posição clara sobre se o design está pronto e as condições que devem ser atendidas primeiro.
10. Fontes e datas — uma linha nomeando as páginas utilizadas e suas datas, além do status de visualização dos mecanismos em uso.

Use tabelas para o mapa, matriz e plano de teste, listas numeradas para listas de verificação e blocos de código cercados para qualquer texto de instrução ou descrição que o usuário colará no Copilot Studio.

Etapa 1: Identificar a plataforma e os mecanismos

Leia as seções 1 e 2 de references/handoff-guide.md. Primeiro, resolva a plataforma: a mesma palavra significa coisas diferentes.

O usuário diz	Significa em	Cuidado com
"Agente filho"	Plataforma padrão	Sempre recebe o contexto do pai; nenhuma configuração para excluí-lo
"Subagente"	Plataforma Conversa com Cliente (ou, vagamente, qualquer subagente)	Compartilha configuração, implantação e ALM com o agente primário
"Agente conectado"	Qualquer plataforma	Padrão: alternância de histórico, mesmo ambiente, um nível. Plataforma Microsoft Copilot: o pai é o único comunicador; nenhuma configuração de histórico nomeada (Q3). Conversa com Cliente: apenas agentes Microsoft Foundry.
"Agente A2A", "Agente Foundry"	Plataforma padrão ou Microsoft Copilot	Externo: a Microsoft coloca a responsabilidade pelos fluxos de dados e aprovações no criador
"Transferir para um humano", "escalar"	Plataforma padrão ou caminhos de escalada Conversa com Cliente	Padrão: histórico completo e todas as variáveis de tópico definidas pelo usuário vão para o hub. Conversa com Cliente: carga útil não documentada.
"Transferência de agente", "agente hub"	Agente de Auto-Atendimento do Funcionário no Microsoft Copilot	A transferência passa o histórico e o prompt original, pode cruzar ambientes e pode atingir agentes de terceiros

Se o usuário misturar plataformas em um único design, trate cada aresta de delegação separadamente.

Etapa 2: Estabelecer o que cruza cada transferência

Para cada delegado, declare a partir da seção 3 do guia o que ele recebe, o que retorna e o que é perdido: solicitações reformuladas, citações, mensagens próprias de um subagente, ações do Adaptive Card e acesso. Use a redação da Microsoft. Onde o guia disser não documentado, diga isso; não preencha a lacuna com base em como outra plataforma se comporta.

Etapa 3: Classificar ações e definir o nível onde elas executam

Classifique cada delegado pelo tipo de ação mais alto entre as ferramentas que ele pode acessar (seção 6.1 do guia, A1 a A6). Mapeie cada tipo para os três níveis da Microsoft (seção 5 do guia): sem confirmação, confirmação na conversa, aprovação offline. O nível pertence ao agente que possui a ferramenta. Leia a seção 4 do guia para saber onde a confirmação e as credenciais são definidas, e sinalize cada ferramenta delegada em A2 a A5 que usa credenciais fornecidas pelo criador. Conte ferramentas de servidor MCP como ferramentas.

Etapa 4: Verificar quem pode delegar o quê para quem

Aplique a seção 6.2 do guia (a tabela de delegação e a regra do delegador autônomo) e as sete regras na seção 6.3. Liste cada violação com seu número de regra e uma correção concreta em termos do Copilot Studio, nomeando a configuração, nó ou entrada.

Etapa 5: Construir o artefato

Artefato	Seção do guia	Conteúdo
Matriz de limites	6.4	Uma linha por delegado, cada coluna preenchida ou desconhecido
Blocos de instrução	7	Blocos pai, subagente e descrição, nomes adaptados, linhas da Microsoft mantidas textualmente, linhas de limite marcadas
Contrato de transferência	8	Entradas e saídas por delegado, com descrições escritas para o orquestrador
Lista de verificação de revisão	11	As dez verificações, cada uma marcada como aprovada, reprovada ou desconhecida para este design
Plano de teste de locatário	10	Os testes que se aplicam às plataformas e delegados do usuário; remova os testes já executados e incorpore seus resultados em Observado no locatário
Revisão de design	6.4, 6.3, 11	Matriz, violações, lista de verificação e recomendação juntos

Cada artefato carrega a data da documentação e o status de visualização dos mecanismos que cobre.

Etapa 6: Recomendar, depois parar

Dê uma posição clara: pronto, pronto com correções listadas ou não pronto. Um design não está pronto se qualquer ação A5 for acessível por roteamento generativo, se qualquer ferramenta delegada A2 a A5 usar credenciais fornecidas pelo criador sem uma exceção registrada (um delegador autônomo sempre precisa de uma, porque os gatilhos são executados com as credenciais do criador; seções 4 e 6.2 do guia), ou se um delegado externo receber histórico de chat sem uma decisão registrada de compartilhamento de dados. Não se ofereça para alterar os agentes.

Regras

• Nunca afirme que a confirmação, credenciais ou política de dados de um pai se aplicam às ferramentas de um delegado. A Microsoft documenta estes por ferramenta, no agente que possui a ferramenta.
• Nunca afirme que um agente conectado recebe apenas a tarefa, a menos que o usuário tenha confirmado que a opção Passar histórico da conversa para este agente está desmarcada em um agente de plataforma padrão. Os padrões passam o histórico.
• Nunca nomeie uma configuração de histórico, uma profundidade de delegação, um bloqueio de administrador para conexões de agente ou um passe-through de token de usuário onde o guia diz não documentado. Responda "não documentado a partir de " e nomeie o teste que o estabeleceria. Também não negue um: as FAQ dizem que você "pode configurar se o histórico completo da conversa é passado" para agentes externos, embora nenhuma página nomeie a configuração (guia Q3; teste T6).
• Nunca apresente os tipos de ação, tabela de delegação, sete regras, saída actionsTaken ou linhas de instrução de limite como orientação da Microsoft. Eles são o padrão deste skill sobre os fatos da Microsoft; rotule-os.
• Sempre mantenha três classes de fato separadas: documentado (página e data), observado no locatário (teste de quem, quando) e não documentado.
• Sempre cite a redação da Microsoft do guia ou de uma busca ao vivo da página citada, não da memória.
• Sempre resolva o conflito do "único agente que fala com o usuário" (Q6) a favor da página do subagente, à qual a página de padrões agora se refere: instrua o subagente a permanecer em silêncio; não confie em uma instrução apenas do pai.
• Sempre use os nomes atuais da Microsoft: plataforma padrão; plataforma Microsoft Copilot (renomeada da plataforma GitHub Copilot em 28 de outubro de 2026; Learn e o produto ainda podem mostrar o nome antigo; mantenha o nome antigo em títulos e citações de páginas do Learn; "um framework de criação e orquestração do Microsoft Copilot Studio, não o serviço GitHub Copilot"; uma plataforma do Copilot Studio, não o produto Microsoft Copilot); plataforma Conversa com Cliente, cujos especialistas são subagentes; Microsoft Foundry (não Azure AI Foundry); Agent2Agent (A2A); Microsoft 365 Agents SDK; hub de engajamento; e, para o agente de Auto-Atendimento do Funcionário, Microsoft Copilot e Copilot Chat como suas páginas dizem.
• Sempre mantenha nomes de locatário, agente, usuário e cliente que o usuário compartilha fora de exemplos reutilizáveis e blocos prontos para colar.
• Se o design não tiver delegação, diga que este skill é a ferramenta errada e aponte para os níveis da seção 5 do guia para um único agente.

Exemplos

Entrada: "Nosso agente de helpdesk de TI (plataforma padrão) roteia para um agente conectado de Facilities no mesmo ambiente e para um agente A2A de um fornecedor que pode cancelar pedidos de hardware. Os usuários conversam com ele no Microsoft Teams. De quais limites precisamos?"

Saída (resumida):

Mapa de transferência: Helpdesk → Facilities (agente Copilot Studio conectado, padrão); Helpdesk → Pedidos do fornecedor (A2A, padrão). Fatos documentados: Facilities recebe o histórico da conversa, a menos que Passar histórico da conversa para este agente esteja desmarcado; ele "está habilitado por padrão" (Projetar subagentes, 4 nov. 2026). A carga útil de exemplo do A2A carrega "Histórico completo do chat, não apenas a última fala do usuário" (A2A, 26 ago. 2026). Para agentes externos, "você é responsável pelo uso de tais agentes" (mesma página). A confirmação é por ferramenta: Perguntar ao usuário final antes de executar "está definido como Não por padrão" (Adicionar ferramentas, 1 out. 2026). Matriz de limites: Facilities, A3 (rascunha ordens de serviço), roteamento generativo, histórico ativado (motivo desconhecido), credenciais do usuário final, sem confirmação, sem saídas: falha na regra 4. Pedidos do fornecedor, A5 (cancela pedidos), roteamento generativo, histórico completo do chat, conexão OAuth 2.0, sem confirmação: falha nas regras 1, 3 e 5. Violações e correções:

• Regra 5: remova o agente do fornecedor do roteamento generativo. Acesse-o apenas através de um tópico "Cancelar pedido" com um nó de confirmação e um redirecionamento, passando um scopedRequest que contenha apenas o número do pedido.
• Regra 3: registre uma decisão de compartilhamento de dados com o fornecedor que cubra o histórico do chat, ou não conecte o agente.
• Regra 4: adicione as saídas answered, findings, openQuestions e actionsTaken ao Facilities e desmarque a alternância de histórico. Perguntas em aberto: Q1, Q4, Q5. Recomendação: não pronto. Lance o Facilities após a correção da regra 4; segure a conexão do fornecedor até que o tópico de redirecionamento exista e a decisão de compartilhamento de dados esteja assinada. Fontes e datas: Padrões multi-agente (4 nov. 2026); Conectar a um agente Copilot Studio existente (30 out. 2026); A2A (26 ago. 2026); Projetar subagentes (4 nov. 2026); Adicionar ferramentas (1 out. 2026). "Adicionar outros agentes" da plataforma padrão é documentação em visualização.

Referências

• references/handoff-guide.md — onde a orientação da Microsoft está (seção 1); mecanismos por plataforma (2); o que cruza cada transferência, textualmente (3); onde credenciais e confirmação são definidas (4); níveis de decisão da Microsoft (5); padrão de limites deste skill: tipos de ação, tabela de delegação, sete regras, modelo de matriz (6); blocos de instrução prontos para colar (7); contrato de transferência (8); perguntas em aberto Q1 a Q10 (9); testes de locatário T1 a T10 (10); lista de verificação de revisão (11); o que observar (12); todas as fontes com datas. Leia antes de responder; leia a seção nomeada na Etapa 5 antes de construir um artefato.