System messages tool calling y rituales obsoletos

El system message que funcionaba en GPT-5.5 probablemente está saboteando tus resultados en GPT-5.6. No porque esté mal escrito, sino porque el modelo cambió lo que escucha, lo que ignora y lo que interpreta al revés de lo que esperas. Si trabajas con la API de OpenAI y quieres prompts que rindan, aquí tienes la nueva estructura oficial y los antipatrones que debes eliminar.

¿Qué pasó con el rol system en GPT-5.6?

El rol system como tal quedó deprecado desde la generación o-1. Ahora tus instrucciones viajan en un developer message dentro del input array, o en el parámetro top-level instructions del Responses API.

La jerarquía sigue igual y en este orden: platform arriba, developer después y user al final. Cambia el contenedor, no la lógica de prioridades.

¿Dónde escribo el prompt del sistema en la nueva API? En el developer message dentro del input array, o en el parámetro instructions del Responses API. El rol system ya no se usa desde o-1.

¿Cuáles son las 8 secciones del esqueleto oficial?

El esqueleto recomendado tiene ocho secciones en orden específico, en texto plano y con labels claros:

1. Role: quién es el modelo.
2. Personality: tono base.
3. Goal: qué debe existir al final.
4. Success criteria: cómo verificar que se logró.
5. Constraints: qué no puede pasar.
6. Tools: qué herramientas están disponibles.
7. Output: formato esperado.
8. Stop rules: cuándo abortar.

Fíjate en algo importante: ninguna de estas secciones prescribe la secuencia interna del modelo. Defines el contrato, no el proceso.

¿Por qué GPT-5.6 castiga los prompts contradictorios?

GPT-5.6 sigue instrucciones de forma más literal que sus antecesores. Cuando dos reglas se contradicen, no promedia ni elige la más segura: se vuelve impredecible.

De hecho, un prompt incompleto es más estable que uno lleno de contradicciones internas. Por eso conviene eliminar reglas repetidas con distintas palabras, instrucciones de estilo redundantes, ejemplos que no cambian comportamiento observable y descripciones de herramientas irrelevantes para la tarea actual.

Esto no es minimalismo estético, es supervivencia del prompt.

¿Qué antipatrones concretos debo eliminar?

Hay tres frases que parecen inocentes y arruinan el output:

• "Sé conciso": sumado al default de concisión del modelo, corta información necesaria. Reemplázalo con text.verbosity en la API y especifica qué conservar y qué recortar.
• "Think step by step": gasta tokens generando prosa que imita razonamiento sin activar la maquinaria real de reasoning, que se controla con el parámetro reasoning.effort.
• "Sé amigable": los labels amplios se interpretan de forma inconsistente. Cámbialos por comportamientos verificables, como si el usuario reporta un problema, acknowledges el issue específico antes de dar el siguiente paso.

¿Por qué "think step by step" ya no funciona en GPT-5.6? Porque genera prosa que simula razonamiento sin activar el motor real. Para forzar razonamiento profundo usa el parámetro reasoning.effort de la API.

¿Cómo cambia el tool calling en GPT-5.6?

Aquí hay una reversión directa respecto a la versión anterior. En 5.5, la guía oficial te animaba a narrar cada llamada a herramientas. La instrucción actual dice lo contrario: pide un preámbulo corto antes de la primera llamada, y luego actualizaciones escasas solo en cambios de fase mayor.

No pidas narración de llamadas rutinarias. Cuando fuerzas narración, pagas tokens extra por descripciones que no aportan nada y empujas al modelo hacia decoración verbal en lugar de resultados estructurados.

¿Qué necesita una definición de herramienta limpia?

Exactamente cuatro cosas, ni una más:

• Qué hace la herramienta.
• Cuándo usarla.
• Campos de retorno importantes.
• Comportamiento en caso de error.

Piénsalo como un job posting: rol, cuándo actuar, qué entrega y qué hacer cuando falla. No escribes una novela.

¿Por qué los prompts con lógica if-else fallan?

El error más común en producción es lockear cada paso con secuencias fijas y ramas if-else. Un modelo que podría encontrar una ruta más corta y correcta queda obligado a seguir cada giro que pre-mapeaste.

El fix es reemplazar lógica rígida con decision rules. Por ejemplo, en lugar de un árbol multi-branch, una sola oración funciona:

Después de cada resultado, pregúntate si el request ya puede responderse con evidencia útil. Si sí, responde. Si la evidencia sigue faltando, nombra el hecho faltante y usa el fallback más pequeño.

Reserva palabras como ALWAYS y NEVER para invariantes verdaderos: safety, campos requeridos y acciones prohibidas. Para todo lo demás, decision rules.

¿Cuándo sí conviene fijar el flujo desde la aplicación?

Hay tres escenarios claros donde el control lo lleva tu código, no el prompt:

• Cuando el data flow es predecible y no necesita creatividad del modelo.
• Cuando los resultados intermedios necesitan procesamiento en código antes de continuar.
• Cuando las acciones requieren un boundary de autorización que tu app controla.

Mide el impacto siempre: corre las mismas tareas con prompts prescritos y con prompts outcome-defined, y compara pass rates, latencia y costo por tarea.

¿Por qué la estructura del prompt equivale a un setting de effort?

El spread de 68x en costo documentado significa que la estructura del prompt es funcionalmente un setting de effort. Un prompt prescrito que fuerza mayor reasoning efectivo es lo mismo que subir el knob sin darte cuenta, y lo pagas en tu factura mensual.

En la siguiente entrega entramos a ventana de contexto, breakpoints y prompt caching, donde el acantilado de precio en 272,000 tokens se vuelve el factor dominante de tu costo. ¿Cuál de estos antipatrones estás usando hoy en tus prompts? Cuéntamelo en los comentarios.