¿Qué es context engineering? Todo lo que el modelo ve antes de responder | Cleon

Un modelo nunca ve tu codebase, tu CRM, tus intenciones, ni la última cosa que le dijiste hace cinco minutos a menos que alguna de esas haya entrado al context window — el bloque de tokens que el modelo lee antes de producir una sola palabra. Esa ventana es el mundo entero del modelo para esa llamada. Nada fuera de ella existe. Este es el hecho sobre el que gira todo en esta subcategoría, y reencuadra todo el trabajo. "Prompt engineering" significa, en sentido estrecho, las palabras que escribís en el prompt. Context engineering es la disciplina más amplia: decidir todo lo que entra en la ventana para una llamada dada — y eso, no la redacción de una instrucción, es la verdadera unidad de control.

El cambio es de redactar una oración a ensamblar un payload. Las palabras que tipeás son un input entre varios, y a menudo no el que decide si la respuesta es correcta. Esta página traza la línea, nombra todo lo que compite por espacio en la ventana, y expone el vocabulario sobre el que se apoya el resto de la subcategoría. Hacé bien el contexto y toda una clase de bugs que de otro modo le echarías al modelo simplemente deja de pasar (principio 2 — groundeá antes de generar, la misma lógica una capa más arriba).

Qué llena la ventana

Todo lo que el modelo lee para una llamada se ensambla en una sola ventana antes de que la llamada corra. Vale la pena nombrar las partes una vez, porque cada una es una decisión separada y cada una gasta del mismo presupuesto:

El system prompt — quién es el modelo para esta llamada, cuál es su trabajo, y las reglas que tiene que sostener. El rol, la tarea y los límites viven acá. Este es el texto con más palanca de la ventana, y la profundidad de escribirlo es system prompts e instructions.
Instructions — la tarea específica para esta llamada: qué hacer con el input, en qué formato, bajo qué restricciones. El system prompt fija las reglas permanentes; las instructions fijan el pedido inmediato.
Few-shot examples — ejemplos trabajados de input-y-output que ponés en la ventana para mostrarle al modelo la forma que querés, en vez de solo describirla. Dos buenos ejemplos a menudo le ganan a un párrafo de instrucción.
Retrieved context — hechos reales traídos en tiempo de query para que el modelo responda desde tus datos en vez de desde el entrenamiento. Esto es grounding, y es una disciplina en sí misma; su forma es qué es grounding.
Conversation history / state — lo que vino antes en un intercambio multi-turno, más cualquier estado de scratch que el sistema arrastra hacia adelante. En una conversación larga esta es la parte que crece en silencio hasta desplazar a todo lo demás.
Tool definitions — las funciones tipadas que el modelo tiene permitido llamar, cada una con un nombre, una descripción que lee, y argumentos que completa. Cada tool que exponés es texto en la ventana que el modelo tiene que leer antes de poder elegir; su diseño es tools y actions.
El input del usuario — la pregunta o el contenido real para este turno. La única parte que la gente piensa como "el prompt", y con frecuencia la tajada más chica de lo que el modelo realmente ve.

La lista es el punto. Cuando imaginás una llamada como solo "el prompt", optimizás una caja e ignorás las seis de alrededor. Cuando la imaginás como una ventana que comparten siete cosas, empezás a hacer las preguntas que importan: cuál de estas se gana su espacio, cuál falta, cuál está tan inflada que está enterrando al resto.

La ventana es finita, y está ordenada

Dos propiedades de la ventana gobiernan todo lo de aguas abajo. Primero, es finita. Hay un techo duro de cuántos tokens entran, y cada parte de arriba saca de ese único presupuesto — este es el principio 10, el contexto es un presupuesto, no un balde. Agregá un system prompt más largo y hay menos lugar para hechos recuperados. Dejá que la historia crezca sin límite y eventualmente desplaza a la instrucción que importa. Más no es mejor; pasado un punto es activamente peor, porque la señal que el modelo necesita se ahoga en el contexto que agregaste "por las dudas".

Segundo, la ventana está ordenada, y la posición carga peso. La misma instrucción no es igual de efectiva en todas partes. Una regla clave enterrada en el medio de una ventana larga queda subponderada — los modelos atienden de manera más confiable a lo que está cerca del arranque y cerca del final, y una instrucción crítica varada en el medio de diez mil tokens de historia puede ser efectivamente invisible. Así que context engineering no es solo qué entra en la ventana sino dónde y en qué orden — los mismos hechos acomodados distinto producen respuestas distintas.

Manejar esto de forma deliberada — medir cuánto cuesta cada parte, decidir qué guardar y qué soltar a medida que una conversación crece, ordenar para la atención — es una profundidad en sí misma: cómo se estructura la ventana, cómo se gasta el presupuesto de tokens, y cómo técnicas como prompt caching cambian la aritmética. Tratalo como la capa operativa debajo de esta página; conocela en profundidad más adelante en la subcategoría.

La mayoría de "el modelo se equivocó" es un problema de contexto

Acá está el encuadre honesto, y es la idea más útil de esta página: la mayoría de las fallas que la gente le cuelga al modelo son fallas de contexto, no de razonamiento. El modelo por lo general razonó bien — sobre una ventana a la que le faltaba la instrucción correcta, le faltaba el hecho recuperado, o estaba tan rellena que la señal que necesitaba se ahogó en ruido.

Este es el mismo patrón que el grounding nombra una capa más abajo. Cuando una respuesta groundeada es fluida pero está mal, qué es grounding te dice que sospeches del retrieval antes que del modelo — porque el modelo defendió una respuesta construida sobre los tres chunks equivocados. Context engineering lo generaliza: el retrieval es una de las cosas que llenan la ventana, y cualquier parte de la ventana puede ser la culpable. Una instrucción faltante, historia vieja, una tool definition malformada, el hecho correcto puesto donde el modelo lo subpondera — cada una produce una respuesta que parece una falla del modelo y no lo es. El mismo instinto aparece del lado del agente en gotchas de agentes, donde una respuesta equivocada con seguridad se rastrea a lo que se le pasó al agente. Hacé bien el contexto y el bug desaparece, porque nunca fue culpa del modelo.

Por eso "context engineering" es el nombre correcto para la disciplina y "prompt engineering" es un subconjunto de ella. La redacción importa, y las próximas páginas van en profundidad sobre eso. Pero la redacción de una instrucción perfecta que el modelo nunca alcanza — porque está enterrada, o porque el hecho del que depende nunca se recuperó — no arregla nada. La ventana es la unidad. Las palabras son una parte de ella.

El vocabulario

Esta subcategoría se apoya en un conjunto chico de términos. Acá están una vez, en simple; vas a conocer cada uno en profundidad a medida que la subcategoría avanza.

System prompt — las instrucciones permanentes para una llamada: rol, tarea, reglas, límites. Se fija una vez por llamada, sostiene por toda la llamada.
Instruction — el pedido específico para este turno: qué hacer, en qué formato, bajo qué restricciones. El pedido inmediato, distinto de las reglas permanentes.
Few-shot / multishot — poner ejemplos trabajados de input-output en la ventana para demostrar la forma que querés. "Few-shot" es un puñado de ejemplos; "zero-shot" es ninguno, solo instrucción.
Chain-of-thought — promptear al modelo para que razone paso a paso antes de responder, de modo que el desarrollo esté en la ventana y la respuesta final se pare sobre él en vez de llegar en frío.
Structured output — restringir al modelo a devolver una forma fija — JSON, un schema, un conjunto de campos — en vez de prosa libre, para que el código de aguas abajo pueda consumirlo de manera confiable. Su propia página es structured output.
Context window — el bloque finito de tokens que el modelo lee para una llamada. El contenedor que todo lo de arriba comparte.
Token budget — la contabilidad de ese espacio finito: cuántos tokens cuesta cada parte y cuántos quedan. Lo que estás gastando cuando agregás a la ventana.
Prompt caching — reutilizar el procesamiento que el modelo hace de un prefijo estable de la ventana entre llamadas, para que la parte que no cambia no se vuelva a pagar cada vez. La palanca que hace que un contexto grande y estable sea costeable de mandar repetidamente.

Cada uno de estos recibe una página o una sección propia a medida que la subcategoría avanza. Acá son solo las palabras, para que el resto se lea limpio.

A dónde ir después

Desde acá, la subcategoría construye hacia afuera desde la ventana que esta página encuadró. La parte con más palanca de ella — cómo escribir el system prompt y las instructions para que el modelo sostenga su trabajo y sus límites — es system prompts e instructions. Cuando necesitás que el modelo devuelva algo que el código pueda consumir en vez de prosa que un humano lee, eso es structured output. Y los modos de falla antes de chocártelos en producción — los bugs con forma de contexto que se disfrazan de fallas del modelo — están en gotchas de prompting.

La misma disciplina cruza plataformas como tools complementarias que un ingeniero compone, nunca un versus. El contexto que llena la ventana de un agente se ensambla de la misma forma ya sea que el agente corra en Agentforce dentro del modelo de seguridad de Salesforce o en la Claude API por fuera; las partes son idénticas, solo difiere la fuente de cada una. Las superficies específicas de plataforma están encuadradas en qué es un agente y las páginas de build de agentes a las que apunta.

System prompts e instructions — el texto con más palanca de la ventana: rol, tarea, reglas, y cómo escribirlas para que sostengan
Structured output — restringir al modelo a una forma que el código pueda consumir, no prosa que un humano lee
Gotchas de prompting — los modos de falla con forma de contexto — instrucciones enterradas, historia inflada, hechos faltantes — y cómo atraparlos
Qué es grounding — el retrieved context es una parte de la ventana; esta es la disciplina de hacerlo bien
Tools y actions — las tool definitions también son texto en la ventana; cómo diseñar las funciones que un modelo puede llamar
Gotchas de agentes — la misma lección del lado del agente: una respuesta equivocada con seguridad se rastrea a lo que se le pasó al agente
Style Guide de prompting — la vara que un prompt pasa antes de salir
Debuggear prompts — aislar la variable, después arreglar
Principios de AI Engineering — el contexto es un presupuesto no un balde (10), groundeá antes de generar (2), el modelo es la parte fácil (4)

Reference:

Qué llena la ventana

La ventana es finita, y está ordenada

La mayoría de "el modelo se equivocó" es un problema de contexto

El vocabulario

A dónde ir después

Related