Au sein d'une équipe exploitant plusieurs agents de code, une Tâche passe continuellement de main en main. Un agent de développement Sonnet écrit la modification et un relecteur Opus la vérifie. Un agent Claude Code se retrouve bloqué, et la Tâche est transférée à un agent Codex. Claude Sonnet 5.5, sorti le 28 septembre, formalise explicitement ce qui a toujours été en partie vrai : le raisonnement du modèle n'accompagne pas le travail produit. La page d'Anthropic sur les nouveautés de Sonnet 5.5 indique que chaque bloc de réflexion « enregistre quel modèle l'a produit », et aucun autre modèle ne peut lire les blocs de Sonnet 5.5.
Le problème réside dans la discrétion avec laquelle cela se produit. Lorsqu'une requête comporte un bloc que le modèle ne peut pas lire, l'API le supprime silencieusement avant même que le modèle ne le voie. La requête aboutit, les blocs supprimés ne sont pas facturés, et la seule trace restante est une entrée input_transformations, qui n'apparaît que si vous avez envoyé l'en-tête bêta thinking-binding-controls-2026-08-01. L'agent relecteur reçoit le diff sans en comprendre le pourquoi, aucune erreur n'est levée, et la relecture paraît bien mieux informée qu'elle ne l'est en réalité.
En résumé
Pour la transmission de contexte entre agents utilisant des modèles différents, une seule règle prévaut : le seul contexte qui survit à un passage de relais est ce qui a été consigné par écrit dans la Tâche. Les blocs de réflexion sont liés au modèle qui les a générés, à la conversation exacte et, pour Sonnet 5.5, au compte utilisé. Veillez à ce que chaque agent termine son exécution par un commentaire de passation : décisions prises et leurs motivations, hypothèses de travail, approches tentées sans succès, questions en suspens, fichiers modifiés et vérifications effectuées. Si vous concevez votre propre harness, conservez l'historique en mode ajout uniquement (append-only).
Un bloc de réflexion est lié de trois manières
Un bloc de réflexion correspond au raisonnement produit par un modèle au cours d'un tour de parole, renvoyé avec une signature que l'API vérifie avant qu'une requête ultérieure ne puisse l'utiliser. La documentation sur la préservation de la réflexion décrit trois types de liaison, et chacun correspond à une passation que votre équipe effectue déjà au quotidien.
Le modèle. Sonnet 5.5 peut lire les blocs provenant de Sonnet 5, d'Opus 4.8, d'Haiku 4.5 et de modèles antérieurs, mais pas ceux d'Opus 5, d'Opus 5.5, de Fable ou de Mythos. Le sens du transfert compte : d'après les notes d'Anthropic sur le changement de modèle en cours de conversation, un échange qui passe de Sonnet 5 à Sonnet 5.5 conserve son raisonnement, tandis qu'une transition de Sonnet 5.5 vers n'importe quel autre modèle exécute les tours suivants sans ce dernier. Cela inclut le mécanisme de repli côté serveur propre à Anthropic, qui réessaie certaines requêtes refusées par Sonnet 5.5 sur Sonnet 5.
La conversation. Un bloc n'est utilisable que s'il s'inscrit dans la continuité exacte du prompt système, des outils et des messages à partir desquels il a été généré. La FAQ de la documentation en précise la conséquence : le raisonnement ne peut pas être transféré dans une autre conversation ; il faut donc démarrer la nouvelle à partir d'un résumé de l'état de la tâche (l'objectif, les décisions prises, les fichiers et résultats obtenus jusqu'ici, la prochaine étape). Lorsqu'une Tâche passe à un autre agent, le Runtime démarre une nouvelle session, ce qui équivaut à une nouvelle conversation, même avec le même modèle. C'est précisément pour cette raison qu'une nouvelle session d'un outil repart de zéro, un sujet abordé dans notre article sur le maintien du contexte entre sessions d'IA.
Le compte. Les blocs de Sonnet 5.5 ne fonctionnent qu'au sein du compte qui les a générés ou d'un compte qui lui est associé. L'article de lancement d'Anthropic mentionne un cas concret où cela se manifeste : le changement de compte en cours de session dans Claude Code.
En résumé : entre différents agents, le raisonnement n'a en réalité jamais été transmis. Sonnet 5.5 n'a fait qu'inscrire cette règle noir sur blanc dans le contrat d'API.
Trois passations qui abandonnent silencieusement le raisonnement
| Passation | Ce qui est conservé | Ce qui est perdu | Ce qui vous en alerte |
|---|---|---|---|
| De l'agent de développement Sonnet 5.5 à l'agent relecteur Opus 5.5 | Le diff, le dépôt, la description de la Tâche et les commentaires | La réflexion de Sonnet 5.5. Aucun autre modèle ne peut la lire, et la session de relecture constitue de toute façon une nouvelle session | Rien d'un agent à l'autre. Au sein d'une même conversation API, une entrée model_binding_mismatch avec l'en-tête bêta |
| De l'agent Claude Code à l'agent Codex | Le diff, la branche, l'enregistrement de la Tâche, le fichier de règles partagé du dépôt | L'intégralité de la réflexion de Claude et l'état de session de Claude Code. Codex démarre sa propre conversation | Rien |
| Même modèle, compte différent (changement de compte en cours de session dans Claude Code, ou relecture d'une session enregistrée avec les identifiants d'un autre compte) | La transcription visible : messages, appels d'outils, résultats | Chaque bloc de réflexion de Sonnet 5.5 produit avec le premier compte | Une entrée organization_binding_mismatch avec l'en-tête bêta, sur l'API Claude et Google Cloud. Sinon, rien |
C'est la dernière colonne qui pose problème. Les trois passations s'exécutent avec succès, et l'agent récepteur répond avec assurance en disposant de moins d'informations que le précédent. Un relecteur tournant sur un autre modèle peut ainsi approuver une modification sur laquelle l'agent de développement avait des doutes, simplement parce que ces doutes se trouvaient dans une réflexion qu'il n'a jamais vue.
Nous écrivions précédemment que passer d'un agent de code à un autre « préserve le code et abandonne le raisonnement ». Ce constat s'applique désormais aussi au niveau de l'API, ce qui a son importance pour les équipes qui utilisent conjointement Claude Code et Codex sur une même base de code et pour les règles de routage avec escalade. Si les Tâches complexes sont transmises d'un agent de développement Sonnet 5.5 à Opus 5.5, comme décrit dans Sonnet 5.5 ou Opus 5.5 : quel agent pour quelle tâche ?, chaque escalade correspond exactement à la passation de la première ligne.
Ce que doit contenir une note de passation lorsque le raisonnement ne peut être transmis
La note de passation d'un agent de code n'a qu'un seul rôle : consigner par écrit les éléments de raisonnement essentiels, là où l'agent suivant pourra les consulter. Les champs ci-dessous enrichissent le format de résumé proposé par Anthropic avec deux éléments que contenaient les blocs de réflexion et que les diffs ne révèlent jamais : pourquoi une solution donnée a été choisie, et quelles pistes ont déjà été écartées. Intégrez ce modèle dans les instructions de chaque agent susceptible de transmettre une Tâche :
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
Trois détails garantissent son efficacité.
Demandez les décisions, pas le raisonnement brut. Sonnet 5.5 est le premier modèle Sonnet doté de classificateurs de sécurité contre l'extraction de raisonnement, et sa catégorie de refus reasoning_extraction bloque les requêtes demandant de reproduire la réflexion interne dans le texte de réponse. « Colle ta réflexion dans le commentaire » relève précisément de ce cas de figure. « Énumère chaque décision et sa justification » constitue un compte rendu tout à fait ordinaire.
La section « Tenté, échoué » est celle qui fait gagner le plus de temps. Une impasse est invisible dans un diff. Sans cette note, rien n'empêche l'agent suivant de commettre exactement la même erreur.
Les vérifications doivent inclure les commandes et leur résultat. « Les tests passent » est une simple affirmation. La commande exécutée, accompagnée du décompte des résultats, constitue une preuve concrète qu'un relecteur peut relancer.
La règle d'arbitrage est simple : faites l'impasse sur cette note lorsqu'un seul agent gère une Tâche de son attribution jusqu'à la relecture en une seule passe, et que la personne qui valide le travail examine de toute façon le diff. Exigez-la dès lors qu'une Tâche change de responsable (Assignee), change de modèle ou est transmise à un agent relecteur. Nos modèles de passation pour agents de code traitent des points de contact entre un humain et un agent ; cette note s'adresse au point de jonction entre deux agents.
Si vous développez votre propre harness, modifier l'historique déclenche désormais une erreur
La plupart des lecteurs peuvent passer cette section. La documentation sur la préservation de la réflexion précise que rien ne change si vos requêtes sont générées par Claude Code, claude.ai, Claude Managed Agents ou le SDK Claude Agent. Cela ne concerne que les cas où votre propre code appelle directement l'API Messages.
Pour les comptes créés à compter du 31 août 2026 à 00:00 UTC sur l'API Claude, Amazon Bedrock et Google Cloud, rejouer un bloc de réflexion de Sonnet 5.5 après avoir modifié le moindre élément antérieur (le prompt système, les outils ou un message précédent) renvoie une erreur 400. Les comptes plus anciens ne subissent cette vérification que si la requête l'active explicitement, ce qui tend un piège : tout fonctionne avec votre propre clé API, mais un utilisateur exécutant votre outil avec la clé d'un compte plus récent essuie l'erreur 400. La solution : conservez la conversation en mode ajout seul (append-only).
- Figez le prompt système et les outils dès le début de la session. Modifiez les instructions en ajoutant un message système en cours de conversation, ce que Sonnet 5.5 prend en charge, contrairement à Sonnet 5.
- Renvoyez chaque tour de l'assistant exactement tel qu'il a été retourné, y compris les blocs de réflexion vides.
- Effectuez le compactage via l'API, et non en réécrivant les tours précédents. Le compactage à la demande (bêta
compact-2026-09-04) renvoie un bloc de résumé signé que vous envoyez à la place des messages concernés. Le compactage simple recommandé par la documentation consiste à envoyer un seul message de résumé suivi de l'instruction suivante, ce qui évite de rejouer les anciennes réflexions.
{ "role": "system", "content": "Review found a race in the retry path. Do not change the public API." }
Avec l'en-tête bêta, prefix_mismatch_behavior: "drop_block" supprime les blocs non conformes au lieu de lever une erreur. La documentation précise bien que cela ne fait que masquer la modification au lieu de résoudre le problème.
Remarquez la structure du compactage recommandé par Anthropic. Lorsque le raisonnement ne peut pas être rejoué, la réponse d'Anthropic réside dans un résumé écrit : une note de passation qui ne dit pas son nom.
Où se situe la passation dans Sharkly
La Tâche constitue le registre partagé, et la passation doit impérativement s'y trouver, car rien d'autre ne subsiste au-delà de la session. Une Tâche regroupe la Conversation (un dialogue sous forme de commentaires), le fil d'Activité recensant commentaires et modifications, ainsi que l'historique des Exécutions de chaque session. Les messages d'un agent destinés à l'équipe sont enregistrés sous forme de commentaire rattaché à l'exécution. Lorsqu'un agent a besoin d'une réponse, sa question est postée dans la Tâche sous forme de commentaire, la Tâche affiche le statut en attente d'une réponse humaine, et la question parvient directement dans la boîte de réception (Inbox) de la personne concernée.
C'est lors de la réattribution que cette approche prend tout son sens. Modifiez le responsable (Assignee) pour passer d'un agent Sonnet 5.5 à un relecteur Opus 5.5, ou à un agent Codex, et l'exécution suivante démarrera à partir de la Tâche, et non d'une transcription. La documentation de Sharkly détaille ce qu'une exécution basée sur une tâche peut intégrer : le titre et la description, les commentaires récents ainsi que celui qui a déclenché l'exécution, les instructions de l'agent et ses dépôts. Le commentaire de passation figure dans cette liste. La réflexion de l'agent précédent n'y figure pas et, lors d'un changement de modèle, l'API l'aurait de toute façon écartée.
Deux bonnes pratiques en découlent. La documentation recommande d'inscrire les conclusions destinées à l'équipe dans les commentaires ou dans la description de la Tâche ; tout arbitrage conclu dans un échange parallèle avec un agent doit donc y être consigné avant de transférer la Tâche. De plus, comme une exécution charge les commentaires récents, veillez à intégrer dans la description les décisions qui doivent s'appliquer à l'ensemble de la Tâche.
C'est ici que la neutralité vis-à-vis des fournisseurs prend toute sa valeur. L'agent utilise le modèle par défaut du Runtime ; la règle de passation réside donc dans les instructions de l'agent et fonctionne à l'identique, que le Runtime suivant soit Claude Code sur Sonnet 5.5 ou Codex sur un autre modèle. La configuration est détaillée dans notre guide sur l'exécution des agents Claude Sonnet 5.5 dans Sharkly. Les agents effectuent des recherches, exécutent, testent et rendent compte. Les humains fixent le cap, accordent les autorisations et valident le résultat à partir du même compte rendu écrit que consultera l'agent suivant — un principe fondamental pour garantir le contrôle humain sur le travail des agents.
La préservation de la réflexion a vu le jour avec Fable 5.1 et concerne désormais Opus 5.5 et Sonnet 5.5. Mettez en place des passations qui ne dépendent jamais du transfert du raisonnement, et le prochain changement de modèle ne viendra pas perturber vos flux de travail. Si vous faites déjà tourner plusieurs agents, Sharkly vous offre un espace centralisé pour gérer leurs tâches et leurs résultats.
