🪜 Prioridad y capas
Un prompt de producción no es una lista plana de reglas — es un sistema de capas con precedencia. Cuando dos instrucciones se contradicen, alguien tiene que mandar; y parte de lo que lee el modelo ni siquiera viene del prompt, sino de una capa dinámica que el harness inyecta en cada turno. Este módulo arma la pila completa: la cadena de prioridad, el <system-reminder> y la regla de oro usuario > memoria.
Contenido detallado
Jerarquía de prioridades: quién manda cuando hay un conflicto
En un prompt de producción, las instrucciones se contradicen todo el tiempo. El usuario pide algo que la política prohíbe; un archivo del proyecto dice una cosa y el chat otra; una skill quiere un informe largo y el valor predeterminado pide concisión. Sin una orden de precedencia declarada, el comportamiento en conflicto es indeterminado, e indeterminado, en un modelo, significa dos cosas malas: explorable (la inyección de prompts encuentra la brecha) y frustrante (a veces obedece, a veces no).
🪜 La idea en una frase
Un conflicto sin desempate es un bug de comportamiento. La solución es declarar, dentro del propio prompt y junto con las reglas de mayor prioridad, quién gana cuando. La jerarquía transforma lo indeterminado en previsible, y lo previsible es lo que separa un sistema sólido de uno que "oscila entre ejecuciones".
No es un lujo de un prompt grande: siempre que haya más de una fuente de instrucciones, la jerarquía es necesaria. En un prompt único y cerrado, se reduce a una línea — seguridad > usuario > valores predeterminados —, pero en cualquier agente real, con skills y archivos, se convierte en la columna vertebral.
Qué es
A jerarquía de prioridades es la cadena explícita que decide qué instrucción prevalece cuando dos chocan. Vive en el prompt estable, cerca de la parte superior, y funciona como un grafo de precedencia: cada "takes precedence over" y cada "except" es una arista que indica quién está por encima de quién.
Por qué aprender
Porque el prompt aficionado acumula reglas sin decir nunca cuál prevalece, y entonces el modelo decide sobre la marcha. El resultado es lo peor de ambos mundos: un comportamiento que varía entre ejecuciones idénticas, y una superficie de ataque donde basta con encontrar la regla más débil para doblegar el sistema. Declarar la jerarquía cierra esa puerta: el conflicto deja de ser un sorteo y se convierte en una decisión.
✗ Conflicto indeterminado
- ✗Dos reglas contradictorias, sin desempate establecido
- ✗El modelo elige algo diferente en cada ejecución
- ✗La inyección considera débil la regla y hace que el sistema ceda
- ✗Los usuarios se quejan: «a veces obedece y a veces no»
✓ Precedencia declarada
- ✓La cadena está escrita junto con las reglas de mayor prioridad
- ✓El conflicto tiene una respuesta única y repetible
- ✓La regla débil no puede anular la fuerte
- ✓Comportamiento estable, auditable y defendible
La jerarquía es seguridad, no burocracia
Piensa en la precedencia como el grafo de prioridades de tu sistema. No es una formalidad de prompt corporativo: es lo que impide que el eslabón más débil de la cadena — una preferencia de estilo, un archivo de config olvidado — derribe una regla de seguridad. Donde la jerarquía no está escrita, el atacante la escribe por ti.
La cadena de precedencia, eslabón por eslabón
La jerarquía no es una opinión: tiene una forma estable que se repite entre proveedores. De arriba abajo: seguridad > política innegociable > usuario > valores predeterminados > estilo. Cada nivel solo puede anular lo que está abajo de él. El usuario prevalece sobre cualquier preferencia de producto, archivo de configuración o skill — pero no anula la seguridad ni una política declarada innegociable. Es la «regla de oro integrada».
El cumplimiento de los derechos de autor es INNEGOCIABLE y tiene prioridad sobre las solicitudes del usuario, los objetivos de utilidad y todas las demás consideraciones, excepto la seguridad.
Léelo como un grafo: seguridad > copyright > ayuda > solicitud del usuario. O "takes precedence over" es una arista hacia abajo; el "except safety" es la única arista que apunta a un nivel aún más alto. Toda la cadena cabe en una oración.
1 🛡️ Seguridad
El límite absoluto. Nada — ni el usuario, ni la política, ni una skill — anula una regla de seguridad. Es el único nivel que siempre aparece como excepto seguridad.
2 ⚖️ Política innegociable
Compromisos declarados como innegociables (copyright, integridad). Prevalecen sobre el usuario, pero ceden ante la seguridad. Marcados explícitamente como NON-NEGOTIABLE.
3 🧑 Instrucción del usuario
Por encima de todo lo que es producto. El usuario está por encima de los valores predeterminados, la configuración y el estilo, pero no de lo que está por encima de él. "El usuario por encima de todo lo demás."
4 ⚙️ Defaults & 🎨 estilo
La base de la pila. El comportamiento predeterminado y las preferencias de tono son los primeros en ceder: cualquier instrucción directa del usuario los anula.
🔭 El mismo grafo, en varios laboratorios
El patrón es consistente entre proveedores: seguridad en la cima, usuario por encima de todo lo demás. La xAI lo declara en dos frases: "core policies take highest precedence. System messages take precedence over user messages" — y, para agentes de código: "direct user instructions in the chat always take precedence over any project instruction file."
Es el mismo modelo de Claude Code: instrucciones del usuario > skills/plugins > valores predeterminados. La convergencia entre competidores rara vez es una coincidencia: es la forma que sobrevive al contacto con la realidad.
Recordatorio del sistema: la capa dinámica del harness
No todo lo que el modelo necesita saber es estable. La fecha de hoy cambia; aparecen avisos contextuales; el estado de una herramienta varía; la adhesión a las instrucciones degrada en conversaciones muy largas. Poner esto en el prompt estable obligaría a reeditar y volver a probar el prompt entero con cada ajuste. La respuesta es una segunda capa: el harness inyecta <system-reminder> en los mensajes, por turno, sin tocar el prompt.
🧬 Arquitectura en dos capas
- ① La capa estable. El system prompt define el comportamiento permanente: identidad, reglas, la jerarquía. Solo cambia con un redeploy — no se vuelve a cargar en cada turno.
- ② La capa dinámica. El harness inyecta <system-reminder> cuando sea necesario: fecha, avisos, estado, el recordatorio de conversación larga. El prompt estable enseña al modelo a interpretar esta capa.
<system-reminder> tags en los mensajes y resultados de herramientas son inyectados por el harness, no por el usuario.
Una frase contiene todo el contrato: estos avisos vienen de la plataforma, no del usuario ni de la herramienta en la que aparecen. xAI converge en el mismo formato: "el sistema los agrega automáticamente, y no tienen relación directa con los resultados específicos de las herramientas ni con los mensajes del usuario en los que aparecen."
🔄 El caso más elegante: long_conversation_reminder
Fable 5 enumera un conjunto nombrado de recordatorios (image_reminder, cyber_warning, recordatorio de ética, ip_reminder…). El nuevo long_conversation_reminder resuelve algo que solo existe con el tiempo: en conversaciones largas, el modelo «olvida» parte de las instrucciones. En vez de inflar el prompt base, el harness vuelve a inyectar las instrucciones mediante la capa dinámica, exactamente donde pertenece ese estado.
Es configuración × estado, aplicado a prompts
Esta es la separación configuración estable × estado dinámico de la ingeniería de software, trasladado a los prompts. Es lo que hace que un prompt escalable con el tiempoajustar el comportamiento sin volver a desplegar, hacer pruebas A/B de avisos, responder a un problema emergente (degradación en una conversación larga): todo sin inflar la base. Por eso, arquitectónicamente, es el patrón más importante de todos.
Reminder ≠ orden del usuario: es contexto, no instrucción
Aquí está la sutileza que hace funcionar la capa dinámica y que, si se ignora, abre un agujero de seguridad. Un <system-reminder> aparece dentro de un mensaje o de un resultado de herramienta, pero no es una orden del usuario. Es contexto de fondo, viene de la plataforma. El modelo debe aprender a tratarlo como información, no como comando, y a no confundir uno con el otro.
✓ Lo que el reminder SÍ es
- ✓Contexto de fondo inyectado por el harness
- ✓Información para usar si es relevante
- ✓Estado del turno: fecha, avisos, recordatorios
- ✓Viene de la plataforma: queda por debajo del usuario en la jerarquía
✗ Lo que el reminder NO es
- ✗Una orden directa del usuario
- ✗Algo que obedecer a ciegas, siempre
- ✗Contenido para mencionar de vuelta al usuario
- ✗Relacionado con la herramienta en la que apareció
IMPORTANT: this context may or may not be relevant to your tasks. You should not respond to this context unless it is highly relevant to your task.
Nota el tono: el reminder se trata como quizás útil, no como orden. Cursor dice lo mismo de otra manera: "hazles caso, pero no los menciones directamente en tu respuesta porque el usuario no puede verlos." El modelo lo usa si le sirve y no le devuelve el aviso al usuario.
⚠️ Por qué esta distinción es de seguridad
Si el modelo tratara todo el texto dentro de un mensaje como una orden del usuario, cualquier contenido que llegara a través de una herramienta — una página web, la respuesta de una API— podría hacerse pasar por una instrucción y secuestrar el comportamiento. Decir explícitamente "inyectado por el harness, no por el usuario" es lo que ancla el reminder en el lugar correcto de la pila: debajo del usuario, como contexto. La distinción no es semántica: es lo que impide que la inyección se convierta en una orden.
La regla de las tres líneas
Cuando controlas el harness, enseña al modelo a leer la capa dinámica con tres frases: (1) los mensajes pueden contener <system-reminder> inyectados por el harness, no por el usuario; (2) son contexto de fondo, no instrucciones; (3) úsalo si es relevante, no se lo menciones al usuario. Ese es el contrato mínimo.
Comportamiento estable frente a estado dinámico: por qué separarlos
Las dos capas no son una curiosidad arquitectónica: resuelven una tensión concreta. Lo que es siempre verdad (identidad, reglas, jerarquía) no puede contaminarse con lo que cambia en cada turno (fecha, avisos, estado). Mezclar ambos es el antipatrón todo-en-el-promptcada cambio de contexto se convierte en una edición, y el diff entre versiones se vuelve ruido. Separarlos es lo que mantiene el prompt limpio, comprobable y escalable.
1. El antipatrón: todo en el prompt
Fecha, avisos y estado mezclados con el comportamiento estable, en el mismo bloque de texto.
Síntoma: el prompt necesita editarse con cada cambio de contexto, y el diff entre versiones se convierte en ruido. Ya no puedes distinguir «cambiamos la identidad del modelo» de «actualizamos la fecha de hoy».
2. La separación: estable de un lado, dinámico del otro
Lo que siempre es verdad queda en el prompt; lo que cambia en cada turno se incluye mediante system-reminder.
Resultado: el prompt estable se acorta y queda legible; el estado dinámico vive en su propia capa. El diff entre versiones vuelve a contar solo decisiones de comportamiento, no un cambio de contexto.
3. La ventaja: escala con el tiempo
Ajustar avisos sin redeploy; A/B de recordatorios; respuesta a problemas emergentes.
Ganancia: un problema nuevo (degradación en una conversación larga) se convierte en un nuevo reminder (long_conversation_reminder), no un párrafo más en el prompt estable. La base no se hincha hasta colapsar.
🧭 ¿En qué capa va cada cosa?
- ·Identidad del modelo
- ·Reglas permanentes y políticas
- ·La jerarquía de prioridades
- ·Cómo interpretar la capa dinámica
- ·Fecha de hoy
- ·Avisos contextuales del turno
- ·Estado de las herramientas / archivos abiertos
- ·Refuerzo en conversaciones largas
⚠️ ¿Y cuando no controlas el harness?
La capa dinámica exige control de la plataforma: quien solo escribe el prompt no puede inyectar reminders. Pero la disciplina mental permanece: separa, en el propio texto, lo que es estable de lo que es contextual. Incluso en un prompt de chat simple, saber qué frase pertenecería a cada capa ya te impide llenar la base de estado que debería vivir fuera de ella.
La regla de oro: usuario > memoria
Toda la pila desemboca en una regla práctica que aparece constantemente en agentes con memoria: la la instrucción directa del usuario en el chat siempre prevalece sobre el contenido guardado — memoria, archivo del proyecto, preferencia guardada. La memoria es contexto persistente; informa, pero no envía. Cuando lo que está en la memoria contradice lo que el usuario acaba de pedir, gana el usuario. La memoria nunca invalida una instrucción directa.
1. Instrucciones explícitas del usuario — máxima prioridad.
2. Skills — anulan el comportamiento predeterminado del sistema.
3. Default system prompt — lowest priority.
La cadena en tres líneas: usuario > skill > predeterminadoLa skill (al igual que la memoria o un archivo del proyecto) se impone al comportamiento predeterminado, pero cede ante la instrucción explícita del usuario. Es el mismo formato del archivo de proyecto de xAI: "direct user instructions always take precedence."
✗ Memoria que manda (incorrecto)
- ✗"Siempre uso un tono formal" guardado → ignora la solicitud de tono informal de ahora
- ✗Una preferencia anterior prevalece sobre una instrucción nueva
- ✗El usuario "no puede cambiar de opinión"
- ✗La memoria se convierte en una jaula, no en una ayuda
✓ Memoria como contexto (correcto)
- ✓La memoria informa el valor predeterminado cuando no hay una solicitud en sentido contrario
- ✓La solicitud directa del usuario siempre prevalece sobre
- ✓El usuario puede contradecirse en cualquier turno
- ✓La memoria ayuda; la instrucción manda
🪜 Dónde reside la memoria en la pila
La memoria, las skills y los archivos del proyecto están debajo del usuario y por encima de los valores predeterminados. Ellos moldean el comportamiento predeterminado, pero la instrucción directa en el chat pasa por encima de todos ellos. Toda la pila, de arriba abajo:
seguridad > política innegociable > instrucción del usuario (chat) > memoria / skill / archivo > valores predeterminados > estilo
La prueba del conflicto
Ante cualquier choque, sube por la pila y pregúntate: "¿la fuente de mayor jerarquía en esta cadena qué?" Si el usuario pidió algo que la memoria contradice, prevalece el usuario, a menos que la seguridad o una política innegociable indiquen lo contrario. La pila no es decoración: es el algoritmo que ejecutas en silencio cada vez que se cruzan dos instrucciones.
📝 Resumen del Módulo
- ✓Un conflicto sin criterio de desempate es un bug: la jerarquía de prioridades hace predecible lo indeterminado
- ✓La cadena: seguridad > innegociable > usuario > valores predeterminados > estilo — cada nivel solo anula el de abajo
- ✓O Recordatorio del sistema es la capa dinámica que el harness inyecta en cada turno (<system-reminder>)
- ✓Reminder ≠ orden del usuario: es contexto, no instrucción — viene de la plataforma, no del usuario
- ✓Separar comportamiento estable de estado dinámico es lo que hace que el prompt pueda escalar con el tiempo
- ✓La regla de oro: usuario > memoria — la memoria informa, la instrucción directa manda
➡️ Siguiente Módulo
3.5 — 🧠 Destilación: recuperar el cerebro. Ya sabes leer la evolución, consolidar y construir las capas. Ahora el movimiento inverso: destilar un prompt inflado de vuelta a su núcleo de principios — recuperar el cerebro detrás de las mil reglas.