Context engineering: por qué tu agent se vuelve más tonto en el turno 40

Anthropic trazó la línea en septiembre de 2025 y las dos frases van una al lado de la otra. Prompt engineering es «métodos para escribir y organizar instrucciones para LLM con el fin de obtener resultados óptimos». Context engineering es «el conjunto de estrategias para seleccionar y mantener el conjunto óptimo de tokens (información) durante la inferencia de LLM, incluida toda la demás información que pueda acabar ahí fuera de los prompts».¹

La diferencia operativa es cuándo, y por quién. Un prompt lo redacta una vez una persona, y se revisa. Un contexto se monta en cada llamada, mediante código que nadie está mirando, a partir de material que nadie escribió a mano: cuarenta turnos de historial, seis resultados de herramientas, cuatro pasajes recuperados, un perfil de usuario, doce esquemas JSON. Capítulo 15 midió lo que aportan unas instrucciones mejores. Este capítulo trata sobre el otro noventa por ciento de los tokens, que llegan solos.

El mismo documento nombra el recurso que todos gastan: los modelos «tienen un “presupuesto de attention” del que tiran al analizar grandes volúmenes de contexto. Cada token nuevo introducido agota parte de ese presupuesto». Y nombra el síntoma: «a medida que aumenta el número de tokens en la context window, disminuye la capacidad del modelo para recordar información de ese contexto con precisión» — putrefacción del contexto.¹

Esa última frase es una afirmación sobre comportamiento, lo que significa que puede comprobarse, y la tabla de la parte superior de esta página es la comprobación.

Cuarenta líneas contra el endpoint local de Capítulo 22 — un pequeño servidor Python que mantiene Qwen2.5-0.5B-Instruct en la CPU y habla con la forma de chat-completions, de modo que el bucle se queda en TypeScript y los tensores se quedan al otro lado del puerto.

const DEPTHS = [0, 0.125, 0.25, 0.375, 0.5, 0.625, 0.75, 0.875, 1];

for (const d of DEPTHS) {
  const slot = Math.round(d * (N - 1));
  let hits = 0, other = 0;
  for (let t = 0; t < TRIALS; t++) {
    const recs = buildRecords(N, 1000 + t);          // 25 unique tickets
    const gold = recs[Math.floor(rng(7 + t)() * N)]; // a different one each trial
    const rest = recs.filter((x) => x.ticket !== gold.ticket).slice(0, N - 1);
    const lines = [...rest.slice(0, slot).map((x) => x.line),   
                   gold.line,                                   
                   ...rest.slice(slot).map((x) => x.line)];     
    const r = await complete(prompt(lines, ask(gold.owner)), { maxTokens: 12 });
    const said = /\d{4}/.exec(r.text)?.[0];
    if (said === String(gold.ext)) hits++;
    else if (said && recs.some((x) => String(x.ext) === said)) other++;
  }
}

El contador other es lo que convierte un resultado decepcionante en uno útil: cuando el modelo se equivoca, ¿está perdido o está seguro?

La respuesta es que está seguro. En las ocho posiciones que no son la primera, 136 de las 205 respuestas incorrectas eran la extensión de otro ticket: un número real de cuatro dígitos, con formato correcto, leído de la línea equivocada. En la posición 1 solo una de las cinco respuestas fallidas lo era; en la posición 7, veintiuna de veintiséis.

Esa distinción es lo que importa en producción. Un modelo que dice no lo encuentro es un bug que notas; un modelo que devuelve el número de una fila vecina es un bug que envías, porque en pantalla ambos parecen idénticos. Es el fallo contra el que el Capítulo 19 construyó citas verificables, llegando desde dentro del prompt en lugar de desde el índice.

La posición es un eje. La longitud es el otro, y es más fácil de probar: mantén la respuesta en el medio y haz crecer la lista.

Un registro y 97 tokens: 90 %. Tres registros y 159 tokens: 55 %. Ocho registros y 315 tokens: 15 %, y desde ahí plano y bajo hasta 140 registros y 4.477 tokens. Todo el colapso ocurre entre la primera y la octava línea de una lista.

La última columna es todo lo que no es ni la extensión correcta ni la de otro registro, lo que con un solo registro en la página es el único sitio donde puede caer una respuesta incorrecta. Los dos fallos con un registro merecen contarse en lugar de redondearse fuera, porque ninguno fue una negativa: uno respondió 5806 a un registro cuya única línea dice 5805. Con 97 tokens y un único candidato, este modelo aún copia mal un dígito dos veces de veinte, y ese es el suelo contra el que se mide todo lo demás.

De ahí salen dos cosas. Una context window más grande compra el derecho a enviar más, no la certeza de que se lea: este modelo tiene una ventana de 32.768 tokens y un rango de trabajo, en esta tarea, de unos pocos cientos de tokens. Y no hay umbral, ni precipicio, ni estado de «contexto lleno»: la degradación ya está en marcha en el tercer registro y se completa en el octavo, al uno por ciento de la ventana. Sea lo que sea un límite de contexto, no es lo que gobierna esto.

Suelen proponerse dos mecanismos. El primero es la aritmética del Capítulo 9, que Anthropic formula en los mismos términos que este curso: los modelos «se basan en la arquitectura transformer, que permite que cada token atienda a todos los demás tokens en todo el contexto. Esto da lugar a n² relaciones por pares para n tokens».¹ La attention sobre una secuencia más larga no es la misma operación aplicada a más material; es un presupuesto fijo de masa de probabilidad repartido entre más competidores. El segundo es el entrenamiento: los modelos ven muchas más secuencias cortas que largas, así que los patrones posicionales de largo alcance son la parte menos practicada de la red. Eso es un argumento, no una medición, y este capítulo no puede zanjarlo.

Lo que sí está zanjado es la forma, y lo está desde 2023. Liu et al. probaron respuesta a preguntas multi-documento y recuperación clave-valor en familias y tamaños de modelos, y descubrieron que «el rendimiento suele ser más alto cuando la información relevante aparece al principio o al final del contexto de entrada, y se degrada de forma significativa cuando los modelos deben acceder a información relevante en medio de contextos largos, incluso en modelos explícitamente de contexto largo».² El Capítulo 15 tomó de ese artículo su regla de posición; el Capítulo 19 tomó de él la razón por la que veinte chunks recuperados pueden puntuar peor que cuatro. La forma práctica del hecho es la única frase de aquí sobre la que deberías actuar: esto se mide en cinco minutos en tu propio modelo con tus propios datos, y ninguna curva publicada sustituye a la tuya.

Pregunta a un equipo qué llena el contexto de su agent y obtendrás una estimación, porque ninguna API devuelve la respuesta: la respuesta te da prompt_tokens, un único número para todo.

Puedes reconstruir el desglose con cuatro recuentos y tres restas: el prompt completo renderizado, el mismo sin definiciones de herramientas, solo el mensaje de sistema con y sin ellas, y todo sin los resultados de herramientas:

async function buckets(messages: Msg[]) {
  const sys = messages.slice(0, 1);
  const withoutResults = messages.filter((m) => m.role !== "tool");
  const [total, sysWithTools, sysNoTools, noResults] = await Promise.all([
    countPrompt(messages, CATALOGUE),        // everything
    countPrompt(sys, CATALOGUE),             // system + scaffolding + schemas
    countPrompt(sys),                        // system + scaffolding
    countPrompt(withoutResults, CATALOGUE),  // everything but tool output
  ]);
  return {
    system: sysNoTools,
    tools: sysWithTools - sysNoTools,                                  
    toolResults: total - noResults,                                    
    conversation: total - sysWithTools - (total - noResults),          
    total,
  };
}

countPrompt aplica la plantilla de chat del propio modelo antes de tokenizar, lo cual importa más de lo que parece: tu texto no es lo que se cuenta. Los marcadores de rol, el preámbulo de tool calling y el renderizado del esquema son todos tokens que pagas y que nunca has escrito. Capítulo 7 construyó un tokenizador y el Capítulo 16 contó con js-tiktoken; aquí el recuento viene del mismo modelo que leerá el prompt, que es el único recuento exactamente correcto.

Ahora pásale un agent real: cuarenta turnos de una investigación de incidente, doce herramientas, un entorno de operaciones falso que devuelve volcados de logs y series de métricas realistas.

Lee la primera fila frente a la última.

En el turno 1, el prompt tiene 2.547 tokens y el 71 % son definiciones de herramientas. El system prompt es el 3 %. Lo que escribió el usuario es el 6 %. El agent aún no ha hecho nada y ya carga con 1.817 tokens de esquema JSON.

Para el turno 40, el prompt tiene 10.632 tokens y las proporciones se han invertido: definiciones 17 %, conversación 29 %, resultados de herramientas 53 %. La salida de herramientas superó a las definiciones en el turno 5; la conversación no las superó hasta el turno 25, así que durante el primer sesenta por ciento de la sesión el catálogo de herramientas fue más grande que todo lo que se había dicho.

Luego el total. En 57 llamadas al modelo, la ejecución facturó 370.291 tokens de entrada para un contexto final de 10.632: el último prompt se pagó unas treinta y cinco veces, que es la cuadrática del Capítulo 16 con el multiplicador de un agent encima. De esos 370.291, 103.569, o el 28 % de todo lo facturado, fueron las doce definiciones de herramientas, reenviadas byte a byte en cada llamada.

El catálogo de herramientas es el mayor coste fijo de un agent y es invisible, porque nunca lo ves: pasas un array de objetos y el proveedor lo renderiza dentro del prompt por ti. Medido, con las mismas doce herramientas:

system prompt + chat scaffolding, no tools:        85 tokens
all twelve definitions:                          1,817 tokens
  of which fixed tool-calling scaffolding:         126 tokens
three tools instead of twelve:                     605 tokens
same twelve, one-sentence descriptions,
  no parameter prose:                            1,291 tokens  (-29 %)

Por herramienta, el coste marginal va de 80 tokens para get_current_time, que recibe una cadena, a 263 para search_tickets, que recibe cuatro parámetros con un enum y una frase de orientación cada uno. Ese es el tipo de cambio detrás del consejo central del Capítulo 18 de que la descripción es la API: una buena descripción cuesta unos cien tokens en cada solicitud durante el resto de la vida del agent. Tres consecuencias.

Una herramienta que no usas también factura. El agent llamó a siete de las doce. Las otras cinco costaron 697 tokens en cada una de las 57 solicitudes: 39.729 en total, más de una décima parte de todo lo facturado en la ejecución, por capacidades que nunca tocó. Una de las cinco contiene el detalle más afilado del trace: el modelo intentó tres veces llamar a read_log, que no existe. La herramienta que quería era search_logs, la segunda definición más cara del catálogo, con 237 tokens. Pagó esa definición 57 veces, nunca la usó y nunca encontró su nombre.

Recortar prosa es la optimización más barata disponible, y es un intercambio. Reducir las descripciones a una frase y eliminar la documentación de parámetros ahorró 526 tokens por llamada, un 29 %, sin tocar una línea de lógica, y empeoró las llamadas a herramientas del modelo, que es lo que midió el Capítulo 18. La cuestión es que ahora ambos lados de ese intercambio están en la misma unidad.

A cierta escala, enviar definiciones deja de tener sentido. Anthropic le puso número en noviembre de 2025: un conjunto grande de servidores conectados implica procesar «cientos de miles de tokens» de definiciones antes de leer la solicitud, y sustituir eso por ejecución de código — que el agent descubra y cargue solo las definiciones que necesita — «reduce el uso de tokens de 150.000 tokens a 2.000 tokens, un ahorro de tiempo y coste del 98,7 %».³ La misma idea que el resto de este capítulo, aplicada a esquemas en lugar de historial: mantén el índice, resuelve la entrada bajo demanda.

Se plantaron dos cosas en esa transcripción de cuarenta turnos. En el turno 2, antes de cualquier trabajo real, el usuario declara una regla permanente: cualquier ticket que abras debe archivarse con mi número de empleado, 4417. En el turno 19, en mitad del incidente, un dato: el shard afectado es pay-shard-7, confirmado por el equipo de pagos. En el turno 40 el usuario pide al agent que abra el ticket de incidente, lo que requiere ambas cosas. Cada prueba se pregunta en seis formulaciones distintas y se puntúa sobre seis; la decodificación greedy es determinista, así que una llamada da un sí o no irrepetible y seis dan una tasa.

La transcripción se reproduce después bajo siete políticas de contexto. Se reproduce en lugar de volver a ejecutarse, deliberadamente: los mensajes, las llamadas a herramientas y los resultados de herramientas son byte a byte idénticos en las siete, así que la única variable es lo que cada política decidió conservar. El Capítulo 16 mostró por qué una ventana deslizante es una mala jugada económica, porque destruye el prefijo cacheable. Esto es lo que le hace al comportamiento:

Las filas de compactación incluyen lo que costó compactar: 18.581 tokens de entrada para siete resúmenes y 3.392 más para el tomador de notas. La fila de control está ahí para que un cero pueda leerse como un cero: con los dos mensajes solos en un prompt de 1.981 tokens, este modelo responde perfectamente a ambas pruebas, así que ninguna fila es que la tarea sea demasiado difícil.

El historial completo recuerda, y es lo más caro de la tabla: 370.291 tokens de entrada para una sesión cuyo contenido duradero son dos frases.

Eso responde a una pregunta que el arranque dejó abierta. ¿Por qué una transcripción de 10.632 tokens contiene un dato que un registro de 853 tokens pierde? Porque la longitud es la variable equivocada. El registro contiene veinticinco extensiones de cuatro dígitos en veinticinco frases idénticas: veinticuatro señuelos casi perfectos para la que quieres. La transcripción contiene exactamente un número de empleado y un nombre de shard. La putrefacción del contexto es interferencia antes que volumen, por eso 136 de las 205 respuestas incorrectas de arriba eran el valor de un vecino. La pregunta útil sobre una ventana no es lo larga que es; es cuántas cosas dentro de ella se parecen a la respuesta.

La ventana deslizante es un 57 % más barata y ha perdido el incidente. El número de empleado sobrevive solo porque el agent lo había repetido en los turnos recientes. El shard, mencionado una vez en el turno 19, no está en los últimos doce mensajes, y el modelo no lo dice. Preguntado seis veces respondió «el shard de pagos afectado es shard 4417», tirando del número de empleado, el único otro identificador que quedaba en su ventana, y dos veces «pool», sacado de la cadena pool_exhausted en una línea de log.

La compactación es barata y perdió el mismo dato. Siete resúmenes, escritos por el modelo bajo una instrucción explícita de conservar identificadores, números, instrucciones permanentes y preguntas abiertas, y pay-shard-7 no está en ninguno de los que importaban; las seis conjeturas fueron shard 1, pay_shard_1 y pool. La compactación no falla en voz alta. Produce una sesión fluida, plausible y mucho más corta que ha dejado caer una línea en silencio.

Tres filas sacaron 0/6 en el dato del turno 19: la ventana deslizante, la compactación y la compactación con notas. Dieciocho respuestas incorrectas entre ellas, y ni una sola fue «no lo sé».

Luego la fila que debería dar vergüenza. Conservar literalmente los cuarenta mensajes propios del usuario, más los últimos cuatro turnos completos y nada más, cuesta 168.550 tokens — un 54 % menos que el historial completo — y responde a ambas pruebas tan bien como el historial completo o mejor. Sin resumidor, sin tomador de notas, sin segundo modelo: un filtro sobre role === "user". Las palabras del usuario son los tokens baratos de alto valor en la ventana de un agent, y la mayoría de los diseños las descartan con todo lo demás.

Las dos últimas filas son otra vez la tabla inicial, dentro del agent. El mismo bloque fijado, movido del mensaje de sistema al final del prompt: 5/6 se convierte en 6/6. En seis ensayos no es una diferencia significativa y no se presenta como tal; se presenta como recordatorio de que dónde es un parámetro que estás fijando lo sepas o no.

Las cuatro estrategias de abajo son de Anthropic, en su orden, aunque solo las tres últimas son su lista de largo horizonte.¹ Las cuatro son variaciones de una instrucción: no cargues lo que puedas recuperar, y no cargues en bruto lo que puedas llevar comprimido.

const elide: Policy = (h) => [SYSTEM, ...h.flatMap((turn, ti) =>
  turn.map((m) => (ti < h.length - 4 && m.role === "tool"
    ? { role: "tool", name: m.name,
        content: `[${m.name} result from turn ${ti + 1}, ${m.content.length} chars, ` +
                 `elided; call ${m.name} again with the same arguments to re-read it]` }
    : m)))];

const r = await complete([
  { role: "system", content:
      "You keep a durable note file for a support session. Given one user message, " +
      "output one short note ONLY if it states a standing rule, an identifier or a fact " +
      "that must survive the rest of the session. Otherwise output exactly NONE." },
  { role: "user", content: `Turn ${i + 1}: ${user}` },
], { maxTokens: 40 });
if (!/^none\b/i.test(r.text.trim())) notes.push(`turn ${i + 1}: ${r.text.trim()}`);

El sub-agent no está en la tabla de arriba porque no se ejecuta durante cuarenta turnos: se ejecuta una vez, en una ventana que alguien acotó para él. Dado el system prompt, los turnos 17 a 19 y nada más — 2.737 tokens — respondió a la prueba del shard 6/6, mejor que cualquier política de la tabla, y a la prueba del empleado 0/6, porque ese número no está en los tres turnos que se le entregaron.

Eso son los sub-agents en dos números: una ventana limpia no es inteligencia, es alcance, y el acotamiento lo hace por adelantado un código que ya tiene que saber qué turnos importan. Hay una cosa más en esas respuestas que merece conservarse. Esta fue la única política que respondió «None available» en lugar de inventar algo. Un modelo con un contexto pequeño y coherente sabe qué le falta; un modelo con uno grande y ruidoso no.

Casi todas las conversaciones confusas sobre memoria de agents son tres mecanismos llevando la misma palabra. Tienen vidas, propietarios y modos de fallo distintos, y un sistema que los guarda en el mismo sitio tiene un problema que aún no ha notado.

El marco académico es el de CoALA, que organiza los language agents en torno a «componentes de memoria modulares» y separa la memoria de trabajo de los almacenes episódicos, semánticos y procedimentales.⁴ MemGPT toma la misma idea al pie de la letra, tomando prestada la memoria virtual de los sistemas operativos: un nivel rápido dentro de la ventana, un nivel lento fuera de ella, y el propio modelo moviendo datos entre ambos con function calls.⁵ Ambos obligan a plantear la pregunta que un producto debe responder de todos modos: no cuánto puedo conservar, sino a qué almacén pertenece esto y cuándo caduca.

La prueba práctica es una pregunta por dato: ¿qué debería seguir siendo verdad mañana? Un resultado de herramienta del turno 12, nada. Un resumen de la sesión, hasta que termine la sesión. Que el número de empleado del usuario es 4417, hasta que cambie de trabajo. Tres respuestas, tres almacenes.

Ahora puedes medir qué hay en una ventana, decidir qué se queda en ella y distinguir entre un agent que olvidó algo y uno que lo llevaba y no miró.

La última de las cuatro estrategias es la que no encaja aquí. Un sub-agent no es una política de contexto, es un segundo agent, y en el momento en que hay dos tienes que decidir qué pasa entre ellos y cuál manda. Capítulo 25 es eso: los cinco patrones de orquestación y de dónde sale realmente cada uno de sus nombres, las dos topologías que se confunden — pedir a un sub-agent y recibir una respuesta de vuelta, frente a entregarle la conversación y no recuperarla — y el hallazgo medido de que, en la tarea a la que pone precio, la disposición más simple gana, seguido de la prueba para saber cuándo deja de ganar.

También hereda exactamente lo que este capítulo acaba de medir. Un sub-agent devuelve un resumen. Un resumen es una compactación que no escribiste, producida por un modelo cuya ventana no puedes ver, y el padre no tiene forma de distinguir uno bueno de uno incorrecto y seguro: la misma distinción que separaba el 84 % del 19 % al principio de esta página, y que convirtió dieciocho datos ausentes en dieciocho inventados. Así que: cuando el sub-agent se equivoca, ¿qué puede mirar exactamente el padre?

Todos los números de aquí se produjeron en esta máquina y ninguno se estimó. El modelo es Qwen2.5-0.5B-Instruct en float32 en la CPU con decodificación greedy, servido sobre loopback por un pequeño endpoint Python que habla con la forma de chat-completions y expone una ruta de recuento de tokens — otra vez la costura del Capítulo 14, tensores en el lado Python y el bucle en el lado TypeScript — así que cada recuento es el tokenizador propio de ese modelo aplicado a su propia plantilla de chat. La tabla de posición son 288 llamadas, nueve posiciones por treinta y dos ensayos con un ticket distinto en cada ensayo; la tabla de longitud son 140 llamadas; la ejecución del agent son 57 llamadas al modelo durante 43 minutos de reloj; la tabla de políticas es esa única transcripción reproducida bajo siete políticas. Los intervalos son de Wilson, del Capítulo 4. No se llamó a ninguna API de pago, que también es la razón por la que no hay ningún precio en el capítulo: los recuentos de tokens son exactos y las tarifas por las que los multiplicarías son las del Capítulo 16.