El prompt engineering pregunta "¿cómo redacto las instrucciones?". El context engineering plantea una pregunta más amplia: de todo lo que el modelo podría ver en este paso, ¿qué debería ver? Para una única respuesta de chat la diferencia es pequeña. Para un agente que se ejecuta durante cincuenta pasos, lee archivos, llama a herramientas y acumula resultados, es la diferencia entre un sistema que se mantiene lúcido y otro que poco a poco pierde el hilo. Esta guía explica por qué el contexto es un recurso escaso y las técnicas que lo mantienen enfocado.

Por qué falla "usa la ventana de contexto grande y ya"

Los modelos actuales aceptan cientos de miles o incluso un millón de tokens. Es tentador meterlo todo: el código completo, toda la documentación, el historial entero de la conversación. En la práctica, la calidad se degrada mucho antes del límite:

  • La atención no es uniforme. Los modelos recuperan mejor la información del principio y del final de los contextos largos que de la mitad (Liu et al., Lost in the Middle).
  • El contexto efectivo es más corto que el anunciado. Los benchmarks que van más allá de la simple búsqueda de "una aguja en un pajar" muestran que el rendimiento cae a medida que crece el contexto, sobre todo en el razonamiento de varios saltos (Hsieh et al., RULER).
  • Los distractores perjudican. El contenido irrelevante pero plausible desvía a los modelos más que el contenido que falta.
  • El coste y la latencia crecen con los tokens. Cada paso de un agente vuelve a leer todo el contexto; consulta optimización de costes de LLM.

El equipo de ingeniería de Anthropic describe el contexto como un recurso finito con rendimientos marginales decrecientes, un "presupuesto de atención" (Effective context engineering for AI agents). El objetivo es el conjunto más pequeño de tokens con mucha señal que maximice la probabilidad del resultado deseado.

Qué compite por la ventana de contexto

Componente Tamaño típico Notas
Prompt de sistema 1–5k tokens Estable; se puede cachear
Definiciones de herramientas 0,5–20k tokens Crece con cada herramienta; consulta diseño de herramientas
Documentos recuperados 2–50k tokens La mayor palanca en RAG
Historial de la conversación Crece sin límite Hay que recortarlo o resumirlo
Resultados de herramientas Crecen en cada paso A menudo el mayor consumidor en los agentes
Memoria / notas 0,5–5k tokens Hechos seleccionados de trabajo anterior
Tarea actual Pequeña Nunca debería quedar desplazada

Trátalo como el presupuesto de memoria en programación de sistemas embebidos: cada componente recibe una asignación y cada token tiene que justificarse.

Técnica 1: dimensiona bien el prompt de sistema

Los prompts de sistema fallan en dos direcciones. Demasiado específicos —listas largas de reglas si-entonces para casos límite— y se vuelven frágiles y contradictorios. Demasiado vagos —"sé útil"— y al modelo le faltan las señales que necesita. Apunta al término medio: principios claros, las pocas reglas estrictas que importan y un puñado de ejemplos canónicos en lugar de una lista exhaustiva. Organízalo con encabezados o etiquetas XML para que las secciones sean fáciles de localizar. Los detalles están en prompt engineering para desarrolladores.

Técnica 2: recuperación justo a tiempo en lugar de precarga

En lugar de cargar por adelantado todos los datos potencialmente relevantes, da al agente referencias ligeras y herramientas para obtener los detalles cuando los necesite: rutas de archivos, IDs de documentos, herramientas de búsqueda, consultas a base de datos. Así trabajan los agentes de programación en repositorios grandes: no leen todos los archivos; hacen grep, listan directorios, abren los archivos relevantes y se quedan solo con lo que importa.

Compromisos:

  • La precarga es más rápida en ejecución y funciona cuando el conjunto relevante es pequeño y predecible (el perfil de un cliente en un chat de soporte).
  • El justo a tiempo escala a grandes corpus y mantiene limpio el contexto, a costa de llamadas extra a herramientas.
  • El híbrido —precargar un núcleo pequeño y de alto valor (instrucciones, perfil del usuario, un archivo de instrucciones del proyecto como CLAUDE.md) y recuperar el resto bajo demanda— es la opción por defecto que recomiendo.

La calidad de la recuperación pasa entonces a ser crítica; consulta RAG para empresas y embeddings y chunking.

Técnica 3: recorta y resume los resultados de las herramientas

Los resultados de las herramientas son la parte del contexto de un agente que más rápido crece. Estrategias:

  • Da forma a la salida en origen. Las herramientas deberían devolver resultados concisos y con mucha señal, con paginación; es más barato que limpiar después.
  • Elimina los resultados obsoletos. Una vez usada una salida grande —la lectura de un archivo, un resultado de búsqueda— rara vez hace falta conservarla literal. Algunas plataformas permiten borrar automáticamente los resultados antiguos de herramientas; si no, sustitúyelos por una nota de una línea ("leído config.yaml: usa Postgres 16, pool de 20").
  • Guarda los artefactos grandes fuera del contexto. Escribe las salidas grandes en archivos y dale al agente la ruta.

Técnica 4: compactación

Cuando una conversación se acerca al límite de contexto, resúmela y continúa en una ventana nueva con el resumen. Bien hecha, la compactación conserva las decisiones, los problemas abiertos y los detalles importantes (nombres de archivo, IDs, mensajes de error) y descarta la salida redundante de herramientas y los callejones sin salida.

Summarise this session for continuation. Keep:
- the task and acceptance criteria
- decisions made and why
- files changed and their current state
- unresolved errors with exact messages
- next planned steps
Drop: raw tool outputs already acted on, failed approaches (one line each).

Ajusta el prompt de resumen con sesiones largas reales: primero maximiza la exhaustividad (que no se pierda nada importante) y después recorta. Los agentes de programación lo implementan como compactación automática o manual.

Técnica 5: notas estructuradas

En tareas largas, deja que el agente mantenga notas fuera de la ventana de contexto —un archivo NOTES.md, una lista de tareas, una herramienta de memoria— y que las relea cuando lo necesite. Las notas sobreviven a la compactación y a los reinicios de contexto, y le dan al agente una sensación persistente de progreso durante horas de trabajo. Funciona especialmente bien en migraciones de varios pasos, tareas de investigación y cualquier cosa que abarque varias sesiones.

# NOTES.md — migration of billing to java.time
- [x] Package billing.invoice (12 files) — tests green
- [x] Package billing.tax — note: TaxPeriod uses Europe/Kyiv explicitly
- [ ] Package billing.reports — 3 usages of Joda Interval, need adapter
Open question: rounding in ReportTotals differs from old behaviour? (#481)

Técnica 6: subagentes con contextos limpios

Un subagente es una llamada al modelo o un agente separado, con su propio contexto limpio, al que se le da una tarea concreta —"encuentra todos los sitios donde analizamos fechas en el paquete de informes y resume los formatos usados"— y que devuelve solo un resultado condensado. El contexto del agente principal recibe unos cientos de tokens en lugar de las decenas de miles que consumió el subagente.

Esta separación de responsabilidades es una de las razones principales por las que las arquitecturas multiagente superan a los agentes individuales en tareas de investigación amplias, con un coste notable en tokens; consulta sistemas multiagente. Las herramientas de programación exponen la misma idea como subagentes.

Técnica 7: memoria a largo plazo, con cuidado

La memoria entre sesiones —preferencias del usuario, decisiones pasadas, hechos sobre un proyecto— hace que los agentes parezcan más listos, pero también es contexto que puede ser erróneo, estar desactualizado o haber sido inyectado. Reglas que sigo:

  • Guarda hechos con procedencia y fecha, no transcripciones en bruto.
  • Recupera la memoria de forma selectiva por relevancia, como cualquier otro documento.
  • Deja que los usuarios vean y borren lo que se recuerda de ellos; es también un requisito de privacidad.
  • Trata como no confiable la memoria escrita a partir de contenido no confiable.

Orden y caché

Cómo ordenas el contexto importa tanto para la calidad como para el coste:

  1. Primero el contenido estable: prompt de sistema, definiciones de herramientas, documentos de referencia largos. Este prefijo se puede cachear, lo que reduce mucho el coste y la latencia en llamadas repetidas.
  2. Después el semiestable: perfil del usuario, notas del proyecto.
  3. Al final, lo dinámico: historial de la conversación, últimos resultados de herramientas, la pregunta actual.

Colocar los documentos largos antes de la pregunta también suele mejorar la calidad de la respuesta.

Medir la calidad del contexto

El context engineering se puede probar:

  • Ablación: elimina un componente del contexto y vuelve a ejecutar los evals; si las puntuaciones no bajan, estabas pagando por nada.
  • Presupuesto de tokens por paso: sigue los tokens de entrada por paso del agente a lo largo de una sesión; un crecimiento repentino apunta a resultados de herramientas inflados.
  • Evals de sesiones largas: incluye tareas que requieran más de 30 pasos para que la degradación aparezca en los tests y no en producción.
  • Revisión de trazas: lee lo que vio realmente el modelo en el paso en el que se equivocó; consulta observabilidad de LLM.

Preguntas frecuentes

¿El context engineering es solo un nombre nuevo para RAG? RAG es una de sus técnicas. El context engineering abarca también las instrucciones, las herramientas, el historial, la memoria y cómo evoluciona todo ello durante una tarea de varios pasos.

¿Las ventanas de contexto más grandes lo vuelven innecesario? No. Las ventanas más grandes suben el techo, pero el enfoque y el coste siguen dependiendo de lo que metas. Todos los benchmarks publicados de contexto largo muestran degradación con más contenido distractor.

¿Cómo decidimos qué resumir? Conserva todo lo necesario para tomar decisiones futuras —objetivos, restricciones, decisiones, errores abiertos, identificadores— y descarta lo que ya se ha utilizado.

¿Por dónde empezamos? Mide los tokens por paso de tu agente, encuentra el mayor contribuyente (normalmente los resultados de herramientas o el historial) y arregla eso primero.

Fuentes

  1. Anthropic (2025). Effective context engineering for AI agents.
  2. Liu et al. (2023). Lost in the Middle: How Language Models Use Long Contexts.
  3. Hsieh et al. (2024). RULER: What's the Real Context Size of Your Long-Context Language Models?
  4. Anthropic. Prompt caching.
  5. Anthropic. Claude Code subagents.
  6. Packer et al. (2023). MemGPT: Towards LLMs as Operating Systems.