Uma Task muda de mãos constantemente em uma equipe que opera vários agentes de programação. Um worker Sonnet escreve a alteração e um revisor Opus a verifica. Um Claude Code Agent trava e a Task passa para um Codex Agent. O Claude Sonnet 5.5, lançado em 28 de setembro, formaliza algo que sempre foi parcialmente verdade: o raciocínio do modelo não acompanha o trabalho. A página de novidades do Sonnet 5.5 da Anthropic afirma que cada bloco de pensamento “registra qual modelo o produziu”, e nenhum outro modelo lê os blocos do Sonnet 5.5.
O problema é o silêncio com que isso acontece. Quando uma requisição contém um bloco que o modelo não consegue ler, a API o descarta antes que o modelo o veja. A requisição é concluída com sucesso, os blocos descartados não são cobrados e o único rastro é uma entrada em input_transformations, que só aparece se você tiver enviado o cabeçalho beta thinking-binding-controls-2026-08-01. O Agent revisor recebe o diff sem o "porquê", nenhum erro é gerado e a revisão parece muito mais bem informada do que realmente é.
TL;DR
Para o contexto de handoff entre agentes e modelos, uma única regra resolve: o único contexto que sobrevive a uma transferência é o que alguém registrou na Task. Os blocos de pensamento são vinculados ao modelo que os gerou, à conversa exata e, no caso do Sonnet 5.5, à conta. Faça com que todo Agent termine sua execução com um comentário de handoff: decisões e suas justificativas, premissas assumidas, o que foi tentado e falhou, dúvidas em aberto, arquivos alterados e verificações executadas. Se você estiver construindo seu próprio harness, mantenha o histórico estritamente incremental (append-only).
Um bloco de pensamento é vinculado de três formas
Um bloco de pensamento é o raciocínio gerado por um modelo para um turno de interação, retornado com uma assinatura que a API valida antes que uma requisição posterior possa utilizá-lo. A documentação sobre preservação de pensamento (preserved thinking) descreve três vinculações, e cada uma delas corresponde a um handoff que sua equipe já realiza no dia a dia.
Modelo. O Sonnet 5.5 lê blocos do Sonnet 5, Opus 4.8, Haiku 4.5 e de modelos anteriores, mas não do Opus 5, Opus 5.5, Fable ou Mythos. A direção importa: de acordo com as notas da Anthropic sobre a troca de modelos no meio de uma conversa, uma conversa que migra do Sonnet 5 para o Sonnet 5.5 mantém seu raciocínio, mas uma que vai do Sonnet 5.5 para qualquer outro modelo executa os turnos seguintes sem ele. Isso inclui o próprio fallback no servidor da Anthropic, que tenta novamente no Sonnet 5 algumas requisições recusadas pelo Sonnet 5.5.
Conversa. Um bloco só pode ser utilizado quando vem na sequência exata do prompt de sistema, ferramentas e mensagens a partir dos quais foi gerado. O FAQ da documentação deixa clara a consequência: o raciocínio não pode ser transferido para uma conversa diferente; portanto, inicie a nova a partir de um resumo do estado da tarefa (o objetivo, decisões tomadas, arquivos e resultados até o momento e o próximo passo). Quando uma Task passa para um Agent diferente, o Runtime inicia uma nova sessão — o que constitui uma nova conversa, mesmo no mesmo modelo. Esse é o mesmo motivo pelo qual uma nova sessão de uma ferramenta começa do zero, conforme abordado em como manter o contexto entre sessões de IA.
Conta. Os blocos do Sonnet 5.5 funcionam apenas na conta em que foram gerados ou em uma conta vinculada a ela. O post de lançamento da Anthropic cita uma situação em que isso acontece: ao alternar de conta no meio de uma sessão no Claude Code.
Em resumo: entre Agents, o raciocínio nunca foi compartilhado. O Sonnet 5.5 transformou isso em parte do contrato da API.
Três handoffs que descartam o raciocínio silenciosamente
| Handoff | O que é mantido | O que é perdido | O que indica isso |
|---|---|---|---|
| Do Agent worker Sonnet 5.5 para o Agent revisor Opus 5.5 | O diff, o repositório, a descrição da Task e os comentários | O pensamento do Sonnet 5.5. Nenhum outro modelo o lê e, de qualquer forma, a execução de revisão é uma nova sessão | Nada entre Agents. Dentro de uma mesma conversa da API, uma entrada model_binding_mismatch ao usar o cabeçalho beta |
| Do Claude Code Agent para o Codex Agent | O diff, a branch, o registro da Task e o arquivo de regras compartilhadas do repositório | Todo o pensamento do Claude e o estado da sessão do Claude Code. O Codex inicia sua própria conversa | Nada |
| Mesmo modelo, conta diferente (uma troca de conta no meio da sessão no Claude Code ou a reprodução de uma sessão salva com as credenciais de outra conta) | A transcrição visível: mensagens, chamadas de ferramentas e resultados | Todos os blocos de pensamento do Sonnet 5.5 gerados na primeira conta | Uma entrada organization_binding_mismatch com o cabeçalho beta, na Claude API e no Google Cloud. Caso contrário, nada |
A última coluna é o grande problema. Todos os três handoffs são concluídos com sucesso, e o Agent receptor responde com total confiança sabendo menos do que o anterior sabia. Um revisor que utiliza outro modelo pode aprovar uma alteração sobre a qual o worker tinha dúvidas, simplesmente porque essas dúvidas estavam em um raciocínio que ele nunca chegou a ver.
Já havíamos escrito anteriormente que alternar entre agentes de programação “preserva o código e descarta o raciocínio”. Isso agora se aplica também no nível da API, o que é fundamental para equipes que executam Claude Code e Codex em uma mesma base de código e para regras de roteamento com escalonamento. Se Tasks complexas passam de um worker Sonnet 5.5 para o Opus 5.5, como mostrado em Sonnet 5.5 ou Opus 5.5: qual agente deve receber a tarefa, cada escalonamento é exatamente um handoff da primeira linha da tabela.
O que uma nota de handoff precisa conter quando o raciocínio não pode ser transferido
A nota de handoff de um agente de programação tem apenas um papel: registrar por escrito o raciocínio que realmente importa, para que o próximo worker consiga lê-lo. Os campos abaixo expandem o modelo de resumo sugerido pela Anthropic com dois pontos cruciais que os blocos de pensamento continham e que os diffs nunca mostram: por que um caminho foi escolhido e quais alternativas já foram descartadas. Cole isso nas instruções de todo Agent capaz de repassar uma Task:
Before you finish, post one comment on the Task that starts with "Handoff".
Write it for a reader who has this Task and the diff, and nothing else.
Decisions: each choice you made and the reason for it, one line each
Assumptions: what you took as true without verifying it
Tried, failed: approaches you ruled out and why, so nobody retries them
Open questions: what a person or the next Agent has to decide
Files touched: paths changed, and which ones are unfinished
Checks run: exact commands and their results; name any check you skipped
Next step: the one action you would take next
Três detalhes garantem a eficácia desse processo.
Peça decisões, não o raciocínio propriamente dito. O Sonnet 5.5 é o primeiro modelo da linha Sonnet a incluir classificadores de segurança contra extração de raciocínio, e sua categoria de recusa reasoning_extraction abrange solicitações para reproduzir o raciocínio interno no texto da resposta. “Cole seu pensamento no comentário” se enquadra nessa solicitação. Já “Liste cada decisão e sua justificativa” é apenas um relatório de rotina.
“Tried, failed” é o que mais economiza tempo. Um beco sem saída é invisível em um diff. Sem essa anotação, o próximo Agent corre o risco de cometer exatamente o mesmo erro.
Verificações significam comandos e resultados. Dizer “os testes passaram” é apenas uma afirmação. O comando executado, com suas contagens e saídas, é uma evidência concreta que o revisor pode reproduzir.
A regra de decisão é simples: dispense a nota quando um único Agent conduzir uma Task do início à revisão em uma única execução contínua e a pessoa responsável pela aprovação for analisar o diff de qualquer forma. Exija-a no instante em que a Task mudar de Assignee (responsável), mudar de modelo ou for enviada para um Agent revisor. Os modelos de handoff para agentes de programação cobrem a transição entre uma pessoa e um Agent; esta nota cobre a transição entre dois Agents.
Se você constrói seu próprio harness, editar o histórico agora gera erro
A maioria dos leitores pode ignorar esta parte. A documentação sobre preservação de pensamento afirma que nada muda se as suas requisições forem geradas pelo Claude Code, claude.ai, Claude Managed Agents ou Claude Agent SDK. Isso se torna relevante quando é o seu próprio código que faz chamadas diretas à Messages API.
Para contas criadas a partir de 31 de agosto de 2026 às 00:00 UTC, na Claude API, Amazon Bedrock e Google Cloud, reenviar um bloco de pensamento do Sonnet 5.5 após qualquer alteração no histórico anterior (no prompt de sistema, nas ferramentas ou em uma mensagem anterior) retorna um erro 400. Contas mais antigas só passam por essa validação se a requisição optar por isso expressamente, o que cria uma armadilha: a sua própria chave funciona sem problemas, mas um usuário executando a ferramenta com a chave de uma conta mais nova é barrado pelo erro 400. A solução: mantenha a conversa estritamente incremental (append-only).
- Congele o prompt de sistema e as ferramentas no início da sessão. Altere as instruções anexando uma mensagem de sistema no meio da conversa, recurso suportado pelo Sonnet 5.5, mas não pelo Sonnet 5.
- Envie de volta cada turno do assistente exatamente como foi retornado, incluindo blocos de pensamento vazios.
- Faça a compactação pela API, e não reescrevendo turnos anteriores. A compactação sob demanda (beta
compact-2026-09-04) retorna um bloco de resumo assinado que você envia no lugar das mensagens abrangidas. A compactação simples recomendada pela documentação envia uma mensagem de resumo mais a instrução seguinte, de modo que nenhum pensamento antigo seja reutilizado.
{ "role": "system", "content": "Review found a race in the retry path. Do not change the public API." }
Com o cabeçalho beta, prefix_mismatch_behavior: "drop_block" descarta os blocos incompatíveis em vez de retornar erro. A documentação deixa claro que isso apenas mascara a edição, em vez de corrigi-la.
Observe o formato da compactação recomendada pela Anthropic. Quando o raciocínio não pode ser reenviado, a solução da Anthropic é um resumo por escrito: uma nota de handoff com outro nome.
Onde o handoff fica registrado no Sharkly
A Task é o registro compartilhado, e o handoff deve ficar nela porque nada mais sobrevive à sessão. Uma Task armazena a Conversation (diálogo baseado em comentários), a linha do tempo de Activity com comentários e alterações, e o histórico de Executions de cada execução. Mensagens do Agent destinadas à equipe são salvas como comentários vinculados àquela execução. Quando um Agent precisa de uma resposta, sua dúvida é enviada de volta à Task como comentário, a Task passa a indicar que está aguardando resposta humana e a questão chega à Inbox dessa pessoa.
É na reatribuição que essa abordagem se paga. Altere o Assignee de um Agent Sonnet 5.5 para um revisor Opus 5.5 ou para um Agent Codex, e a próxima execução começará a partir da Task, e não de uma transcrição. A documentação do Sharkly lista o que uma execução baseada em tarefa pode incluir: o título e a descrição, comentários recentes e o comentário que acionou a execução, as instruções do Agent e seus repositórios. O comentário de handoff está nessa lista. O pensamento do Agent anterior não está — e, ao trocar de modelo, a API o descartaria de qualquer forma.
Disso decorrem dois hábitos práticos. A documentação recomenda registrar conclusões visíveis para a equipe em comentários ou na descrição da Task, garantindo que qualquer decisão tomada em um bate-papo à parte com um Agent seja inserida ali antes da Task avançar. E, como cada execução carrega os comentários recentes, consolide na descrição as decisões que devem permanecer válidas durante toda a Task.
É aqui que a neutralidade em relação a provedores mostra seu valor. O Agent segue o modelo padrão do Runtime, portanto a regra de handoff reside nas instruções do Agent e funciona da mesma forma, seja o próximo Runtime o Claude Code no Sonnet 5.5 ou o Codex em qualquer outro modelo. As instruções de configuração estão em como executar agentes Claude Sonnet 5.5 no Sharkly. Os agentes pesquisam, executam, testam e reportam. As pessoas definem o direcionamento, concedem autoridade e aprovam o resultado a partir do mesmo registro por escrito que o próximo Agent lerá — que é exatamente a base para o controle e protagonismo humano sobre o trabalho dos agentes.
A preservação de pensamento começou com o Fable 5.1 e agora abrange o Opus 5.5 e o Sonnet 5.5. Estruture handoffs que nunca dependam da transferência de raciocínio, e a próxima troca de modelo não quebrará o seu fluxo. Se você já opera vários agentes, o Sharkly oferece um único lugar para gerenciar suas tarefas e resultados.
