Context engineering es solo decidir qué ve el modelo

Context engineering es decidir qué ve el modelo. Todo lo demás es detalle de implementación.

Cada tantos meses la industria acuña una palabra nueva para algo que ya era cierto. Context engineering es la última. La idea no está mal, y la etiqueta no es inútil. Lo que está mal es cómo se enseña el concepto: como una disciplina vecina del prompt engineering, un arte más suave, algo que se hace con palabras bien elegidas y una estructura cuidada. Ese enfoque se pierde la parte que de verdad importa.

La context window es un presupuesto rígido. Cada token que entra desplaza un token que querías conservar. Cuando se acaba el presupuesto, el agente no ve el principio de su propio plan, pierde el error que estaba persiguiendo y empieza a pedir cosas que ya leyó. Eso no es una falla del modelo. Es una falla de gestión. Context engineering es el trabajo de gestionar ese presupuesto, y es casi seguro que ya lo estás haciendo mal.

Llevo 25 años poniendo código en producción. A fines de 2025 construí solo una fintech cripto de 13 apps con agentes de IA en 70 días. Lo que más ajusté no fue el modelo, ni los prompts, ni la elección de herramientas. Fue lo que el agente podía ver en cada momento. Esto es lo que aprendí.

Context engineering no es prompt engineering

La gente confunde las dos cosas todo el tiempo, y la confusión les sale cara. Prompt engineering es el oficio de escribir bien un mensaje: la instrucción correcta, los ejemplos correctos, el enfoque correcto para un solo pedido. Context engineering opera a nivel de sesión. Gestiona todo el presupuesto de tokens a lo largo de todos los turnos, decidiendo qué se queda, qué se comprime, qué se saca y qué se carga de nuevo.

✗

Prompt engineering

1. 01Optimiza un solo mensaje
2. 02Se enfoca en la claridad de la instrucción
3. 03Alcance: un pedido
4. 04Resultado: un one-shot mejor
5. 05Ya está bien entendido

✓

Context engineering

1. 01Gestiona todo el presupuesto de tokens
2. 02Se enfoca en lo que ve el modelo
3. 03Alcance: toda la sesión
4. 04Resultado: tasa de tareas completadas
5. 05Donde están las ganancias reales

Un prompt mejor en una ventana llena no hace nada. El modelo no tiene dónde meterlo. Puedes escribir la instrucción más cuidada de tu vida y el agente igual va a alucinar la estructura de archivos que ya leyó, porque esa lectura está enterrada bajo veinte mil tokens de salida de tests que nunca necesitó. El presupuesto es la restricción. El prompt depende de él.

Dónde encaja el context engineering en el harness

Context engineering no existe por sí solo. Es una de las cuatro partes de lo que el harness engineering llama el sistema alrededor del modelo: el loop del agente, la interfaz de herramientas, la gestión de contexto y el control. La gestión de contexto es la tercera parte. Responde una pregunta en cada turno: de todo lo que podría entrar en la ventana, ¿qué debería entrar?

Las cuatro capas del harness

1. L1

   Loop del agente

   La orquestación que sigue llamando al modelo hasta que la tarea termina. Decide cuándo parar, cuándo reintentar, cuándo delegar. Context engineering no vive aquí, pero el loop determina cuántos turnos queman el presupuesto.

   +
2. L2

   Interfaz de herramientas

   Cada herramienta que el modelo puede llamar. El schema de la herramienta en sí cuesta tokens antes de que el modelo escriba nada. Un MCP server con 40 herramientas cargadas puede comerse entre 13k y 18k tokens solo en schema, antes de que corra un solo comando.

   +
3. L3

   Gestión de contexto

   Lo que ve el modelo en cada turno. Aquí vive el context engineering: comprimir la salida de las herramientas, compactar el historial, cargar memoria, sacar lo que ya no importa. Las decisiones de presupuesto pasan aquí.

   budget = window size
   spent = tool output + history + system + schemas
   available = budget - spent

   +
4. L4

   Control

   Los guardrails y checkpoints que evitan que el agente se desboque. Permisos, paradas con un humano en el loop, verificación antes de entregar. Importante, pero no es el tema de hoy.

Nombrarlo así importa. Si llamas “context engineering” a todo lo que va más allá de un prompt one-shot, pierdes la distinción entre curar la ventana (gestión de contexto) y diseñar el sistema que gestiona la ventana (harness engineering). Los dos son reales, y no son el mismo trabajo.

El presupuesto que ya estás excediendo

Aquí viene la parte incómoda. No tienes que hacer nada fuera de lo común para reventar la context window. El comportamiento por defecto de cualquier agente de IA de código la revienta por ti, automáticamente, en casi cualquier tarea que no sea trivial.

Hay cuatro fugas. Cada una es real, cada una tiene un costo de tokens medible, y casi todos los harnesses ignoran al menos dos.

Las cuatro fugas de contexto

1. 01

   Salida cruda de las herramientas

   Cada comando que corre el agente vuelca su salida completa en la ventana. Un git status en un repo con mucho movimiento son unos 2.000 tokens. Una corrida completa de tests, unos 25.000. El agente necesitaba los tres tests que fallaron, no los veintidós que pasaron.

   git status    ~2,000 tokens
   full test run ~25,000 tokens
   git log --all can exceed 10,000

   +
2. 02

   Historial repetido

   En cada turno se reenvía toda la conversación. El archivo que el agente leyó en el turno tres sigue ahí en el turno quince. El error que imprimió en el turno cuatro se volvió a imprimir en el turno siete. El modelo paga por releer todo eso, cada vez.

   same file x 5 reads = 5x the token cost
   error printed x 3 = 3x the token cost

   +
3. 03

   System prompt inflado

   Un system prompt largo cuesta tokens en cada turno porque va arriba de todo el contexto. pi, el agente de código minimalista, funciona con unas 150 palabras. Muchos harnesses comerciales usan diez veces eso, llenos de instrucciones que el modelo ya conoce por su entrenamiento.

   +
4. 04

   Schemas de MCP sin usar

   Los schemas de las herramientas se cargan en la ventana las llame o no el modelo. Un MCP server popular puede consumir entre 13.000 y 18.000 tokens de schema antes de que corra un solo comando. Carga solo las herramientas que de verdad necesitas en esta sesión.

   one MCP server  13k to 18k tokens
   two MCP servers 26k to 36k tokens
   both loaded regardless of usage

El desglose del costo en tokens tiene la cuenta completa. El punto aquí es más acotado: el context engineering empieza por saber cuál de estas cuatro fugas se está comiendo tu presupuesto. No puedes arreglar lo que no nombraste.

Las tácticas, una por fuga

Conocer las fugas no alcanza. Esto es lo que hay que hacer con cada una. No son opciones teóricas. Son los movimientos reales, en orden de retorno.

Comprime la salida de las herramientas en el origen. El cambio de mayor retorno en cualquier harness es un filtro sobre la salida de las herramientas. RTK es un proxy de CLI open source que se ubica entre el shell y el modelo. El agente corre un comando y RTK reescribe la salida antes de que llegue a la ventana. Filtrado inteligente, agrupación, deduplicación. En los comandos de desarrollo del día a día ahorra entre 60 y 90%. Un hook de shell lo vuelve invisible para el agente. Este es el que vale la pena copiar hoy.

Compacta el historial entre turnos. La capa de la conversación es el segundo arreglo. Entre turnos, deduplica las lecturas repetidas de archivos, reduce los pasos exitosos a un resumen de una línea, mantén intactos los turnos recientes y resume los viejos. El modelo ve el delta en lugar de la transcripción otra vez. No es una idea nueva. Es el mismo filtro de la capa de herramientas, aplicado un nivel más arriba.

Mantén el system prompt corto y específico. El enfoque minimalista de pi es instructivo. Unas 150 palabras, nada que el modelo no necesite saber. La teoría: un modelo de frontera ya entiende ingeniería de software, control de versiones e iteración cuidadosa. No hace falta explicárselo. Hace falta decirle qué es específico de tu proyecto. Cada línea de boilerplate en el system prompt es un impuesto en cada turno.

Carga solo las herramientas que necesita esta sesión. Cada MCP server que cargas al inicio cuesta tokens, lo uses o no. Cargar herramientas por sesión es el arreglo: empieza con el conjunto mínimo y agrega herramientas cuando el agente de verdad las necesite. Es una decisión de diseño del harness, no una decisión de modelo.

Movimientos de context engineering, en orden

• ✓Obligatorio:
  Comprimir la salida de las herramientas con un proxy de CLIRTK en github.com/rtk-ai/rtk. Open source, un hook de shell lo hace transparente. Recorta entre 60 y 90% en los comandos de desarrollo del día a día. Empieza aquí.
• ✓Obligatorio:
  Compactar el historial de la conversación entre turnosDeduplicar lecturas, resumir turnos viejos, mantener intactos los recientes. El modelo debería leer el delta, no la repetición.
• ✓Obligatorio:
  Auditar el system prompt en busca de boilerplateCorta todo lo que el modelo ya sabe por su entrenamiento. Lo que queda debería ser específico del proyecto: las convenciones, las decisiones, lo que el entrenamiento no puede saber.
• •Opcional:
  Cargar herramientas por sesión, no al inicioSolo las herramientas que esta sesión de verdad necesita. Agrégalas cuando el agente las pida, no antes. Cada schema que se carga cuesta tokens, las llame o no el modelo.
• •Opcional:
  Inyectar memoria al inicio de la sesión en lugar de volver a explicarDecisiones y convenciones del proyecto en un archivo AGENTS.md. El harness lo carga automáticamente. El agente empieza sabiendo en lugar de preguntando.

La tabla que lo hace concreto

Así se ve la misma sesión de código con un harness ingenuo y con uno con context engineering. Mismo modelo, misma tarea, mismas herramientas.

Contexto ingenuo vs. diseñado

Mismo modelo. Misma tarea. Uno se queda sin ventana. El otro no.

Ítem del presupuesto	Harness ingenuo	Harness diseñado
System prompt	5.000 a 10.000 tokens de boilerplate	150 palabras, solo lo específico del proyecto
Schemas de herramientas cargados	todos los servers, 15k a 30k tokens al inicio	por sesión, 2k a 4k tokens
Salida por llamada a herramienta	volcado crudo, 2k a 25k por comando	comprimida, 60 a 90% menos
Historial de la conversación	repetición completa en cada turno	solo el delta, turnos viejos resumidos
Memoria de la sesión	volver a explicar todo al inicio de la sesión	cargada automáticamente desde AGENTS.md
Resultado	ventana agotada a mitad de la tarea	presupuesto disponible para el trabajo real

Los números de la izquierda no son hipotéticos. Son lo que obtienes con la configuración por defecto. Pagas por una ventana de 200k tokens y quemas un tercio antes de que el agente escriba la primera línea útil.

Context engineering es un medio, no un culto

El discurso alrededor del context engineering agarró cierto sabor. La gente escribe como si una ventana bien gestionada fuera el objetivo. No lo es. El objetivo es terminar la tarea. La métrica es tokens por tarea terminada, no un presupuesto prolijo.

Esto importa porque curar de más también es un modo de falla. Comprime demasiado la salida de las herramientas y el modelo se pierde la señal de error que necesitaba. Resume el historial demasiado pronto y pierde el plan que estaba ejecutando. Saca de la ventana el archivo que está editando y lo reescribe a ciegas. Context engineering es un problema de calibración, no de minimización. La pregunta no es “qué tan chica puedo hacer la ventana” sino “¿tiene el modelo lo que necesita para dar el siguiente paso?”

El enfoque que me resulta útil: context engineering es gestión de presupuesto de un recurso fijo. No gastas cero en el súper porque gastar cero sea una virtud. Gastas lo que necesitas y evitas gastar en lo que no te alimenta. La sesión que termina la tarea en el turno ocho con la ventana a la mitad es un mejor resultado que la sesión que llega al turno treinta con un historial perfectamente compacto y ninguna tarea hecha.

La guía de harness engineering es donde esto se conecta con el sistema más amplio. La gestión de contexto es una de cuatro partes. Aislada, no es la más importante. Es la parte que determina si las otras tres pueden funcionar a lo largo de una sesión real en una codebase real.

Context engineering es decidir qué ve el modelo. Acierta esa decisión y el modelo hace lo que es capaz de hacer. Equivócate y estás pagando por una inteligencia que nunca vas a usar.

Preguntas frecuentes

¿Qué es context engineering en agentes de IA de código?+

Context engineering es la práctica de decidir qué tokens entran en la context window del modelo en cada turno de una sesión de agente. No se trata de escribir mejores prompts. Se trata de gestionar el presupuesto rígido de la context window: comprimir la salida de las herramientas, compactar el historial, mantener ajustado el system prompt y cargar solo las herramientas que la sesión de verdad necesita. El objetivo es que el modelo tenga lo que necesita para dar el siguiente paso sin gastar tokens en ruido que nunca va a usar.

¿En qué se diferencia el context engineering del prompt engineering?+

El prompt engineering optimiza un solo mensaje: la instrucción correcta, los ejemplos correctos, el enfoque correcto para un pedido. Opera en el alcance de una llamada.

El context engineering opera a nivel de sesión. Gestiona todo el presupuesto de tokens a lo largo de todos los turnos: qué se queda en la ventana, qué se comprime, qué se saca y qué se vuelve a cargar desde la memoria. Un prompt mejor en una ventana llena no hace nada. El presupuesto es la restricción, y el prompt engineering depende de él.

¿Cuáles son las mayores fugas de la context window en agentes de IA de código?+

Hay cuatro fugas principales. La más grande es la salida cruda de las herramientas: un git status son unos 2.000 tokens y una corrida completa de tests, unos 25.000. El agente necesitaba los tests que fallaron, no los que pasaron.

La segunda es el historial repetido: toda la conversación se reenvía en cada turno, así que un archivo leído en el turno tres sigue ahí en el turno quince, pagando su costo en tokens cada vez.

La tercera es un system prompt inflado: todo lo que el modelo ya sabe por su entrenamiento es un impuesto en cada turno. Deja solo lo que es específico del proyecto.

La cuarta son los schemas de MCP sin usar: cada server de herramientas cargado al inicio cuesta tokens, los llame o no el modelo. Un MCP server popular puede comerse entre 13.000 y 18.000 tokens antes de que corra un solo comando.

¿Cuál es la forma más rápida de reducir el uso de la context window en un agente de código?+

Comprimir la salida de las herramientas en el origen. RTK (github.com/rtk-ai/rtk) es un proxy de CLI open source que se ubica entre el shell y el modelo. El agente corre un comando y RTK reescribe la salida en una forma comprimida antes de que llegue a la context window. En los comandos de desarrollo del día a día ahorra entre 60 y 90%. Un hook de shell lo vuelve completamente transparente para el agente. Es el cambio de mayor retorno y el más fácil de conectar.

¿Cómo afecta el costo de los schemas de MCP a la context window?+

Cada MCP server que cargas inyecta el schema de sus herramientas en la context window al inicio de la sesión, antes de que el agente escriba nada. Un solo MCP server popular puede consumir entre 13.000 y 18.000 tokens de schema. Carga dos y gastaste entre 26.000 y 36.000 tokens antes de que corra un solo comando. El arreglo es cargar herramientas por sesión: empezar con el conjunto mínimo que la sesión de verdad necesita y agregar más solo cuando el agente lo pida. Cargar todas las herramientas disponibles al inicio es un default común y un desperdicio constante.

¿Es más importante el context engineering que elegir un modelo mejor?+

En la mayoría de las sesiones reales de código, sí. Un modelo mejor en una ventana llena igual falla la tarea cuando el archivo relevante salió de la ventana hace tres turnos. El context engineering determina si el modelo tiene la información que necesita para actuar. Con la capa de contexto funcionando, un cambio de modelo suma limpio encima. Antes de arreglar la capa de contexto, cambiar de modelo casi siempre solo paga el mismo desperdicio a un precio más alto.