Dónde ubicar cada dato en tu system prompt

¿Dónde pones una pieza nueva de información cuando diseñas un asistente con IA? Esa decisión, aparentemente menor, provoca más desastres en sistemas reales que casi cualquier otro error. El mismo dato en el lugar equivocado puede saturarte el contexto, desaparecer cuando lo necesitas o contradecir otra instrucción.

El objetivo es simple: salir con un árbol de decisión que apliques sin pensarle demasiado, como si programaras condiciones. Si esto, entonces esto. Esto le sirve a cualquiera que construya asistentes, agentes o flujos con modelos de lenguaje y quiera dejar de improvisar dónde va cada dato.

Cuáles son los cinco lugares donde puede vivir la información

Toda información termina en uno de cinco destinos, y cada uno tiene su criterio de entrada [00:36]. La clave no es qué tan importante es un dato, sino cada cuándo cambia y cada cuándo se necesita.

• System prompt: identidad, restricciones duras y formato. Aplica siempre, sin excepción.
• User prompt: la tarea de este momento. Cambia a cada turno.
• Memoria: preferencias, decisiones y estado del proyecto. Sobrevive durante la sesión.
• Herramientas: datos que cambian, son enormes o volátiles. Es lo que no cabe o no para de moverse.
• Base de conocimiento: documentación estable y voluminosa que solo se necesita en algunas ocasiones.

Fíjate en el patrón: el criterio siempre gira alrededor de frecuencia de cambio y frecuencia de uso, nunca de relevancia percibida.

¿Qué diferencia hay entre memoria y base de conocimiento? La memoria guarda datos que cambian y deben sobrevivir a la sesión, como el estado de un proyecto. La base de conocimiento guarda documentación estable y grande que solo consultas de vez en cuando.

Cómo funciona el árbol de decisión para ubicar cada dato

Piénsalo como programador, con lógica condicional [01:30]. Ante cualquier dato nuevo, respondes preguntas en cadena hasta llegar a un destino.

1. ¿Aplica a toda la interacción? Si cabe en pocas líneas, va al system prompt. Si es larga, va a un archivo o skill referenciado que se carga solo cuando hace falta.
2. Si no aplica a todo, ¿cambia con el tiempo? Si cambia y la necesitas ahora, se agrega como herramienta. Si cambia pero no la necesitas ahora, no la traigas.
3. Si no cambia con el tiempo, ¿debe sobrevivir a la sesión? Si sí, va a memoria. Si no, queda en el user prompt.

Con estas tres preguntas cubres cualquier pieza de información sin adivinar.

Cómo se ve el árbol aplicado a una tienda de electrónica

Con cinco datos reales el árbol se vuelve evidente [02:47]:

• Responder en español neutro y nunca prometer fechas de entrega: aplica siempre, va al system prompt.
• El cliente ya reportó el mismo problema tres veces: debe sobrevivir a la sesión, va a memoria.
• Cuántas unidades quedan de un modelo: cambia cada hora, va a herramientas.
• El manual de herramientas de 12.000 palabras: estable y enorme, va a base de conocimiento.
• "Ayúdame a redactar este ticket": es de este turno, va al user prompt.

Una vez que ves los cinco casos separados, cuesta volver a mezclarlos.

Por qué meter el manual completo al system prompt es el peor error

El error más común es cargar ese manual de 12.000 palabras al system prompt "para tenerlo a la mano" [03:35]. El problema es que gastas tu presupuesto de atención en algo que solo se usa en el 5 % de los casos.

Esta idea, según la clase, ha salvado sistemas enteros y le ha ahorrado mucho dinero a las empresas. Es el aprendizaje que conviene no soltar.

¿Dónde van las instrucciones de cómo usar una herramienta? Van en la descripción de la herramienta, nunca en el system prompt. Si las pones en los dos lados, tarde o temprano actualizas uno y olvidas el otro, y ahí nacen las contradicciones.

Ese origen duplicado explica un caso anterior donde una regla decía "deja documentación según sea apropiado" en un lugar y "no agregues comentarios" en otro [04:23]. Nadie las escribió juntas ni las leyó juntas, así que el modelo tuvo que vivir con ambas.

Qué recomienda Anthropic sobre instrucciones, skills y referencias

El artículo más reciente de Anthropic aporta tres reglas prácticas [04:52] que refinan cómo escribes el contexto.

• Instrucciones del proyecto ligeras: gasta tokens en los gotcha, esos momentos de "claro, es eso", no en lo obvio.
• Guías y skills sin sobrerestringir: su valor está en codificar tu criterio, no en amarrar al modelo.
• Referencias en código: el modelo prefiere mil veces un mockup en HTML que una descripción larguísima.

La lógica de fondo es la misma del árbol: pon cada cosa donde rinde, no donde parezca cómodo.

Cómo construir tu mapa de fuentes de contexto

El reto es armar un mapa de fuentes de contexto de un asistente que uses o un caso hipotético [05:23]. Sirve para detectar qué tienes mal ubicado hoy.

1. Crea una tabla con cuatro columnas: información, destino, por qué y vigencia.
2. Lista entre 8 y 12 piezas de información que ese asistente necesita.
3. Pasa cada pieza por el árbol de decisión y asígnale un destino.
4. Marca en rojo las que hoy están en el lugar equivocado.
5. Mueve una sola pieza roja a donde le toca y úsala tres días así.

Ese cuarto paso, el de mover y probar, es donde empiezas a ver cambios reales. Elige la instrucción que más te esté doliendo, casi siempre es algo que repites en cada sesión y que debería vivir en el proyecto entero. Guarda esta tabla: es una de las cinco piezas de tu entregable final.

¿Qué dato de tu asistente sospechas que está en el lugar equivocado? Cuéntamelo y revisémoslo juntos.