Ingeniería de contexto para agentes de IA: qué entra realmente en la ventana de contexto

Tabla de contenidos

Publicado en agosto de 2026.

TL;DR: La ingeniería de contexto es la disciplina de decidir qué tokens se ganan un lugar en la ventana de contexto de un agente en cada paso — las instrucciones del sistema, las definiciones de herramientas, los datos recuperados y el historial de conversación compiten todos por el mismo espacio limitado. La ingeniería de prompts pregunta cómo formulo esto; la ingeniería de contexto pregunta qué necesita saber realmente el modelo ahora mismo. El modo de fallo habitual no es demasiado poco contexto — es demasiado: historial obsoleto, esquemas de herramientas irrelevantes y documentos recuperados que nadie pidió, todo diluyendo la señal y disparando el costo. Aplico un presupuesto fijo por categoría, recorto el historial antes que la identidad, y resumo antes de truncar.

Lectura del operador: Los agentes que más me ha costado depurar no fallaban porque el modelo fuera débil. Fallaban porque había dejado que la ventana de contexto se convirtiera en un cajón desordenado: seis esquemas de herramientas que la tarea no necesitaba, un historial de conversación que se había desviado 40 turnos de la petición original, un documento recuperado que era técnicamente relevante y prácticamente inútil. Arreglar el prompt no ayudaba. Arreglar lo que había delante del prompt sí.

La ingeniería de prompts te consiguió un agente que funciona. La ingeniería de contexto es lo que lo mantiene funcionando cuando maneja volumen real, historial real y casos límite reales — y es la habilidad a la que le dedico más tiempo ahora que a la redacción del prompt.

La ingeniería de prompts y la ingeniería de contexto no son el mismo trabajo

Un prompt es una instrucción. El contexto es todo lo que el modelo ve al actuar sobre esa instrucción: el prompt del sistema, las herramientas que puede invocar, lo que hayas recuperado o consultado, y cuánta conversación o historial de ejecuciones anteriores decidiste llevar contigo. La ingeniería de prompts optimiza la redacción de lo primero. La ingeniería de contexto optimiza la composición de las cuatro cosas.

Esta distinción importa en la práctica, no solo en el vocabulario. Si escribo un prompt perfectamente afinado y le entrego al agente cinco esquemas de herramientas irrelevantes y cuarenta turnos de historial obsoleto, la redacción no importa — el modelo está razonando sobre un contexto que es mayormente ruido. Cada uno de mis agentes que pasó de “funciona en la demo” a “funciona a las 3 de la mañana con una entrada rara” llegó ahí arreglando lo que había en la ventana, no reformulando las instrucciones dentro de ella.

Las cuatro cosas que compiten por el espacio

En cada turno, cuatro categorías luchan por el mismo espacio limitado:

1. Instrucciones del sistema — identidad, reglas, formato de salida. Consulta las cinco capas que uso para los prompts de sistema — esta es la única categoría que debería mantenerse casi fija, porque el prompt caching solo compensa cuando el prefijo no se mueve.
2. Definiciones de herramientas — los esquemas de cada herramienta que el agente podría invocar este turno, la necesite o no.
3. Datos recuperados — cualquier cosa extraída de una base de datos, un vector store o una llamada a una API: memoria, documentos, registros de clientes.
4. Historial de conversación o de ejecución — lo que ya ha pasado en esta sesión o en esta ejecución.

Ninguna de estas es gratis. Cada token de cualquier categoría es un token que el modelo tiene que sopesar frente a todos los demás al decidir qué hacer a continuación, y cada token es un token que pagas en cada solicitud que no sea un acierto de caché.

El error casi siempre es demasiado, no muy poco

Cuando un agente se comporta mal, el instinto es añadir más contexto — más instrucciones, más antecedentes, más historial “por si acaso”. En mi experiencia eso suele ser al revés.

Demasiados esquemas de herramientas. He visto a un agente invocar la herramienta equivocada no porque faltara la correcta, sino porque estaba enterrada detrás de otras seis que no necesitaba para esa tarea. Envía solo las herramientas relevantes para el paso actual, no toda la caja de herramientas en cada llamada. Una capa de enrutamiento que decide qué subconjunto de herramientas exponer es barata de construir y se paga sola la primera vez que evita una llamada equivocada.

Historial de conversación obsoleto. Un agente de soporte que arrastra 60 turnos de historial de tres incidencias no relacionadas de hace tiempo no está “recordando al cliente” — está diluyendo la petición actual con ruido irrelevante, y ocasionalmente actuando sobre algo que ya no es cierto. Este es exactamente el modo de fallo que la memoria episódica con una ventana acotada debería evitar, y vale la pena comprobar si tu ventana realmente está acotada o ha crecido sin límite en silencio.

Documentos recuperados que nadie pidió. Una recuperación semántica que devuelve los 10 fragmentos “más similares” en lugar de los 2 relevantes entierra la respuesta en distracción de aspecto plausible. Más contexto recuperado no es más señal — a partir de cierto punto es activamente peor, porque el modelo tiene que trabajar más para encontrar la parte que importa.

Instrucciones repetidas a la defensiva. Veo esto en prompts que repiten la misma regla de cuatro formas distintas porque una versión anterior del agente la ignoró una vez. Esa es una señal de que la regla necesitaba moverse antes en el prompt o hacerse cumplir de forma estructural (una restricción en el esquema de una herramienta, un paso de validación) — no una señal para rellenar el contexto con repetición.

El presupuesto que realmente aplico

En más de 30 agentes en producción, fijo un presupuesto explícito de tokens por categoría antes de construir el agente, no después de que empiece a comportarse mal:

El orden de esa última columna es el marco de decisión real: primero el historial, luego la amplitud de la recuperación, luego el alcance de las herramientas, y las instrucciones del sistema al final. El historial es lo más barato de comprimir sin perder corrección — un resumen de dos frases de “qué pasó en los turnos 1-30” suele aportar el mismo valor operativo que la transcripción completa. Recortar las instrucciones del sistema es lo más peligroso, porque ahí es donde vive el comportamiento real del agente.

Resume antes de truncar

Truncar — simplemente descartar los turnos más antiguos — es la versión tosca de esto. Funciona hasta que el turno descartado contenía el único dato que el agente necesitaba. El patrón mejor es la compactación: antes de descartar historial bruto, colapsarlo en un resumen estructurado breve que capture las decisiones y los hechos, y conservar ese resumen de forma permanente incluso después de que los turnos brutos hayan desaparecido.

// workers/compact-history.ts

interface HistoryDigest {
  summary: string; // 2-3 frases: qué se ha decidido, resuelto, o sigue abierto
  keyFacts: Record<string, string>; // hechos estables que vale la pena conservar textualmente
  turnCount: number; // cuántos turnos brutos reemplaza este resumen
}

async function compactIfNeeded(
  history: ConversationTurn[],
  env: Env
): Promise<{ digest: HistoryDigest | null; recent: ConversationTurn[] }> {
  const RECENT_WINDOW = 10;
  if (history.length <= RECENT_WINDOW) {
    return { digest: null, recent: history };
  }

  const toCompact = history.slice(0, -RECENT_WINDOW);
  const recent = history.slice(-RECENT_WINDOW);

  // Un modelo barato resumiendo casi siempre es suficiente para este paso
  const digest = await summarizeTurns(toCompact, env);
  return { digest, recent };
}

Este es el mismo principio que un eval harness convirtiendo cada fallo de producción en un caso de prueba permanente (ver el eval harness que uso para lanzar agentes): no descartes información, comprímela en una forma barata de conservar y aún útil. Los turnos brutos son desechables. Los hechos que contienen normalmente no lo son.

Recuperación: menos resultados, más relevantes, superan a más resultados

La misma disciplina aplica a cualquier cosa extraída de un vector store o una base de datos. Es tentador recuperar generosamente — top-10, top-20 — bajo la teoría de que más contexto no puede hacer daño. Sí puede. Cada fragmento irrelevante es un fragmento que el modelo tiene que leer, sopesar y descartar, y un montón lo bastante grande de casi-aciertos puede pesar más que el único fragmento que realmente responde la pregunta.

Mi valor por defecto es empezar con un k pequeño (2-4) y ampliarlo solo si puedo demostrar, con casos reales, que la respuesta realmente falta con esa amplitud — no porque una red más ancha se sienta más segura. Si la calidad de la recuperación es inconsistente, la solución suele ser una mejor consulta o un paso de re-ranking, no un k más grande.

Conéctalo con el costo y la corrección

La ingeniería de contexto no es solo un problema de calidad — es la palanca individual más grande sobre lo que cuesta operar un agente, porque en la mayoría de las cargas de trabajo de agentes se cobra mucho más por los tokens de entrada que por los de salida. Una ventana de contexto inflada es una factura inflada antes de ser un bug de comportamiento. Si no has visto la matemática de costos para elegir entre niveles de modelo, el presupuesto de contexto que apliques cambia esa matemática directamente: un contexto más pequeño y bien acotado hace que un modelo más barato sea viable para más de tus tareas, porque no se le pide al modelo buscar una aguja en un pajar innecesariamente grande.

Cada agente que opero usa Claude, y la decisión de nivel de modelo solo tiene sentido una vez que el presupuesto de contexto está fijado — comparar costos sobre un contexto inflado y sin acotar no te dice nada sobre lo que la tarea realmente necesita.

Y porque cambiar lo que hay en la ventana de contexto cambia el comportamiento tanto como cambiar el prompt, cada cambio de contexto pasa por la misma puerta que un cambio de prompt: ejecútalo contra el conjunto de evals construido a partir de fallos reales de producción antes de lanzarlo. Recortar historial o estrechar el ancho de una recuperación es exactamente el tipo de cambio “obviamente seguro” que en silencio hace regresar un caso límite si no lo verificas.

La conclusión del operador

La ingeniería de contexto es decidir, en cada turno, qué se gana un lugar en una ventana limitada — y el fallo por defecto es incluir demasiado, no muy poco. Mantén las instrucciones del sistema estables y como lo último que recortas. Acota las definiciones de herramientas al paso actual. Recupera de forma estrecha y amplía solo con evidencia. Compacta el historial en resúmenes antes de descartarlo, y recorta primero los turnos brutos más antiguos. Luego verifica cada cambio contra tus evals, porque los cambios de contexto alteran el comportamiento exactamente igual que los cambios de prompt — solo que es más fácil fingir que no.

Preguntas frecuentes

¿Qué es la ingeniería de contexto para agentes de IA?

Es la disciplina de decidir qué tokens — instrucciones del sistema, definiciones de herramientas, datos recuperados e historial de conversación — entran en la ventana de contexto de un agente en cada paso, a diferencia de la ingeniería de prompts, que trata de cómo se redacta una única instrucción. Importa más en producción, donde las cuatro categorías compiten por el mismo espacio limitado en cada solicitud.

¿Es la ingeniería de contexto distinta de la ingeniería de prompts?

Sí. La ingeniería de prompts optimiza la redacción de una instrucción. La ingeniería de contexto optimiza todo lo demás que el modelo ve junto a esa instrucción — qué herramientas están expuestas, qué se ha recuperado, y cuánto historial se lleva hacia adelante. Un prompt bien redactado igual falla si está rodeado de esquemas de herramientas irrelevantes o historial obsoleto.

¿Cuánto historial de conversación debería conservar un agente de IA?

Menos de lo que crees. Una ventana deslizante acotada (10-20 turnos recientes es típico) más un resumen condensado de todo lo anterior suele superar a una transcripción bruta completa, porque elimina el ruido sin perder los hechos que importan. Compacta antes de descartar historial, no te limites a truncarlo.

¿Una ventana de contexto más grande significa que necesito menos ingeniería de contexto?

No — elimina el techo técnico duro pero no el problema de costo ni de ruido. Una ventana más grande hace más barato ser descuidado, pero cada token irrelevante sigue diluyendo la señal que el modelo tiene que procesar y sigue costando dinero en cada solicitud que no sea un acierto de caché. La disciplina importa igual a 200K tokens que a 8K.

Relacionado: Cómo escribir prompts de sistema para agentes de IA que no fallen en producción · Cómo añadir memoria a un agente de IA · Prompt caching: reduce tus costos de Claude sin cambiar de modelo · El eval harness que uso para lanzar agentes de IA

¿Necesitas ayuda para diseñar el contexto y la memoria de un agente? Contáctame — diseño sistemas de agentes en producción para equipos operadores.