Migración de prompts agénticos entre ecosistemas

Portar un prompt agéntico entre GPT-5.6 y Claude Sonnet 4.5 no es traducir markdown a XML. Esa suposición, la de intercambiar headers por tags y esperar que todo funcione, es la forma más rápida de romper tu sistema en producción. Lo que falla no es la sintaxis: son incompatibilidades técnicas duras, diferencias filosóficas de orquestación y un problema que nadie quiere admitir, el volumen de instrucciones heredadas que arrastras de generaciones anteriores.

¿Qué errores explotan al portar un prompt de GPT a Claude?

Empecemos por lo que te estalla en la cara de inmediato. Si portas un prompt de GPT a Sonnet 4.5 y tu código setea temperature a 0, recibes un 400. No una degradación sutil: un error directo [00:42]. Lo mismo pasa con top_p, top_k en valores no default, assistant prefill o budget_tokens manual.

¿Por qué? Porque Sonnet 4.5 usa thinking adaptativo como único modo, siempre activo, sin forma de desactivarlo [01:01]. Piénsalo como enchufar un dispositivo de tres pines en un socket de dos. Ninguna cantidad de wordsmithing lo arregla; necesitas recablear la conexión.

¿Por qué mi prompt de GPT devuelve error 400 en Claude Sonnet 4.5? Porque parámetros como temperature=0, top_p, top_k, assistant prefill o budget_tokens son incompatibles con el thinking adaptativo obligatorio de Sonnet 4.5.

¿Qué es una rotura silenciosa en modelos con fallback?

Hay algo peor que un 400: la rotura silenciosa. Prompts que piden al modelo explicar su razonamiento interno, con frases tipo show your thinking, pueden disparar un refusal en Sonnet 4.5. La respuesta llega como HTTP 200, tu sistema cree que todo está bien, pero el stop_reason es refusal [01:36].

Y si usas el parámetro fallback, el request se rutea silenciosamente a Opus 4.8. Obtienes output, pero no del modelo que pagaste [01:46].

¿Por qué las instrucciones heredadas degradan el rendimiento?

Ambos proveedores dicen lo mismo en 2026: prompts sobreespecificados degradan performance. Anthropic lo dice directamente: habilidades construidas para modelos anteriores son frecuentemente demasiado prescriptivas. OpenAI recomienda definir outcome y constraints, y luego dejar espacio [02:08].

El daño al portar no viene de usar el formato equivocado. Viene de mantener todas esas instrucciones legacy. El volumen es el problema, no el dialecto.

¿Cómo funciona la jerarquía de instrucciones en cada ecosistema?

La jerarquía diverge fuerte entre proveedores:

• OpenAI tiene tres niveles: platform, developer y user. Las instrucciones van como developer message o en el parámetro top-level instructions del Responses API [02:34].
• Anthropic usa un solo parámetro system con tags XML como ciudadanos de primera clase. Los documentos van arriba del query, el query al final [02:48].
• Si usas un SDK compatible con OpenAI para hablar con Anthropic, la propia Anthropic etiqueta ese setup como no apto para producción [02:57].

Lo clave es qué escribes, no dónde lo colocas.

¿Qué se rompe al cruzar ecosistemas en tool calling?

Tres cosas se rompen al cruzar ecosistemas cuando trabajas con tool calling:

1. Narrar cada tool call es activamente incorrecto en GPT-5.6. La narración densa estilo Claude debe cortarse [03:13].
2. Los primitivos de orquestación son completamente diferentes. GPT-5.6 tiene acciones hosted: spawn_agent, send_message, wait_agent e interrupt_agent. Claude Code orquesta en lenguaje natural: diriges teammates por nombre y les das task lists [03:33].
3. Programmatic Tool Calling en GPT-5.6 requiere instrucciones explícitas y acotadas. Una instrucción genérica como use tools efficiently está listada oficialmente como algo en lo que no debes confiar [03:57].

Un prompt que spawnee subagentes en GPT no hace absolutamente nada en el API de Claude a menos que hayas construido esas tools tú mismo.

¿Puedo copiar mi lógica de subagentes de GPT-5.6 a Claude? No. Los primitivos como spawn_agent de OpenAI no existen en Claude; ahí orquestas por lenguaje natural con teammates nombrados. Es incompatibilidad arquitectural, no de sintaxis.

¿Cómo cambia el prompt caching entre GPT y Claude?

Ambos sistemas permiten marcar secciones reutilizables, pero con mecánicas divergentes que te muerden si no las respetas.

¿Qué diferencias existen entre prompt_cache_breakpoint y cache_control?

• GPT-5.6 usa prompt_cache_breakpoint en modo explícito más una prompt_cache_key obligatoria, un string que funciona como número de locker. Sin esta key, el matching falla [04:30].
• Claude usa cache_control seteado a ephemeral con fingerprint del contenido real, sin locker. Si el contenido coincide exactamente, el cache pega [04:40].
• Tu prefijo en GPT necesita al menos 1024 tokens antes de cualquier breakpoint. Claude permite 512 [04:58].

Algunas secciones que cacheabas en Claude serán demasiado cortas para GPT.

¿Cuánto duran los caches y qué modelo conviene según tu carga?

El TTL también diverge. GPT ofrece 30 minutos fijos. Claude ofrece 5 minutos por default o una hora opcional a cambio de un write más caro [05:15]. GPT funciona mejor para agent loops sostenidos dentro de media hora. Claude te da margen si hay gaps largos entre requests.

¿Qué porta limpio y qué requiere reescritura?

Hay una lista clara de lo que sobrevive la migración y lo que no.

Portan con bajo riesgo:

• Disciplina de contrato sin contradicciones internas.
• Formato de Programmatic Tool Calling.
• Instrucciones mínimas que fijan un problema específico y medido.
• AGENTS.md como archivo de contexto, un estándar abierto de más de 30 tools [05:45].

Requieren reescritura sustancial:

• Boilerplate de brevedad que over-trunca.
• Rituales de think harder.
• Narración de tool calls.
• Instrucciones de orquestación multi-agente, el caso más duro por primitivos arquitecturalmente diferentes [05:59].

¿Cómo debo migrar sin perder atribución causal?

Cambia modelo primero, mantén effort y corre evaluaciones sin tocar el prompt. Luego remueve una categoría de instrucciones a la vez, evaluando después de cada cambio [06:13]. Nunca reescribas todo simultáneamente porque pierdes atribución causal. Y trackea costo por tarea resuelta, no por token: un modelo puede usar más tokens y aun así resolver más.

El lock-in más profundo no está en el formato del prompt. Está en la lógica de orquestación construida sobre primitivos propietarios. Si tu sistema entero depende de spawn_agent y wait_agent de OpenAI, o de teammates en lenguaje natural de Claude, compraste una dependencia arquitectural que no se resuelve con find and replace [06:49].

En la próxima clase vamos a desarmar cómo evaluar qué claims son verificables, qué riesgos genera ultra mode en producción y cómo comunicar incertidumbre a tu equipo sin caer en parálisis ni en credulidad ciega. ¿Ya te tocó portar algún prompt entre estos modelos? Cuéntame qué se te rompió primero.