Qué es Context Engineering: por qué tu agente de IA piensa peor mientras más le cuentas

Llevas cuarenta minutos en la misma sesión con tu agente de IA. Al principio entendía todo a la primera. Ahora le pides algo simple y te devuelve una respuesta rara, como si hubiera olvidado una decisión que tomaron juntos hace diez mensajes. Le vuelves a explicar. Sigue sin agarrarla del todo.

Tu primer instinto es pensar que el modelo "se puso tonto". No es eso. Es que metiste tanta información en su cabeza que ya no sabe cuál de todo lo que le dijiste importa de verdad.

A resolver justo ese problema — y no solo a resolverlo, sino a evitar que pase desde el principio — se le llama Context Engineering. Y es, sin exagerar, la habilidad que conecta todo lo que ya vimos en blogs anteriores: agentes, subagentes, Skills, MCP y Spec-Driven Development son, en el fondo, herramientas distintas para hacer la misma cosa.

El chisme detrás del término

Esto no viene de un paper académico ni de un libro. Viene de Twitter, en junio de 2025.

Tobi Lütke, el CEO de Shopify, escribió que prefería el término "context engineering" sobre "prompt engineering", porque describe mejor la habilidad real: el arte de darle al modelo todo el contexto necesario para que la tarea sea resoluble.

Seis días después, Andrej Karpathy — uno de los fundadores de OpenAI — lo reforzó con la frase que terminó quedándose:

"Context engineering es el arte delicado y la ciencia de llenar la ventana de contexto con la información justa para el siguiente paso."

Ese comentario se volvió el nuevo consenso de toda la industria casi de un día para otro. Meses después, Anthropic — la empresa detrás de Claude — publicó su propia guía oficial confirmando lo mismo: el prompt engineering ya no alcanza. Ahora se trata de manejar todo lo que rodea al prompt.

Prompt engineering vs. Context engineering: no es lo mismo

Aquí está la confusión más común, así que vamos a aclararla de una vez:

	Prompt Engineering	Context Engineering
Qué controla	Cómo redactas la instrucción	Qué información tiene disponible el modelo
Se preocupa por	El fraseo, el tono, la claridad de una pregunta	El system prompt, las herramientas, la memoria, el historial, los documentos recuperados
Funciona bien en	Una pregunta suelta a un chatbot	Un agente que trabaja en bucle, por varios pasos, con herramientas
Analogía	Escribir bien un mensaje	Decidir qué carpetas, notas y personas están en la sala antes de mandar el mensaje

El prompt engineering es un subconjunto del context engineering, no su reemplazo. Un prompt perfecto no salva a un agente que tiene el contexto equivocado — igual que una pregunta bien hecha en una reunión no sirve de nada si nadie en la sala tiene la información para responderla.

La analogía que lo explica todo: el LLM como sistema operativo

Karpathy también dejó el modelo mental que hoy usa toda la industria para pensarlo: el LLM es como una computadora nueva.

• El modelo es el CPU — el que procesa.
• La ventana de contexto es la RAM — memoria de trabajo, limitada, y cara de usar.

Nadie mete el disco duro entero en la RAM de una computadora. Se elige qué cargar en cada momento, según lo que se necesita hacer ahora. Con un agente de IA pasa exactamente lo mismo: no metes todo el codebase, todo el historial de chat y todos los documentos de una — eliges, en cada paso, qué merece estar ahí.

Context engineering es, literalmente, ser el que decide qué entra a esa RAM.

La prueba de que esto no es solo teoría: "Context Rot"

Aquí está el dato que hace que esto deje de sonar abstracto.

En julio de 2025, un equipo de investigadores de Chroma probó 18 de los modelos más avanzados que existen — entre ellos GPT-4.1, Claude 4 y Gemini 2.5 — y encontró algo que va contra lo que uno esperaría: entre más contexto le metes a un modelo, peor razona sobre él, incluso mucho antes de llenar la ventana completa.

No importa que un modelo diga que soporta 1 millón de tokens. Eso no significa que razone igual de bien con el token 900,000 que con el token 5,000. El estudio lo llamó context rot — literalmente, "pudrición del contexto": el rendimiento se degrada gradualmente mientras el input crece, aunque técnicamente todavía quepa.

Esto es la razón real por la que tu agente "se vuelve tonto" después de cuarenta minutos. No perdió capacidad. Está nadando en más información de la que puede usar bien.

Los 4 modos en que un contexto se arruina

Un investigador llamado Drew Breunig catalogó las formas más comunes en que esto sale mal. Vale la pena conocerlas porque, apenas las nombras, las vas a reconocer:

Context Poisoning (el contexto envenenado). Una alucinación entra al contexto en algún momento — el agente inventó un dato — y como quedó escrita ahí, el agente la sigue usando como si fuera verdad en cada paso siguiente. Es como cuando alguien dice un rumor en una reunión, nadie lo corrige, y para la tercera reunión ya todo el equipo lo repite como hecho.

Context Distraction (el contexto que distrae). El historial creció tanto que el modelo empieza a sobre-enfocarse en él, en vez de usar lo que ya sabe por entrenamiento. Es el equivalente a alguien tan metido en los detalles de una conversación larga que pierde de vista el sentido común más básico.

Context Confusion (el contexto que confunde). Metiste información de más, que no tenía nada que ver con la tarea, y el modelo la usa igual para armar su respuesta — bajando la calidad sin que hiciera falta. Como preguntarle algo puntual a alguien mientras le lees en voz alta un documento entero que no viene al caso: te va a responder peor que si solo le hubieras dado lo relevante.

Context Clash (el contexto que choca). Se acumuló información contradictoria en distintos momentos de la conversación — dijiste una cosa al principio, la cambiaste después, y ambas versiones siguen ahí. El modelo no sabe cuál de las dos obedecer.

Las 4 estrategias para evitarlo (y ya las conoces)

Aquí es donde todo lo que viste en los blogs anteriores se conecta. La industria resume el trabajo de context engineering en cuatro verbos — Write, Select, Compress, Isolate — y resulta que Zeew ya te enseñó una herramienta concreta para cada uno.

Estrategia	Qué significa	Dónde ya lo viste
Write (escribir)	Guardar contexto fuera de la ventana para que no se pierda	Una spec de Spec-Driven Development. La decisión queda escrita en un archivo, no flotando en la memoria de la conversación.
Select (seleccionar)	Traer solo la información correcta en el momento correcto	Un Skill. El agente no carga las instrucciones completas hasta que la tarea realmente las necesita.
Compress (comprimir)	Resumir lo que ya está en el contexto para liberar espacio	La compactación automática que hacen Claude Code y OpenCode cuando la conversación se acerca al límite.
Isolate (aislar)	Separar el trabajo en ventanas de contexto distintas	Un subagente. Explora, investiga o revisa en su propio espacio, y solo devuelve un resumen — el resto del ruido nunca llega a tu conversación principal.

Dicho de otra forma: cuando armaste tu primer subagente de revisión de código, ya estabas haciendo context engineering. Cuando escribiste tu primera spec, también. No era un concepto nuevo — era la teoría detrás de cosas que ya sabías hacer.

Un ejemplo real, con número real: cuando el propio AGENTS.md se convierte en el problema

Este caso pasó de verdad, y es perfecto porque el error viene justo de la herramienta que se supone que ayuda al agente.

El archivo AGENTS.md — el mismo que le explica al agente cómo trabajas en tu proyecto — está pensado para ser breve. Pero hubo un reporte real en el repositorio de OpenCode de un archivo AGENTS.md de 331 KB, cerca de 83,000 tokens. Con una ventana de 128,000 tokens disponibles, ese solo archivo se comía el 81% del espacio disponible — antes de que el agente hiciera absolutamente nada. La sesión entraba en compactación en el primer turno, sin haber avanzado un solo paso.

La instrucción pensada para darle claridad al agente terminó siendo el ruido que lo distrajo. Por eso la recomendación real, la que ya circula entre quienes trabajan con estas herramientas todos los días, es mantener el AGENTS.md corto — la mayoría lo aconseja por debajo de 100 líneas — y mover todo lo demás a archivos de referencia que el agente abre solo si de verdad los necesita.

Es el mismo principio de las carpetas references/ que ya vimos en el blog de Skills, aplicado al archivo de memoria completo de tu proyecto.

Cómo se ve esto en un sistema con orquestador y subagentes

Aquí es donde context engineering deja de ser teoría y se vuelve arquitectura.

Cuando un núcleo orquestador coordina a varios subagentes por fase — como en cualquier sistema multiagente bien armado — lo que realmente está pasando es una aplicación disciplinada de las cuatro estrategias al mismo tiempo:

• El orquestador escribe el plan general en un lugar persistente, no lo mantiene solo "en su cabeza".
• Cada subagente selecciona únicamente las herramientas que su fase necesita — ni una más.
• El resultado que cada subagente entrega ya viene comprimido: un resumen de mil o dos mil tokens, no el proceso completo de exploración.
• Todo el trabajo intermedio queda aislado en la ventana de contexto de cada subagente, sin ensuciar la conversación principal.

Anthropic probó esto con su propio sistema de investigación multiagente y encontró una mejora de más del 90% frente a usar un solo agente para todo. La razón no fue que los subagentes fueran "más inteligentes" — fue que cada uno trabajaba con exactamente el contexto que necesitaba, ni de más ni de menos.

Un checklist rápido para auditar tu propio contexto

Antes de armar tu próximo Skill, subagente o spec, hazte estas cuatro preguntas — una por cada estrategia:

# Auditoría rápida de contexto

- [ ] Write: ¿esta decisión importante está escrita en algún lado,
      o solo existe en la conversación de ahora?
- [ ] Select: ¿el agente tiene acceso solo a lo que esta tarea
      necesita, o le di acceso a todo "por si acaso"?
- [ ] Compress: si esta conversación sigue diez mensajes más,
      ¿el agente todavía va a recordar lo importante?
- [ ] Isolate: ¿esta tarea genera mucho ruido de exploración que
      no necesito ver? Si sí, ¿debería ir a un subagente?

No hace falta contestar las cuatro cada vez. Pero cuando algo empiece a sentirse raro — el agente "se olvida" cosas, contradice algo que ya habían decidido, o simplemente responde peor que al principio — este es el primer lugar donde hay que mirar. Casi nunca es el modelo. Casi siempre es el contexto.

Y ahora que le pusiste nombre a la disciplina completa, la próxima vez que armes un Skill, un subagente o una spec, lo vas a estar haciendo con la teoría detrás, no solo por instinto.