Context engineering: más allá del prompt
Context engineering es decidir qué tokens recibe el modelo en cada paso: instrucciones, herramientas, historial y datos. Por qué va más allá del prompt.
¿Qué es, en concreto?
En su artículo de ingeniería del 29 de septiembre de 2025, Anthropic describe el context engineering como la evolución natural del prompt engineering: mientras el prompt engineering se ocupa de redactar y organizar las instrucciones, el context engineering cura y mantiene el conjunto óptimo de tokens durante la inferencia, incluida la información que no es el prompt. Además, no es una tarea puntual: se repite cada vez que se pasa contenido al modelo. La pregunta cambia de “cómo redacto la instrucción” a “qué debe estar visible para el modelo ahora mismo, y qué no”.
En un producto simple, el contexto está formado por el mensaje del sistema, el historial y el mensaje del usuario. En un agente, crece con cada paso: definiciones de herramientas, resultados de búsquedas, archivos leídos y resúmenes de lo ya hecho. Cada uno ocupa espacio dentro de la ventana de contexto y compite con los demás por la atención del modelo.
Según la misma publicación, un buen contexto tiene estas características: el mensaje del sistema dice lo mínimo necesario con un nivel de especificidad equilibrado; las herramientas son eficientes en tokens y no se solapan; los ejemplos son pocos, variados y representativos, en lugar de una lista de reglas para casos límite; el historial es informativo pero austero. Anthropic resume el criterio en una frase: buscar el conjunto más pequeño posible de tokens de alta señal que lleve al resultado deseado.
¿Por qué más contexto no siempre es mejor?
Según Anthropic, el contexto es un recurso finito con rendimientos decrecientes. A medida que la ventana se llena, baja la capacidad del modelo para recuperar con precisión lo que hay en ella, un patrón que el artículo llama context rot (degradación del contexto). Aparece en todos los modelos, aunque a ritmos distintos, y cada token añadido gasta parte del «presupuesto de atención» del modelo.
Un estudio académico anterior apunta en la misma dirección. En «Lost in the Middle» (Liu y otros, 2023), los modelos evaluados rendían mejor cuando la información relevante estaba al principio o al final de un contexto largo, y peor cuando estaba en el medio, incluso los diseñados para contextos largos. Es un resultado de 2023 con modelos de entonces, así que no lo tomes como una regla fija para los modelos actuales. La lección para diseñar es otra: meter todo en la ventana no sale gratis, y el orden y la selección importan.
¿Por qué le importa a un diseñador?
Porque el contexto es lo que el producto “recuerda” y “sabe” en un momento dado, y eso se diseña:
- Qué ve el usuario de lo que el modelo sabe. Si el agente consultó tres fuentes, la interfaz puede mostrar cuáles.
- Cuándo se olvida algo. Si el contexto se compacta, algunas cosas desaparecen. El usuario debe poder revisar y restaurar lo importante.
- Cuánta información entra. Más información no siempre significa mejor respuesta. Un fragmento irrelevante puede empeorar el resultado.
- Continuidad entre sesiones. Lo que se guarda fuera de la ventana, como notas de progreso, define qué puede retomar el agente mañana. Ver memoria en agentes.
¿Qué técnicas existen para tareas largas?
Anthropic menciona tres técnicas:
| Técnica | Qué hace | Cuándo funciona mejor |
|---|---|---|
| Compactación | Resume el contexto casi lleno y empieza de nuevo con el resumen | Conversaciones o tareas extensas |
| Notas estructuradas | Guarda el progreso fuera de la ventana y lo vuelve a cargar | Trabajo por hitos |
| Subagentes | Un agente especializado trabaja con su propio contexto y devuelve un resumen | Investigación en paralelo |
La compactación puede ser tan simple como borrar los resultados antiguos de herramientas, que es su forma más ligera. En los subagentes, cada uno trabaja en una ventana limpia y devuelve al agente principal un resumen condensado, que según el artículo suele ocupar entre 1.000 y 2.000 tokens. Anthropic sugiere elegir según la tarea: compactación para conversaciones fluidas, notas para trabajo iterativo por hitos y subagentes para investigación en paralelo.
Además, recomienda la recuperación justo a tiempo: en vez de cargar todos los datos de antemano, el agente guarda referencias ligeras, como rutas de archivos o consultas, y carga el contenido cuando lo necesita con una herramienta. Para dominios menos cambiantes, como el legal o el financiero, el artículo admite un enfoque híbrido: parte de los datos se carga al inicio y el agente explora el resto.
¿Cuándo NO conviene?
Cuando la tarea es corta y cabe por completo en un prompt. Montar compactación, notas y subagentes para una petición de una línea agrega complejidad sin beneficio; el propio artículo aconseja hacer lo más simple que funcione. Tampoco conviene si no mides qué pasa con el contexto: sin observar qué se carga y qué responde, no sabes si estás mejorando.
¿Cómo se aplica en tu producto?
- Haz un inventario del contexto. Lista todo lo que entra a una petición típica: instrucciones, herramientas, historial, documentos, resultados previos. Mide cuántos tokens ocupa cada bloque.
- Elimina lo redundante. Si dos herramientas hacen casi lo mismo, o dos instrucciones dicen lo mismo con palabras distintas, quédate con una.
- Carga bajo demanda. Mueve a una herramienta todo lo que solo se usa en casos concretos.
- Define qué se conserva al compactar. Escribe una lista de la información que nunca puede perderse, como decisiones del usuario o restricciones.
- Mide el efecto. Compara la calidad y el costo antes y después de cada cambio, con un conjunto de casos reales.
Ejemplo
Ejemplo ilustrativo: un agente de investigación de usuarios lee 40 entrevistas para producir un informe. Al principio carga todas las transcripciones, y el contexto se llena antes de llegar a la mitad. El equipo cambia el enfoque: el agente crea una nota por entrevista con tres hallazgos, guarda la lista de temas en un archivo de progreso y carga solo las notas relevantes para cada tema del informe. La calidad del informe sube y el diseñador puede ver, en la interfaz, qué entrevistas se usaron en cada sección.
Errores comunes
- Pensar que context engineering es solo un prompt más largo. Un mensaje de sistema inflado también gasta atención.
- Llenar la ventana con herramientas que se solapan.
- Compactar sin revisar qué información se pierde.
- No medir cómo cambia la respuesta cuando cambia el contexto.
- Guardar progreso en el chat en lugar de en un lugar que el agente pueda reconsultar.