O agente de pesquisa encontrou a conta do cliente, confirmou o plano e puxou as últimas quatro faturas. Ele entregou ao agente de cobrança com um resumo de uma linha: "O cliente quer um reembolso." O agente de cobrança, que agora não sabe nada sobre a conta, o plano ou as faturas, começa perguntando pelo ID da conta.
Cada fato que o primeiro agente coletou foi descartado na fronteira. Esse é o problema da entrega de informações (handoff), e ele custa o dobro: uma vez nas chamadas de API duplicadas, outra vez nos erros que surgem do segundo agente trabalhando com menos informações do que o primeiro.
Este guia aborda o que precisa sobreviver a uma entrega de informações, as três maneiras como as equipes passam o estado e quando cada uma funciona, por que os resumos perdem mais do que as pessoas esperam e como testar se uma entrega de informações carregou o que afirmava. Nossa publicação sobre por que os agentes falham em produção trata o estado perdido como um modo de falha central; esta é a versão multiagente disso.
Apidog aparece porque a solução mais barata geralmente é parar de passar dados e passar identificadores, o que só funciona se cada agente puder buscar o mesmo registro da mesma maneira.
O que realmente precisa cruzar a fronteira
Nem tudo. Uma entrega de informações que copia a conversa inteira é tão falha quanto uma que não copia nada, apenas na direção oposta: o segundo agente herda uma janela de contexto completa e precisa descobrir quais partes importam.
Quatro categorias merecem ser separadas.
Identificadores. IDs de conta, IDs de pedido, IDs de trabalho, números de ticket. Estes são pequenos, estáveis e permitem que o agente receptor busque o que precisar. São a coisa mais valiosa a ser passada e a mais comumente descartada.
Decisões já tomadas. "O cliente é elegível para um reembolso sob a política 3." O agente receptor não deve reabrir esta questão. Se o fizer, você terá dois agentes discordando dentro de uma única tarefa.
Restrições. Limites de orçamento, aprovações concedidas, ações já realizadas. Perder isso é como uma tarefa acaba cobrando duas vezes ou pedindo a mesma aprovação uma segunda vez. Isso se conecta diretamente com nossa publicação sobre idempotência para agentes de IA.
Perguntas em aberto. O que o primeiro agente não conseguiu resolver. Passar isso explicitamente impede que o segundo agente assuma silenciosamente.
O que não precisa cruzar: respostas brutas da API, a transcrição do raciocínio e qualquer coisa que o agente receptor possa buscar por conta própria em uma única chamada.
Três maneiras de passar o estado
Passar a conversa inteira. Simples, e funciona para dois agentes em uma tarefa curta. Falha assim que a transcrição é longa, porque o agente receptor gasta a maior parte do seu orçamento lendo o histórico e os fatos relevantes ficam enterrados no meio. Nossa publicação sobre manter as respostas das ferramentas fora da janela de contexto explica por que esse meio é exatamente onde os modelos perdem informações.
Passar um resumo. O primeiro agente escreve uma mensagem de entrega; o segundo começa a partir dela. Este é o padrão na maioria dos frameworks e é um método com perda de dados de uma forma específica: os modelos resumem em direção à narrativa e para longe dos identificadores. Peça um resumo e você obterá "o cliente é assinante há dois anos e está frustrado" em vez de "conta 8812, plano pro, quatro faturas, reembolso aprovado para a fatura inv_44".
Passar um objeto de entrega estruturado. O primeiro agente preenche um esquema. O segundo lê campos, não prosa. Isso dá mais trabalho para configurar e é o que se mantém.
{
"task_id": "task_2026_08_26_0031",
"from_agent": "research",
"to_agent": "billing",
"entities": {
"customer_id": "cus_8812",
"invoice_ids": ["inv_41", "inv_42", "inv_43", "inv_44"],
"subscription_id": "sub_119"
},
"decisions": [
{ "decision": "refund_eligible", "value": true, "basis": "policy 3.2, charged twice in one cycle" }
],
"constraints": {
"max_refund_cents": 4900,
"human_approval_granted": false,
"actions_taken": ["read_invoices"]
},
"open_questions": ["Customer has not confirmed which invoice to refund"],
"summary": "Customer cus_8812 was double-charged in August. Refund of one invoice is approved under policy 3.2, up to 4900 cents. Awaiting the customer's choice of invoice."
}
A prosa ainda aparece, no campo summary, porque ela carrega nuances que o esquema não possui. Ela fica ao lado dos campos estruturados em vez de substituí-los, o que é o objetivo principal.
Valide o objeto antes que a entrega de informações seja executada. Se o customer_id estiver faltando, falhe ruidosamente na fronteira em vez de deixar o segundo agente descobrir isso três chamadas depois.
Passe referências, não payloads
A versão mais robusta de uma entrega de informações passa quase nenhum dado. Ela passa IDs, e o agente receptor busca o que precisa.
Isso funciona por três razões. O estado permanece atualizado, então se algo mudou entre os dois agentes, o segundo vê o valor atual em vez de uma cópia desatualizada. A entrega de informações permanece pequena, algumas centenas de bytes em vez de dezenas de milhares de tokens. E o rastreamento de auditoria melhora, porque cada leitura aparece como uma chamada de API em vez de texto copiado entre prompts.
Isso exige uma coisa: cada agente pode acessar a mesma API com as permissões corretas. Isso não é gratuito. Cada agente precisa de suas próprias credenciais com escopo para o que ele faz, que é o argumento em nossa publicação sobre chaves de API com o mínimo de privilégios para agentes. Um agente de cobrança que possui um token de pesquisa somente leitura não pode emitir o reembolso, e um agente de pesquisa que possui o token de cobrança é um problema de raio de explosão.
Onde uma nova busca seria cara ou lenta, armazene o registro em cache no seu orquestrador e passe uma referência para a entrada do cache. O agente receptor ainda solicita os dados explicitamente, então o padrão permanece o mesmo, mas a segunda leitura é barata.
Onde as entregas de informações realmente falham
Quatro falhas cobrem a maioria dos incidentes.
O identificador perdido. O resumo diz "o cliente" e nunca fornece um ID, então o segundo agente pesquisa pelo nome, encontra duas correspondências e escolhe a errada. Evite isso validando que os IDs de entidade obrigatórios estejam presentes antes que a entrega de informações possa prosseguir.
A ação repetida. O primeiro agente já enviou o e-mail. A entrega de informações não registra isso. O segundo agente envia novamente. Registre actions_taken no objeto de entrega e verifique-o antes de qualquer escrita, apoiado pelas chaves de idempotência que tornam uma repetição inofensiva.
A aprovação perdida. Um humano aprovou um reembolso enquanto o primeiro agente estava em execução. O segundo agente, sem saber disso, pergunta novamente. Os usuários interpretam o segundo prompt como um sistema que não escuta. Leve as aprovações como restrições explícitas e trate-as como com escopo para a tarefa, e não para o agente.
A invenção confiante. O agente receptor precisa de um valor que a entrega de informações não carregou, e em vez de perguntar, ele inventa um que se encaixa na narrativa. Esta é a falha mais perigosa porque se parece com uma tarefa concluída. A defesa é o campo open_questions mais uma regra rígida no prompt do agente receptor: se um identificador obrigatório estiver ausente, pare e pergunte.
Os loops pioram todas as quatro. Quando o agente A entrega para B e B entrega de volta para A, o estado decai a cada passagem, assim como uma fotocópia de uma fotocópia. Limite o número de saltos e carregue o objeto da tarefa original através de cada um deles, em vez de reconstruí-lo em cada fronteira.
Teste a fronteira, não apenas os agentes
As entregas de informações são pontos de integração, então teste-os como pontos de integração.
Assert no objeto de entrega. Execute o primeiro agente em um cenário fixo e verifique o objeto que ele produz: identificadores obrigatórios presentes, decisões registradas, ações listadas. Esta é uma asserção determinística em um payload estruturado, mesmo que o agente que o produziu não seja determinístico, o que o torna um teste utilizável. A abordagem geral está em nosso guia para testar agentes não determinísticos.
Teste o receptor isoladamente. Forneça ao agente de cobrança um objeto de entrega feito à mão e verifique o que ele faz. Em seguida, forneça um intencionalmente quebrado, com o ID do cliente removido, e confirme que ele pergunta em vez de adivinhar. Este segundo teste é o que pega a invenção.
Execute ambos contra mocks. Um teste de entrega de informações que emite reembolsos reais é um teste que você executará uma vez. Aponte ambos os agentes para endpoints mockados para que o conjunto de testes possa ser executado a cada alteração, seguindo nossa publicação sobre executar agentes contra mocks em vez de produção. No Apidog, os mocks vêm da mesma definição de API que ambos os agentes chamam, então os dois nunca se separam.
Registre cada entrega de informações. Registre o objeto completo em cada fronteira com o ID da tarefa. Quando uma execução multiagente dá errado, o log de entrega de informações informa qual agente tinha a informação e qual a perdeu, o que geralmente é toda a investigação. Nossa publicação sobre rastrear chamadas de ferramentas de agente cobre o que mais pertence a esse registro.
O que os frameworks oferecem
A maioria dos frameworks de orquestração oferece uma primitiva de entrega de informações, e ajuda saber o que cada um realmente move através da fronteira antes de confiar nele.
A documentação de entrega de informações do SDK de Agentes da OpenAI modela uma entrega de informações como uma ferramenta que o agente pode chamar, o que significa que o modelo decide quando o controle é transferido. Isso é conveniente, e coloca a decisão na parte menos determinística do seu sistema, então combine-a com validação na saída.
A orientação multiagente do LangGraph adota a abordagem oposta: o estado é um objeto gráfico explícito que cada nó lê e escreve. Isso se alinha de perto com a entrega de informações estruturada descrita acima, e o trabalho principal que resta a você é decidir quais campos são obrigatórios.
O artigo da Anthropic sobre construção de um sistema de pesquisa multiagente vale a pena ser lido pelos detalhes operacionais, particularmente sobre quanta instrução um subagente precisa antes de poder trabalhar utilmente por conta própria.
O fio condutor comum: todo framework moverá algo. Nenhum deles decide por você quais fatos são essenciais. Essa lista é sua para escrever, e é o que vale a pena revisar quando uma execução dá errado.
Mantenha o objeto da tarefa fora da conversa
Uma mudança estrutural evita toda uma família de bugs. Armazene o estado da tarefa em algum lugar durável, indexado pelo ID da tarefa, e faça com que cada agente o leia e escreva em vez de passá-lo por mensagens.
A conversa é um contêiner inadequado para o estado. Ela é compactada, truncada e reescrita por sumarização, e nenhuma dessas operações sabe quais campos você não pode se dar ao luxo de perder. Uma linha em um banco de dados não tem esse problema.
O padrão é pequeno. No início de um turno, o agente carrega o objeto da tarefa. Quando ele realiza uma ação, anexa a actions_taken e salva. Na entrega de informações, ele passa o ID da tarefa, e o agente receptor carrega o mesmo objeto. Nada importante viaja no prompt, então nada importante pode ser resumido e perdido.
Isso também oferece um ponto de retomada. Se uma execução morrer na quarta etapa, o objeto da tarefa ainda mantém tudo o que as três primeiras etapas estabeleceram, e a nova tentativa começa de lá em vez de do nada.
Onde a plataforma pode manter o estado
Se seus agentes são executados como runtimes CLI em máquinas de desenvolvedores, o objeto de tarefa durável descrito acima é algo que você constrói. Algumas plataformas de gerenciamento de trabalho de agentes já o modelam, e vale a pena saber como isso se parece antes de você escrever o seu próprio.
Sharkly é um sistema de gerenciamento de trabalho para pessoas e agentes construído em torno exatamente desta unidade. Uma Tarefa carrega o objetivo, o status, a pessoa responsável, o Agente ou Equipe atribuída para executá-la, os comentários e o estado de execução e resultado do agente. Uma Equipe (Crew) emparelha um Agente líder com outros Agentes e pessoas, de modo que uma tarefa que precisa de vários especialistas é atribuída a um grupo reutilizável, em vez de ser passada de mão em mão através de prompts. Como o estado reside na Tarefa em vez de em uma conversa, uma entrega de informações entre dois agentes não depende de um deles resumir bem.
Os runtimes permanecem os que você já usa. Claude Code, Codex e os demais executam o trabalho em um Computador que você registra; a plataforma fornece o registro da tarefa, a atribuição e o ciclo de revisão em torno deles. Se você está construindo o padrão de tarefa durável por conta própria, a documentação do Sharkly é uma referência útil para quais campos se mostram importantes.
Um checklist para entregas de informações
- Existe um esquema definido para a entrega de informações, e ele é validado na fronteira.
- Os identificadores de entidade são campos obrigatórios, não opcionais.
- As decisões carregam sua base, para que o receptor não refaça o raciocínio.
- As ações já realizadas são registradas e verificadas antes de qualquer escrita.
- Aprovações e orçamentos viajam com a tarefa, não com o agente.
- As perguntas em aberto são explícitas, e o receptor pergunta em vez de assumir.
- Os dados são passados por referência onde uma nova busca é barata.
- A contagem de saltos é limitada, e o objeto da tarefa original sobrevive a cada salto.
- Cada entrega de informações é registrada com o ID da tarefa.
- Testes de fronteira são executados na CI contra mocks, incluindo uma entrega de informações deliberadamente incompleta.
A maioria das falhas multiagentes não são falhas de raciocínio. Elas são um fato que existia em um agente e não no próximo. Projete a fronteira como uma interface, com um esquema e testes, e o segundo agente para de fazer perguntas que o primeiro já respondeu. Baixe o Apidog para manter os mocks e testes de fronteira ao lado da API da qual ambos os agentes dependem.
Perguntas frequentes
Uma entrega de informações estruturada vale a pena para dois agentes? Para dois agentes em uma tarefa curta, passar a conversa geralmente está tudo bem. O objeto estruturado se paga com três ou mais agentes, em tarefas longas ou em qualquer lugar onde uma entrega de informações cruze um processo ou uma fronteira de execução.
O modelo deve escrever o objeto de entrega de informações ou o código deve construí-lo? O código onde puder. Identificadores, ações realizadas e aprovações devem ser preenchidos pelo seu orquestrador a partir do que realmente aconteceu, não da recordação do modelo. Deixe o modelo escrever apenas o summary e as perguntas em aberto.
Como parar a decadência do contexto em um loop? Carregue um objeto de tarefa por toda a execução e atualize-o, em vez de regenerá-lo em cada fronteira. Em seguida, limite os saltos. Se uma tarefa precisar de mais de alguns, a decomposição provavelmente está errada.
E os frameworks com suporte embutido para entrega de informações? Use-os e verifique o que eles realmente transferem. Muitos passam o histórico de mensagens e nada mais, o que significa que os identificadores sobrevivem apenas se aparecerem no texto. Adicione um payload estruturado junto com o que o framework carrega.
Os subagentes precisam de credenciais de API separadas? Sim, com escopo para o que cada um faz. Compartilhar uma chave poderosa entre agentes remove sua capacidade de limitar danos e de saber qual agente fez uma chamada. Nossa publicação sobre chaves de API com o mínimo de privilégios para agentes aborda a configuração.
Quanto o campo de resumo deve conter? Algumas frases, cobrindo a intenção e nuances que os campos estruturados não podem conter. Se começar a listar IDs e valores, estes pertencem aos campos estruturados onde podem ser validados.