En un equipo que ejecuta varios agentes de programación, una Task cambia de manos constantemente. Un agente worker de Sonnet implementa el cambio y un revisor de Opus lo evalúa. Un agente de Claude Code se detiene y la Task pasa a un agente de Codex. Claude Sonnet 5.5, lanzado el 28 de septiembre, pone por escrito algo que siempre fue cierto en parte: el razonamiento del modelo no acompaña al trabajo realizado. La página de Anthropic sobre las novedades de Sonnet 5.5 señala que cada thinking block «registra qué modelo lo produjo», y ningún otro modelo lee los bloques de Sonnet 5.5.
El problema radica en el silencio con el que sucede. Cuando una solicitud incluye un bloque que el modelo no puede interpretar, la API lo descarta antes de que el modelo llegue a verlo. La petición se procesa con éxito, los bloques descartados no se facturan y el único rastro es una entrada en input_transformations, que aparece únicamente si se envió la cabecera beta thinking-binding-controls-2026-08-01. El agente revisor recibe el diff sin conocer los motivos, no salta ningún error y la revisión da la impresión de estar mucho mejor fundamentada de lo que realmente está.
TL;DR
Para el traspaso de contexto entre modelos de agentes, existe una sola regla: el único contexto que sobrevive al traspaso es lo que alguien dejó anotado en la Task. Los thinking blocks están vinculados al modelo que los generó, a la conversación exacta y, en el caso de Sonnet 5.5, a la cuenta. Haz que cada agente termine su ejecución con un comentario de traspaso: decisiones y sus justificaciones, suposiciones, intentos fallidos, preguntas abiertas, archivos modificados y comprobaciones realizadas. Si construyes tu propio harness, mantén el historial estrictamente como append-only.
Un thinking block está vinculado de tres formas
Un thinking block es el razonamiento producido por un modelo a lo largo de un turno, devuelto con una firma criptográfica que la API valida antes de permitir que una petición posterior lo utilice. La documentación de preserved thinking describe tres tipos de vinculación, y cada una se corresponde con un traspaso que tu equipo ya efectúa en el día a día.
Modelo. Sonnet 5.5 puede leer bloques de Sonnet 5, Opus 4.8, Haiku 4.5 y versiones previas, pero no de Opus 5, Opus 5.5, Fable o Mythos. La dirección del cambio importa: según las notas de Anthropic sobre el cambio de modelos a mitad de una conversación, una conversación que pasa de Sonnet 5 a Sonnet 5.5 conserva su razonamiento, mientras que una que pase de Sonnet 5.5 a cualquier otro modelo procesará los turnos siguientes sin él. Esto incluye el mecanismo de fallback en el servidor de Anthropic, que reintenta en Sonnet 5 ciertas solicitudes declinadas de Sonnet 5.5.
Conversación. Un bloque solo puede reutilizarse si va precedido exactamente por el prompt de sistema, las herramientas y los mensajes que formaron parte de su creación. Las preguntas frecuentes de la documentación destacan la consecuencia directa: el razonamiento no se puede trasladar a una conversación diferente; por tanto, es necesario abrir la nueva conversación partiendo de un resumen del estado de la tarea (el objetivo, las decisiones tomadas, los archivos y resultados obtenidos hasta el momento, y el próximo paso). Cuando una Task pasa a otro agente, el Runtime genera una sesión nueva, lo que representa una conversación distinta incluso cuando se emplea el mismo modelo. Es exactamente el mismo motivo por el que una sesión limpia de una herramienta arranca en frío, tal como tratamos en cómo mantener el contexto entre sesiones de IA.
Cuenta. Los bloques generados por Sonnet 5.5 solo funcionan dentro de la cuenta que los produjo o en una asociada a ella. El artículo de presentación de Anthropic menciona un escenario habitual donde esto se evidencia: al alternar entre cuentas a mitad de una sesión en Claude Code.
En conclusión: entre agentes, el razonamiento nunca llegó a transferirse. Sonnet 5.5 formalizó esa realidad dentro del contrato de la API.
Tres traspasos que descartan el razonamiento silenciosamente
| Handoff | What carries over | What’s lost | What tells you |
|---|---|---|---|
| De agente worker Sonnet 5.5 a agente revisor Opus 5.5 | El diff, el repositorio, la descripción de la Task y los comentarios | El razonamiento de Sonnet 5.5. Ningún otro modelo puede interpretarlo y, de todos modos, la revisión es una sesión nueva | Nada entre agentes. Dentro de una misma conversación de la API, una entrada model_binding_mismatch al incluir la cabecera beta |
| De agente Claude Code a agente Codex | El diff, la rama, el registro de la Task y las reglas compartidas del repositorio | Todo el razonamiento de Claude y el estado de la sesión de Claude Code. Codex arranca su propia conversación | Nada |
| Mismo modelo, distinta cuenta (un cambio de cuenta a mitad de sesión en Claude Code, o una sesión guardada reproducida con credenciales de otra cuenta) | La transcripción visible: mensajes, llamadas a herramientas y resultados | Cada thinking block de Sonnet 5.5 creado bajo la primera cuenta | Una entrada organization_binding_mismatch con la cabecera beta en la API de Claude y Google Cloud. De lo contrario, nada |
El verdadero inconveniente radica en la última columna. Los tres traspasos se ejecutan sin fallos y el agente receptor responde con total seguridad disponiendo de menos información de la que manejaba el anterior. Un revisor en otro modelo puede dar el visto bueno a un cambio que generaba dudas al worker, simplemente porque esas reservas estaban en un bloque de razonamiento que jamás vio.
Ya destacamos anteriormente que cambiar entre agentes de programación «preserva el código y descarta el razonamiento». Ahora este comportamiento se replica a nivel de API, lo que resulta crucial para equipos que utilizan Claude Code y Codex en una misma base de código, así como para reglas de enrutamiento con escalado. Si las Tasks complejas se delegan de un worker Sonnet 5.5 a Opus 5.5, como describimos en Sonnet 5.5 u Opus 5.5: qué agente debe asumir la tarea, cada escalado equivale al traspaso de la primera fila.
Qué debe incluir una nota de traspaso cuando el razonamiento no se transfiere
La nota de traspaso en agentes de programación persigue un único propósito: documentar el razonamiento crucial por escrito, donde el siguiente worker pueda leerlo. Los campos detallados abajo complementan la estructura de resumen de Anthropic con dos puntos que los thinking blocks contenían y que los diffs jamás revelan: por qué se adoptó cierta solución y qué alternativas se descartaron previamente. Incorpóralo en las instrucciones de cualquier agente capaz de transferir una 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
Tres pautas clave garantizan su utilidad:
Solicita decisiones, no el proceso de razonamiento. Sonnet 5.5 es el primer modelo Sonnet con filtros de seguridad contra la extracción de razonamiento; su categoría de rechazo reasoning_extraction abarca solicitudes que pretendan volcar el razonamiento interno en la respuesta. Pedirle «pega tu razonamiento en el comentario» activará este bloqueo; pedirle «enumera cada decisión y su porqué» es un reporte técnico convencional.
«Tried, failed» ahorra una enorme cantidad de tiempo. Un callejón sin salida no se aprecia en un diff. Si no se documenta, el próximo agente corre el riesgo de repetir el mismo camino infructuoso.
Las comprobaciones deben incluir comandos exactos y sus resultados. Afirmar que «los tests pasan» es solo una declaración; registrar el comando ejecutado junto a sus métricas ofrece pruebas reproducibles para el revisor.
El criterio a seguir es simple: prescinde de la nota si un único agente gestiona la Task de principio a fin y la persona encargada revisará el diff detalladamente. Hazla obligatoria en cuanto una Task cambie de Assignee, cambie de modelo o sea asignada a un agente revisor. Las plantillas de traspaso para agentes de programación abordan la transición entre personas y agentes; esta nota resuelve la desconexión entre dos agentes distintos.
Si desarrollas tu propio harness, modificar el historial ahora genera un error
La mayoría de los lectores puede pasar por alto esta sección. La documentación de preserved thinking indica que no hay variaciones si Claude Code, claude.ai, Claude Managed Agents o el SDK de Claude Agent gestionan las peticiones. Esto influye de forma directa cuando tu propio software consume la Messages API.
Para cuentas creadas a partir del 31 de agosto de 2026 a las 00:00 UTC en la API de Claude, Amazon Bedrock y Google Cloud, reutilizar un thinking block de Sonnet 5.5 tras alterar cualquier elemento previo (el system prompt, las herramientas o un mensaje anterior) provocará un error 400. En cuentas más antiguas, la comprobación solo se activa si la petición la solicita expresamente, lo que genera un problema inesperado: tus credenciales funcionan bien, pero un usuario que ejecute tu herramienta con una cuenta moderna se topará con el error 400. La solución consiste en tratar la conversación como append-only.
- Mantén fijas las definiciones de herramientas y el system prompt al inicio de la sesión. Modifica las pautas agregando un mensaje de sistema a mitad de conversación, algo compatible con Sonnet 5.5 pero no con Sonnet 5.
- Devuelve cada turno del asistente de manera idéntica a como fue emitido, incluyendo los thinking blocks vacíos.
- Aplica la compactación mediante la API, evitando reescribir mensajes pasados. La compactación bajo demanda (beta
compact-2026-09-04) proporciona un bloque de resumen firmado para enviarlo en lugar de los mensajes que engloba. El enfoque de compactación simple recomendado por la documentación envía un único mensaje de resumen seguido de la siguiente instrucción, impidiendo que se retransmita razonamiento previo.
{ "role": "system", "content": "Review found a race in the retry path. Do not change the public API." }
Con la cabecera beta activa, el parámetro prefix_mismatch_behavior: "drop_block" descarta los bloques no válidos en lugar de fallar. La documentación recalca que esta opción simplemente enmascara la modificación en vez de solventarla.
Fíjate en el diseño de la compactación recomendada por Anthropic: cuando el razonamiento no se puede transferir, la solución consiste en un resumen por escrito; en esencia, una nota de traspaso con otro formato.
Dónde se gestiona el traspaso en Sharkly
La Task constituye el registro central compartido, y el traspaso debe documentarse en ella porque nada más sobrevive al cierre de sesión. Cada Task almacena la Conversación (un diálogo soportado por comentarios), el historial de Actividad con eventos y modificaciones, y el registro de Ejecuciones de cada proceso. El texto del agente orientado al equipo se almacena como un comentario asociado a la ejecución. Si un agente requiere aclaraciones, formula la pregunta como un comentario dentro de la Task, esta queda en espera de respuesta humana y la notificación se canaliza al Inbox de la persona asignada.
La reasignación demuestra el valor de este método. Al transferir el Assignee desde un agente Sonnet 5.5 hacia un revisor Opus 5.5, o a un agente Codex, la nueva ejecución parte de los datos de la Task en lugar de una transcripción. La documentación de Sharkly especifica qué elementos recibe una ejecución asociada a una tarea: título y descripción, comentarios recientes, el comentario disparador, las instrucciones del agente y los repositorios correspondientes. La nota de traspaso figura en esa lista. El razonamiento del agente previo no se transfiere y, al haber un cambio de modelo, la propia API lo habría descartado.
De aquí surgen dos buenas prácticas. La documentación sugiere registrar acuerdos y conclusiones para el equipo en los comentarios o en la descripción de la Task, garantizando que cualquier punto tratado en un diálogo lateral con un agente quede documentado antes de reasignar. Asimismo, dado que cada ejecución incorpora comentarios recientes, conviene trasladar a la descripción principal aquellas decisiones determinantes para toda la Task.
Es aquí donde cobra verdadero sentido la neutralidad respecto a proveedores. Dado que el agente se adapta al modelo por defecto del Runtime, la pauta de traspaso permanece en sus instrucciones y opera de igual forma tanto si el siguiente Runtime es Claude Code con Sonnet 5.5 como si es Codex en otro entorno. El procedimiento de configuración se encuentra en cómo utilizar agentes Claude Sonnet 5.5 en Sharkly. Los agentes analizan, ejecutan, realizan tests y notifican. El equipo humano define el rumbo, autoriza acciones y valida las entregas partiendo del mismo registro escrito que interpretará el próximo agente, base sobre la cual se asienta el control y responsabilidad humana sobre el trabajo con agentes.
El concepto de preserved thinking debutó con Fable 5.1 y actualmente abarca Opus 5.5 y Sonnet 5.5. Estructura traspasos que no dependan del traslado automático del razonamiento, y ninguna actualización futura de modelos afectará tu flujo. Si ya utilizas múltiples agentes, Sharkly te brinda la plataforma unificada para coordinar sus tareas y supervisar sus resultados.
