Seus agents não conseguem passar trabalho um para o outro. Então você faz isso.

São 23h. O Claude Code acabou de terminar um refactor. Você cola o diff no Codex com um “revisa isso.” O Codex volta com quatro comentários na própria janela dele, sem saber nada sobre o ticket ou o fato de que o Claude Code já tentou essa abordagem duas vezes. Você redigita os dois comentários que importam de volta no Claude Code, depois resume a troca toda para o chat agent que devia estar acompanhando o projeto, porque nenhuma das três ferramentas sabe que as outras duas existem. O que acabou de acontecer não é coordenação de agents Claude Code Codex. É você, no alt-tab.

Colar agents best-of-breed à mão não é orquestração; sem um sistema de registro compartilhado, o humano vira a área de transferência, e o fix é um task-record (registro de tarefa) que todo agent lê e escreve, com um audit trail. Este post defende essa afirmação contra o contra-argumento óbvio, que é que um humano bom o bastante no loop é uma feature, não um bug. Não é, a partir do segundo agent, e vale a pena ser preciso sobre o mecanismo, porque a falha parece uma lacuna de tooling e na verdade é uma camada faltando.

A pilha best-of-breed parece alavancagem

O movimento ingênuo é razoável à primeira vista: escolher a melhor ferramenta para cada trabalho. Claude Code para o codebase, porque segura contexto de repo melhor que qualquer coisa que você já tentou. Um research agent separado para qualquer coisa que precise da web aberta. Um chat-native agent, Codex ou Cowork ou o que quer que seu time tenha padronizado, para revisar e discutir. Três especialistas, cada um excelente na sua única coisa, rodando em paralelo. Isso deveria ser estritamente mais throughput do que um agent generalista fazendo tudo em série.

Isso falha no momento em que dois desses agents precisam tocar no mesmo pedaço de trabalho. O time de engenharia da Delega, descrevendo exatamente esse setup com Claude Code e Codex rodando lado a lado, colocou o modo de falha numa frase que vale a pena citar direto: sem uma camada de coordenação entre eles, “você não está orquestrando agents. Você é um clipboard humano.” O diagnóstico deles sobre a causa raiz é estrutural, não uma reclamação sobre polish de UX: essas ferramentas foram “construídas para serem usadas, não para usar umas às outras.” Concretamente, isso significa nenhuma fila de tarefas compartilhada entre eles, nenhum jeito de um agent criar trabalho para o outro, e nenhum sinal que qualquer um dos dois consiga mandar dizendo que um pedaço de trabalho está de fato pronto. Cada uma dessas três lacunas tem que ser preenchida por uma pessoa, toda vez, ou o handoff não acontece.

Colar agents best-of-breed à mão não é orquestração; sem um sistema de registro compartilhado, o humano vira o clipboard, e o fix é um task-record que todo agent lê e escreve, com um audit trail. Três agents especialistas mais zero camada de coordenação não é três vezes mais alavancagem. É uma pessoa fazendo o trabalho de coordenação que costumava ser implícito numa única conversa, agora feito explícito e manual porque a conversa foi dividida em três janelas.

Coordenação de agents Claude Code Codex não existe por padrão

O contra-argumento natural é que isso é um problema de workflow, resolvível com hábitos melhores: manter um doc compartilhado, colar com mais disciplina, escrever prompts melhores que carreguem mais contexto adiante. Esse contra-argumento falha pela mesma razão que uma planilha compartilhada não substitui um banco de dados. Um doc é um registro do que aconteceu; não é algo que um agent consegue consultar para decidir sua própria próxima ação, escrever um resultado estruturado dentro, ou de onde outro agent consiga ler um veredito de pass/fail. Histórico de chat é pior que um doc nisso, porque não tem schema nenhum: “pronto, ficou bom” e “pronto, três coisas ainda quebradas” são indistinguíveis para o próximo agent que lê a thread, e geralmente indistinguíveis para o humano dando uma passada de olho nela também. Esse é o mesmo modo de falha explorado do lado da confiança em “o handoff é onde o trabalho vai morrer”: um handoff sem um contrato estruturado degrada informação a cada hop, seja o hop agent-para-agent ou agent-para-humano. A divergência deste post em relação àquele é específica: o post sobre o handoff é sobre o que acontece com a informação através de qualquer fronteira de etapa; este é sobre o caso mais estreito e mais comum de três produtos comerciais de agent com zero substrato compartilhado, onde o humano não está só perdendo fidelidade num handoff, ele está performando manualmente o próprio handoff, toda vez, para sempre.

Um terceiro fix ingênuo, um passo além de um doc melhor, é dar aos agents um canal de chat compartilhado só deles. Um time que tenta “dar aos agents um Slack compartilhado e um Telegram compartilhado” pelo menos tentou uma camada de coordenação, o que já é mais do que os dois primeiros fixes conseguem. Ainda assim falha, por uma razão específica sua: um canal de chat não tem o conceito de uma tarefa sendo claimed, em progresso, ou verificada como pronta, só um stream de mensagens, então a ambiguidade se move de um doc para um feed em vez de desaparecer. A falha do clipboard descrita aqui é um passo mais atrás que as três: nenhuma superfície compartilhada jamais foi tentada, então o humano é o mecanismo de coordenação inteiro, não um participante de um mecanismo quebrado.

Um agent que não consegue ver o trabalho de outro agent não é um problema de coordenação esperando por uma context window maior. É um registro compartilhado que não existe, e nenhuma quantidade de prompt engineering substitui isso.

O framing enterprise para por que isso continua se repetindo vem da tese da a16z “From ‘System of Record’ to ‘System of Intelligence’”: o CRM, o ticket tracker, o doc store “não vão desaparecer, assim como o friend graph nunca desapareceu, mas estão virando só um input, um entre muitos inputs, para os sistemas de inteligência que usamos para fazer o trabalho acontecer.” Pilhas multi-agent recriam exatamente essa mesma lacuna uma camada abaixo. Cada produto de agent é o seu próprio pequeno sistema de registro para a própria sessão; nenhum deles é o registro compartilhado onde o trabalho em si precisa viver. O “Roadmap: AI systems of action” da BVP estende essa tese ainda mais, descrevendo a indústria se movendo de sistemas de registro para sistemas de ação, onde o registro para de ser passivo e passa a dirigir a execução. Um clipboard, humano ou não, não é nenhum dos dois. Não é um registro, porque nada persiste além do paste; e não dirige ação nenhuma sozinho.

Um task-record, não um chat log

O fix não é um quarto agent que gerencia os outros três, porque isso só adiciona mais uma janela para você relayar contexto. O fix é um task-record compartilhado que funciona como o sistema de registro para o próprio handoff: uma tarefa rotulada com critérios de aceite explícitos que qualquer agent consegue ler, um lugar estruturado para um resultado ser escrito em vez de um parágrafo num chat, e um audit trail durável de quem claimou a tarefa, o que mudou, e o que o verifier disse, independente do que qualquer agent alega sobre o próprio trabalho.

Colar agents best-of-breed à mão não é orquestração; sem um sistema de registro compartilhado, o humano vira o clipboard, e o fix é um task-record que todo agent lê e escreve, com um audit trail. Concretamente, isso significa que o code agent não entrega um diff para um humano colar no review agent. Os dois agents apontam para a mesma tarefa: o code agent escreve o diff dele e um claim estruturado de conclusão no registro; o review agent lê os critérios de aceite da tarefa direto do registro, lê o diff do registro, e escreve as descobertas dele de volta no mesmo lugar, como dado estruturado, não chat. Nenhum dos dois agents precisa saber que o outro existe como produto. Eles só precisam concordar sobre o formato do task-record. Esse é o mesmo princípio defendido do lado da verificação em “o verifier não pode viver num arquivo que o agent tem permissão de editar”: um pass ou fail que vive em algum lugar que o executor consegue editar silenciosamente não é uma checagem, é uma assinatura que a mesma mão também forja. Um task-record que registra um audit trail que nenhum dos dois agents consegue reescrever retroativamente é o que torna essa verificação confiável, para começo de conversa, e é o mesmo substrato que este post está argumentando que todo handoff, não só o veredito final, precisa passar por.

Este é também o degrau que falta que o próprio framing da a16z deixa implícito e que a BVP estende na direção certa mas não operacionaliza especificamente para trabalho multi-agent: um sistema de inteligência que raciocina através de fontes ainda precisa de algum lugar durável para escrever suas decisões, se um segundo sistema de raciocínio, ou um segundo agent, vai agir sobre elas em seguida. O argumento da Apollo em “sistema de registro, sistema de inteligência, sistema de ação” torna isso o fio condutor explicitamente: o registro, o raciocínio e a ação têm que ser um sistema contínuo só, não três produtos que um humano costura à mão. A própria superfície de produto AI OS da Apollo é construída exatamente em torno disso: o task-record é desenhado para ser o substrato de onde todo agent dentro de um workspace lê seus critérios e para onde escreve seu resultado, então a coordenação acontece no registro em vez de numa janela de chat entre os próprios agents da Apollo — o mesmo fix estrutural que este post está argumentando que toda pilha multi-agent precisa, não uma convenção privada vivendo na cabeça de um time só.

O que isso custa, honestamente

Um task-record compartilhado não é de graça, e a versão honesta desse argumento admite isso. No momento em que você roteia o trabalho de todo agent através de um único registro, você abre mão da capacidade de trocar por qualquer agent novo que lançar semana que vem com zero custo de integração. Um coding agent novinho em folha que é excelente no seu truque estreito ainda tem que ser ensinado a ler o schema de tarefa do registro e escrever o resultado dele de volta nele, e isso é trabalho de integração de verdade, não um paste de API key de cinco minutos. Se o seu time já tem três agents ligados a um registro compartilhado e um quarto aparece no próximo trimestre, alguém é dono de escrever esse adapter.

Existe um segundo custo, menos óbvio: um registro compartilhado é um único ponto de coordenação, o que significa que também é um único ponto de falha e uma única coisa que tem que se manter correta. Um chat log que está errado só confunde o próximo leitor. Um task-record que está errado, um critério de aceite editado silenciosamente, um status virado para done por uma escrita errada, propaga esse erro para todo agent que ler ele em seguida, com a aparência de autoridade que uma mensagem de chat nunca teve. É exatamente por isso que a trilha de auditoria não é decoração em cima do task-record; é a única coisa que torna uma escrita errada detectável depois do fato, em vez de simplesmente acreditada.

Os dois custos valem a pena porque a alternativa não tem custo zero, tem custo escondido. O preço da pilha ingênua é pago todo dia, nos minutos que uma pessoa gasta sendo a camada de integração entre ferramentas que nunca iam conversar sozinhas. O preço do task-record é pago uma vez, em trabalho de adapter, e ele desce conforme mais agents num workspace adotam o mesmo formato, em vez de subir.

A virada

Nada disso é realmente sobre qual marca de agent você padroniza. É sobre onde a verdade de um pedaço de trabalho mora enquanto mais de um ator, humano ou agent, precisa agir sobre ela. Um clipboard não tem memória além do paste atual. Um registro tem. A diferença entre um time que está coordenando seus agents e um time que está manualmente carregando contexto entre eles nunca é a qualidade do modelo de nenhum agent na pilha; é se o trabalho em si tem algum lugar durável para morar que não seja a memória de curto prazo e as abas abertas de uma pessoa.

---

O task-record da Apollo existe para que essa lacuna nunca se abra, para começo de conversa: todo agent trabalhando dentro de um workspace, escrevendo código, pesquisando, revisando, lê seus critérios e escreve seu resultado no mesmo lugar, com uma trilha de auditoria que um humano consegue de fato checar em vez de um claim que ele tem que confiar. Volte para aquele diff das 23h. Num workspace construído assim, ele nunca sai do registro para ser colado em lugar nenhum, porque nunca existiu nenhum outro lugar para ele ir.