System messages tool calling y rituales obsoletos

Contenido del curso

No sé dónde empezar

Elegir modelo y modo de razonamiento correcto

Promptear GPT-5.6 según la doctrina oficial

Contexto largo caching y cálculo de costos

Decisión entre proveedores y migración segura

Disciplina epistémica riesgos y limitaciones reales

10
Verificación de datos riesgos y limitaciones reales
06:55 min

Tomar examen

Cursos Empresas Blog Live Conf Eventos Precios

0:004:53

System messages tool calling y rituales obsoletos

Curso de GPT-5.6

Clase 5 de 10

Clase 5 / 10

Recursos

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:

Role: quién es el modelo.
Personality: tono base.
Goal: qué debe existir al final.
Success criteria: cómo verificar que se logró.
Constraints: qué no puede pasar.
Tools: qué herramientas están disponibles.
Output: formato esperado.
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.

Resumen

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

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:

Role: quién es el modelo.
Personality: tono base.
Goal: qué debe existir al final.
Success criteria: cómo verificar que se logró.
Constraints: qué no puede pasar.
Tools: qué herramientas están disponibles.
Output: formato esperado.
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.

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?

¿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 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?

Comentarios (4)4 comentarios

Adrián Soto Girón

Hace 3 meses

siento que ya estamos en el loop XD, entramos a repetir las cosas, sólo decirlo de otra forma.

Diomar Gerardo Milla Blair

Para cuando se viene un curso de Lean Prompting? Pues más que una evolución del Prompt vemos que casi que lo contradice todo al Prompt Engineer como lo conocemos.

Patricio Sánchez Fernández

Hace 2 meses

Muy buen punto, Diomar. Chequeando este curso, queda la sensacion de haber cambiado practicamente todo, son nuevas reglas.

Juan Camilo Mejía Rodríguez

Me confundes, entonces no tendría que revisar cada 5kilometros sino que él sepa qué sería correcto en cada uno de esos tramos?

Exacto. No eres tú quien revisa, es el modelo quien ejecuta una autoevaluación. En lugar de forzar paradas, le das una definición de "hecho" para cada módulo. Él compara su resultado actual contra ese estándar y, si no coincide, ajusta su rumbo sin que tú muevas un dedo.

Si el modelo tiene claro qué constituye un "éxito" técnico, ¿por qué necesitaría que tú le indiques cuándo detenerse?

¿Cuándo nos enseñaran sobre los loops?

Elegir modelo y modo de razonamiento correcto

Sol Terra Luna especificaciones y parámetros

Selección de modelo por escenario de producción

Reasoning effort max Pro Ultra y subagentes

Promptear GPT-5.6 según la doctrina oficial

Lean prompting doctrina oficial y mitos

System messages tool calling y rituales obsoletos

Contexto largo caching y cálculo de costos

Ventana de contexto breakpoints y prompt caching

Tarifas recargos y cálculo de costos reales

Decisión entre proveedores y migración segura

GPT-5.6 Sol versus Claude Fable 5 por tarea

Migración de prompts agénticos entre ecosistemas

Disciplina epistémica riesgos y limitaciones reales

Verificación de datos riesgos y limitaciones reales

System messages tool calling y rituales obsoletos

Progreso del curso

Elegir modelo y modo de razonamiento correcto

Promptear GPT-5.6 según la doctrina oficial

Contexto largo caching y cálculo de costos

Decisión entre proveedores y migración segura

Disciplina epistémica riesgos y limitaciones reales

Recursos

Recursos