EN

Context engineering: la habilidad que sustituyó al prompt engineering

Context engineering es gobernar qué ve el modelo en cada paso, no pulir el prompt. Técnicas, coste del cache y compromisos, con datos verificados.

· 16 min lectura

Colaboradores: Ivan Garcia Villar

Context engineering: la habilidad que sustituyó al prompt engineering

Tu agente funciona perfecto los primeros diez turnos. En el turno treinta empieza a repetir trabajo que ya hizo, olvida una decisión que tomó veinte llamadas a herramientas atrás y se contradice sin pestañear. Y lo raro es que el prompt está pulido al milímetro. El problema no está en lo que escribiste tú: está en todo lo demás que se fue acumulando en la ventana. En 2026 la habilidad que separa a quien dirige agentes de quien los sufre ya no es redactar el prompt perfecto. Es gobernar qué ve el modelo en cada momento. Eso es context engineering.

¿Qué es context engineering (y qué no es)?

Context engineering es el conjunto de estrategias para seleccionar y mantener el conjunto óptimo de tokens que ve un modelo durante la inferencia, incluida toda la información que acaba en la ventana y que no escribiste como prompt. Esa es, casi textual, la definición de Anthropic [1]. La clave está en las dos últimas palabras: outside of the prompts. El prompt es una parte de lo que entra; no es todo. Y parte de lo que entra ni siquiera lo escribiste tú: las instrucciones de una skill instalada o las definiciones de herramientas de un servidor MCP también son tokens de terceros en tu ventana, un flanco que analizo en seguridad de skills y MCP.

Andrej Karpathy lo resumió mejor que nadie: es “the delicate art and science of filling the context window with just the right information for the next step” [2]. Tobi Lütke, CEO de Shopify, prefiere el término sobre “prompt engineering” porque describe mejor la habilidad central: dar todo el contexto necesario para que la tarea sea “plausibly solvable by the LLM” [2]. Y el equipo de Cognition, que construye Devin, lo lleva al terreno operativo: hacer esto de forma automática en un sistema dinámico es “the #1 job of engineers building AI agents” [3].

Que quede claro qué NO es. No es escribir un prompt más largo. No es meter toda la documentación del proyecto en el system prompt “por si acaso”. Ese reflejo, precisamente, es el que degrada al agente.

Prompt engineering vs context engineering: instancia frente a sistema

La diferencia es de horizonte temporal, no de dificultad. Anthropic define prompt engineering como los métodos para escribir y organizar instrucciones que produzcan el mejor resultado [1]: optimizas una instrucción, una vez, para un resultado. Context engineering gobierna lo que el sistema ensambla en cada paso del bucle: instrucciones, historial, resultados de herramientas, notas de memoria y salidas de subagentes. El prompt lo escribes tú. El contexto lo construye tu sistema, turno tras turno, y ahí es donde se degrada.

DimensiónPrompt engineeringContext engineering
Qué optimizala instrucción: redacción, ejemplos, formatoel conjunto total de tokens que ve el modelo
Horizonteuna instancia puntual, un mensajeun sistema en el tiempo, cada paso del bucle
Artefactoel promptla ventana entera: instrucciones, historial, resultados de herramientas, memoria y salidas de subagentes
Fallo típicorespuesta mal dirigida en el primer turnodegradación acumulada: context rot, decisiones olvidadas, coste disparado
Relaciónsubconjuntosuperconjunto: el prompt es una parte de lo que entra en la ventana

Esto no jubila al prompt engineering. Todo lo que sabías sobre escribir instrucciones claras sigue valiendo, y lo tienes recopilado en los patrones esenciales de prompt engineering; solo que ahora es una pieza dentro de un problema más grande. Ese “sistema en el tiempo” es el bucle agéntico, donde el contexto crece y se pudre turno a turno. Si quieres el modelo mental del bucle, lo desarrollo en loop engineering.

¿Por qué más contexto no es mejor contexto?

Porque el modelo no lee la ventana de forma uniforme, y hay evidencia dura de ello. El paper “Lost in the Middle” (Liu et al., 2023) demostró que el rendimiento es más alto cuando la información relevante está al principio o al final del contexto, y “significantly degrades when models must access relevant information in the middle of long contexts” [4]. Es una curva en U: lo que pones en medio de un contexto largo, el modelo lo mira peor.

No es un artefacto de 2023. El informe Context Rot de Chroma evaluó 18 modelos actuales, incluidos GPT-4.1, Claude 4 y Gemini 2.5, y concluyó que su rendimiento “grows increasingly unreliable as input length grows” [5]. Un hallazgo suyo es especialmente incómodo: en LongMemEval, los modelos Claude rindieron mejor con prompts enfocados que con prompts completos que contenían la misma información relevante. Mismo dato útil, más ruido alrededor, peor resultado.

Anthropic pone el marco: los modelos tienen un “attention budget” finito, como la memoria de trabajo humana, así que el contexto es “a finite resource with diminishing marginal returns” [1]. Cuando la ventana crece de más aparece el context rot: cuantos más tokens acumula, peor recuerda el modelo la información que contiene [1].

Trata la ventana como working memory, no como un disco duro. Esa es la postura de todo este post: el contexto es un presupuesto que gastas con cada token, no un almacén donde acumular por si acaso. Si la ventana de contexto todavía te resulta un concepto algo abstracto, la base la tienes en ventana de contexto y buenas prácticas, y en el curso Patrones de Diseño para Agentes de IA se practica de forma interactiva junto al resto de fundamentos del LLM.

La economía del contexto: cuánto cuesta cada token

El contexto no solo degrada la calidad: cuesta dinero, y de forma contraintuitiva. Con prompt caching, leer del cache cuesta 0,1× el precio de input, pero escribir en él cuesta 1,25× para un TTL de 5 minutos y 2× para uno de 1 hora, según los precios oficiales de Anthropic [6]. Reutilizar contexto cacheado es baratísimo, pero cada vez que rompes el cache pagas una prima para volver a escribirlo.

Por eso Manus, tras construir un agente de producción, afirma que “the KV-cache hit rate is the single most important metric for a production-stage AI agent” [7]. Con Claude Sonnet ponen el número: un token de input cacheado cuesta 0,30 USD/MTok frente a 3 USD/MTok sin cachear, una diferencia de 10×. Y el detalle que lo hace caro de verdad: en Manus el ratio medio input:output ronda 100:1, y una tarea típica requiere unas 50 llamadas a herramientas [7]. Cada turno reenvía todo el historial anterior. El input domina la factura.

La derivada de diseño es directa: contexto append-only y prefijo estable. Cualquier byte que cambie al principio del contexto invalida el cache de todo lo que viene detrás. Un senior lo reconoce al instante: es localidad de cache, la misma que gobierna el rendimiento de cualquier sistema con jerarquía de memoria.

// El prefijo del contexto debe ser estable: un byte que cambie al
// principio invalida el cache de todo lo que viene detrás.
// Leer del cache cuesta 0,1× el precio de input; escribirlo 1,25×-2×.

// MAL: timestamp mutable al inicio → cada turno reescribe todo el cache
const prefijoRoto = [
  { role: "system", content: `Hora: ${Date.now()}. Eres un agente...` },
  ...historial,
];

// BIEN: prefijo estable; lo volátil se añade al final (append-only)
const prefijoEstable = [
  { role: "system", content: "Eres un agente..." },     // nunca cambia
  ...historial,                                          // solo crece por el final
  { role: "user", content: `Contexto de sesión: ${sesion}` },
];

Que los tokens sean dinero no es exclusivo de los agentes. El mismo peaje aparece cuando eliges el idioma en el que hablas con el modelo, algo que cuento en el impuesto del idioma.

¿Qué técnicas concretas existen y qué compromiso tiene cada una?

Gobernar el contexto se reduce a cuatro técnicas. Cada una resuelve un problema distinto y sacrifica algo distinto.

Mapa de las cuatro técnicas de context engineering en el bucle del agente: la tarea entra en la ventana de contexto, que se conecta con compactación (historial al límite → resumen comprimido), recuperación just-in-time (consulta bajo demanda → fragmento relevante), memoria externa en fichero (notas y plan → plan recitado al final) y subagente aislado (subtarea acotada → síntesis)

TécnicaQué resuelveCompromisoCuándo usarla
Compactaciónhistorial que desborda la ventanacomprimir es fácil; decidir qué conservar, noconversaciones largas que se acercan al límite
Memoria externa (ficheros)estado que no cabe o no debe vivir en la ventanael agente debe acordarse de leerlo; más E/S por turnoplanes, hallazgos y decisiones que persisten entre turnos
Subagentes (aislamiento)una ventana que acumula ruido de varias tareascoordinación y coste en tokens (~15× vs. chat)tareas paralelizables de solo lectura
Just-in-time retrievalprecargar datos que quizá no uses nuncalatencia y fallos de recuperacióncorpus grande donde solo una fracción es relevante por turno

Compactación: resumir para reiniciar

La compactación toma una conversación cercana al límite de la ventana, resume su contenido y reinicia una ventana nueva con ese resumen [1]. Suena trivial y no lo es. Comprimir bytes es fácil; decidir qué información conservar es el problema difícil. Cognition, que introdujo un modelo dedicado solo a comprimir el historial de acciones y decisiones, lo admite sin rodeos: “This is hard to get right” [3].

Cuando se hace bien, los números lo justifican. El context editing, que borra automáticamente llamadas a herramientas y resultados obsoletos al acercarse al límite de tokens, mejoró un 29% sobre baseline en la eval agéntica de Anthropic; combinado con el memory tool (almacenar y consultar información en ficheros fuera de la ventana), un 39%; y en una evaluación de búsqueda web de 100 turnos redujo el consumo de tokens un 84% [8].

Memoria externa: ficheros como estado

Si el estado no cabe en la ventana, sácalo de la ventana. Anthropic lo llama structured note-taking o agentic memory: el agente escribe notas de forma regular en una memoria persistente fuera del contexto [1]. Manus lo lleva al extremo y trata el sistema de ficheros como “the ultimate context: unlimited in size, persistent by nature, and directly operable by the agent itself” [7].

Aquí aparece la técnica que cierra el círculo con la curva en U. Manus reescribe un todo.md en cada turno, empujando el plan al final del contexto para llevarlo “into the model’s recent attention span, avoiding ‘lost-in-the-middle’ issues” [7]. Recitar los objetivos al final los mantiene en la zona que el modelo lee mejor.

// Recitación: reescribe el plan al FINAL del contexto en cada turno.
// Empuja los objetivos a la atención reciente y esquiva la curva
// en U de "Lost in the Middle".
async function turno(estado: Estado) {
  const plan = await leerFichero("todo.md");        // memoria externa
  const contexto = [...estado.historial, { role: "user", content: plan }];  // el plan queda al final
  const accion = await modelo.decidir(contexto);
  await escribirFichero("todo.md", accion.planActualizado);
  return accion;
}

El compromiso: el estado fuera de la ventana solo sirve si el agente se acuerda de leerlo, y cada lectura y escritura es una operación más por turno.

Subagentes: aislar para no contaminar

Un subagente especializado resuelve una tarea concreta con su propia ventana limpia, en lugar de que un único agente arrastre todo el estado del proyecto [1]. Presentado así, es aislamiento de contexto puro. Pero decidir cuándo compensa es un debate con datos en ambos bandos, y merece su propia sección.

Just-in-time retrieval: cargar solo lo que hace falta

En vez de precargar toda la documentación, el agente mantiene identificadores ligeros (rutas, IDs, consultas) y usa herramientas para cargar los datos en runtime, justo cuando los necesita [1]. La ventana queda limpia; el precio es latencia y el riesgo de que la recuperación falle. La infraestructura que hace esto posible es la de siempre: el pipeline de RAG empresarial y, por debajo, los embeddings y la búsqueda semántica.

Subagentes: el caso donde los dos bandos tienen datos

Aquí está el compromiso más interesante para un senior, porque la misma técnica tiene dos veredictos medidos. A favor: Anthropic reportó que su sistema multiagente (Claude Opus 4 como líder y subagentes Claude Sonnet 4) superó al agente único en un 90,2% en su eval interna de research [9]. La explicación es económica: el uso de tokens explica por sí solo el 80% de la varianza de rendimiento en su eval BrowseComp, y los subagentes comprimen operando en paralelo, cada uno con su propia ventana, y devolviendo solo la síntesis [9]. El coste: los agentes gastan unos 4× más tokens que un chat, y los sistemas multiagente unos 15× [9].

En contra, Cognition. Sus principios son casi opuestos: “Share context, and share full agent traces, not just individual messages” y “Actions carry implicit decisions, and conflicting decisions carry bad results” [3]. Su ejemplo es demoledor: dos subagentes en paralelo tomaron acciones “based on conflicting assumptions not prescribed upfront” [3]. Cada uno decidió bien por su cuenta, y el resultado combinado fue incoherente.

Nadie miente. La variable es si las decisiones de los subagentes deben ser coherentes entre sí. El +90,2% de Anthropic viene de research: tareas paralelizables, de solo lectura, donde cada subagente busca y no pisa a los demás. El aviso de Cognition aplica a escritura y código, donde cada acción arrastra decisiones implícitas que el siguiente paso tiene que respetar. Si tus subagentes solo leen, aíslalos sin miedo. Si escriben, o comparten contexto completo o no los paralelices. Después de bastantes bucles que se me fueron de las manos, la regla con la que me quedo es tratar el paralelismo como culpable hasta que se demuestre lo contrario: lo dejo entrar por defecto cuando la tarea solo lee, y si hay una sola escritura acoplada de por medio prefiero un agente secuencial aunque tarde más, porque depurar decisiones en conflicto cuesta mucho más que los turnos que ahorras. Cuándo el paralelismo compensa lo desgloso en paralelización de agentes: sectioning y voting.

Contraste entre dos patrones de subagentes paralelos: a la izquierda, subagentes de solo lectura consultan fuentes distintas cada uno en su ventana aislada y el orquestador combina los datos limpios en una síntesis exitosa; a la derecha, subagentes de escritura editan código y diseño en paralelo sin compartir contexto completo, cada uno en una ventana parcial, y el resultado combinado es un conflicto de decisiones incompatibles. La regla: tarea de solo lectura, aislar sin miedo; tarea de escritura con decisiones acopladas, compartir contexto completo o no paralelizar

¿Por qué esta habilidad importa precisamente en 2026?

Porque hoy todo el mundo usa agentes y casi nadie los deja solos, y la diferencia entre ambos grupos es qué ve el modelo. Los datos de adopción son contundentes: la encuesta de Pragmatic Engineer de 2026 reporta que el 95% de los encuestados usa herramientas de IA al menos semanalmente, que el 56% hace ya el 70% o más de su trabajo de ingeniería con IA, y que Claude Code pasó de cero a ser la herramienta número uno en solo ocho meses [10].

Pero el techo está claro. El informe 2026 Agentic Coding Trends de Anthropic encontró que, aunque los desarrolladores usan IA en aproximadamente el 60% de su trabajo, solo pueden delegar por completo entre el 0% y el 20% de las tareas [11]. Ese hueco entre “uso” y “delego” tiene nombre propio, la brecha de delegación, y es exactamente el que el context engineering ataca. El propio informe predice que las organizaciones adoptarán workflows multiagente con “parallel reasoning across separate context windows” [11]. Ventanas separadas: aislamiento de contexto, otra vez.

Cuando el contexto se gobierna bien, se desbloquean tareas antes impensables. El informe recoge el caso de Rakuten implementando un método de extracción de vectores de activación en vLLM, una librería open source de 12,5 millones de líneas de código: Claude Code completó el trabajo entero en siete horas de trabajo autónomo en una sola ejecución, con un 99,9% de precisión numérica frente al método de referencia [11]. Siete horas sin que la ventana se pudra por el camino salen de una sola disciplina sostenida turno a turno: gobernar el contexto como un presupuesto que se gasta con criterio, en lugar de dejar que se acumule como un almacén.

Errores comunes

Tratar la ventana como un almacén

Volcar toda la documentación, el historial completo y “todo por si acaso” no hace al agente más informado: lo hace más ruidoso. Es la receta directa del context rot y de los rendimientos decrecientes [1] [5]. Si dudas si un token entra o no, la respuesta por defecto es que no entra.

Romper el prefijo del cache

Un timestamp, un contador o cualquier estado mutable al principio del system prompt invalida el cache de todo el historial en cada turno. Pagas la prima de escritura (1,25×-2×) sobre miles de tokens que no cambiaron [6]. Lo volátil va al final, siempre.

Enterrar lo crítico en el medio

Las instrucciones o decisiones clave a mitad de un contexto largo caen justo en el fondo de la curva en U [4]. El antídoto es la recitación: reescribe lo importante al final en cada turno [7].

Compactar sin criterio de conservación

Resumir el historial perdiendo las decisiones ya tomadas hace que el agente las contradiga tres turnos después. Comprimir bien “is hard to get right” [3]: define qué se conserva sí o sí (decisiones, compromisos, estado) antes de resumir el resto.

Paralelizar subagentes que escriben

Lanzar subagentes en paralelo sobre una tarea de escritura sin contexto compartido produce decisiones implícitas en conflicto [3]. Recuerda que el +90,2% de Anthropic viene de research de solo lectura, no de código [9].

Fuentes

  1. Effective context engineering for AI agents. Anthropic Engineering. Definición de context engineering y de prompt engineering, attention budget, recurso finito con rendimientos decrecientes, context rot, compactación, memoria externa, subagentes y just-in-time retrieval.
  2. Context engineering. Simon Willison. Citas textuales de Andrej Karpathy y de Tobi Lütke sobre el término.
  3. Don’t Build Multi-Agents. Cognition (Walden Yan). “The #1 job of engineers building AI agents”, compartir contexto y trazas completas, decisiones en conflicto y dificultad de la compresión.
  4. Lost in the Middle: How Language Models Use Long Contexts. Liu et al., TACL 2023. La curva en U del uso del contexto.
  5. Context Rot: How Increasing Input Tokens Impacts LLM Performance. Chroma Research. 18 modelos evaluados; el rendimiento se vuelve menos fiable al crecer el input; hallazgo LongMemEval.
  6. Prompt caching. Anthropic Docs. Lectura de cache 0,1×, escritura 1,25× (5 min) y 2× (1 h), TTL por defecto de 5 minutos.
  7. Context Engineering for AI Agents: Lessons from Building Manus. Manus. KV-cache hit rate como métrica nº 1, 0,30 vs 3 USD/MTok, ratio input:output ~100:1, ficheros como contexto definitivo y recitación del todo.md.
  8. Managing context on the Claude Developer Platform. Anthropic. +29% (context editing), +39% (con memory tool), 84% menos de tokens en una eval de 100 turnos, y definiciones de context editing y memory tool.
  9. How we built our multi-agent research system. Anthropic Engineering. +90,2% multiagente vs agente único, tokens explican el 80% de la varianza en BrowseComp, ~4× y ~15× de coste, subagentes como compresión paralela.
  10. AI Tooling for Software Engineers in 2026. Pragmatic Engineer. Datos de adopción: 95% uso semanal, 56% hace 70%+ del trabajo con IA, Claude Code nº 1 en ocho meses.
  11. 2026 Agentic Coding Trends Report. Anthropic. IA en ~60% del trabajo pero solo 0-20% delegable, predicción de workflows multiagente con ventanas separadas y el caso Rakuten (12,5M líneas, 7 horas, 99,9%).

Preguntas Frecuentes

¿El context engineering sustituye al prompt engineering o lo incluye?

Lo incluye: el prompt es solo un subconjunto de todo lo que entra en la ventana, así que escribir buenas instrucciones sigue siendo necesario, pero deja de ser suficiente.

¿Qué es el context rot y por qué obliga a hacer context engineering?

Es la degradación del modelo a medida que crece la ventana: según Anthropic, cuantos más tokens, peor recuerda con precisión la información que contiene. Chroma lo confirmó en 18 modelos actuales, y “Lost in the Middle” ya había mostrado que lo situado en mitad de un contexto largo se lee peor que lo del principio o el final. Por eso no basta con meter más información: hay que curar cuál entra.

¿Cuándo compensa usar subagentes para aislar contexto?

Cuando la tarea es paralelizable y de solo lectura, como investigar en varias fuentes a la vez: ahí Anthropic midió un 90,2% de mejora frente al agente único, porque cada subagente trabaja con su ventana limpia. No compensan cuando escriben o generan código con decisiones acopladas, porque toman supuestos en conflicto que nadie fijó de antemano. Y ten presente el coste: un sistema multiagente puede gastar unos 15× más tokens que un chat.

¿Por qué mi agente es más caro de lo que esperaba?

Porque el input domina la factura. En Manus, un agente de producción real, el ratio input:output ronda 100:1 y una tarea típica encadena unas 50 llamadas a herramientas; como cada turno reenvía todo el historial acumulado, esos tokens de entrada se pagan una y otra vez. La palanca principal es el cache: leer cuesta 0,1× pero escribir 1,25×-2×, de modo que un prefijo estable que no rompa el cache reduce la factura mucho más que cualquier ajuste al prompt.

Sigue explorando

Articulos relacionados