¿Qué es Context Engineering?
Un modelo no responde solamente al prompt: responde a todo lo que tiene disponible en ese momento. La ingeniería de contexto diseña ese entorno de información para que el sistema reciba lo necesario, en el momento adecuado y sin quedar enterrado bajo datos irrelevantes.
Context Engineering, o ingeniería de contexto, es la disciplina de diseñar, seleccionar, organizar, recuperar y mantener la información y los recursos que un modelo o agente recibe durante la inferencia para aumentar la probabilidad de que produzca el comportamiento esperado. Incluye instrucciones, datos, memoria, historial, herramientas, ejemplos, estado y resultados intermedios; por eso es más amplia que el Prompt Engineering.
Qué es Context Engineering
Los modelos de lenguaje trabajan sobre un contexto de inferencia: el conjunto de tokens e información que pueden utilizar para decidir la siguiente salida o acción. Ese contexto puede incluir el mensaje del usuario, instrucciones del sistema, documentos recuperados, historial, memoria, descripciones de herramientas, resultados de APIs, ejemplos, archivos y estado intermedio.
Context Engineering convierte esa selección en un problema de diseño. La pregunta deja de ser únicamente “¿cómo redacto mejor este prompt?” y pasa a ser “¿qué necesita ver el modelo ahora para resolver esta tarea con la mayor fiabilidad posible?”. Anthropic lo plantea como la curaduría del conjunto óptimo de información disponible durante la inferencia y subraya que el contexto es un recurso finito.
Diseñar el entorno informativo de la inferencia. Decide qué instrucciones, datos, memoria, herramientas y estado entran al contexto, cómo se estructuran y cuándo se recuperan.
Llenar la ventana de contexto. Más tokens no garantizan mejor desempeño; el exceso de información puede introducir ruido, contradicciones y pérdida de foco.
Context Engineering: diferencias con conceptos cercanos
| Concepto | Qué resuelve | Relación con Context Engineering |
|---|---|---|
| Prompt Engineering | Redacción y estructura de instrucciones y ejemplos. | Es una parte del problema: la ingeniería de contexto también decide datos, memoria, herramientas, historial y estado. |
| RAG | Recupera información externa para incorporarla antes de generar. | Es una técnica posible de provisión dinámica de contexto, no un sinónimo de Context Engineering. |
| Memoria | Conserva información útil entre pasos o sesiones. | Es una fuente de contexto que debe decidir qué recordar, cuándo recuperar y cuándo descartar. |
| Fine-tuning | Modifica el comportamiento aprendido ajustando parámetros del modelo. | Context Engineering trabaja principalmente con información suministrada en tiempo de inferencia, sin cambiar los pesos del modelo. |
| MCP | Estandariza conexiones entre modelos, herramientas y fuentes. | Puede facilitar el acceso a contexto y herramientas, pero es un protocolo, no la disciplina completa. |
Qué forma parte del contexto
En un sistema real, el contexto no es un único bloque de texto. Suele combinar capas persistentes y dinámicas que cambian según la tarea. Google Cloud distingue instrucciones persistentes, memoria semipersistente y datos dinámicos, una separación útil para decidir qué debe estar siempre presente y qué conviene recuperar sólo cuando hace falta.
| Componente | Ejemplos | Decisión de diseño |
|---|---|---|
| Instrucciones | Rol, objetivos, políticas, formato, criterios. | Mantener reglas estables, claras y a la altura correcta de abstracción. |
| Datos y retrieval | Documentos, web, bases de datos, CRM, resultados de búsqueda. | Recuperar sólo información pertinente, fresca y autorizada. |
| Memoria e historial | Preferencias, decisiones previas, resúmenes, estado de una conversación. | Persistir lo útil sin arrastrar ruido, errores o datos sensibles innecesarios. |
| Herramientas | APIs, buscadores, código, calendario, archivos, bases de datos. | Ofrecer el conjunto mínimo útil y describir claramente capacidades y límites. |
| Estado intermedio | Plan, archivos temporales, cálculos, notas, outputs de herramientas. | Conservar lo que ayuda al siguiente paso y compactar lo que ya cumplió su función. |
Principios para diseñar buen contexto
Relevancia antes que volumen. El objetivo es el menor conjunto de información de alta señal que permita resolver bien la tarea, no la ventana más llena posible.
Información en el momento adecuado. Recuperar datos just in time evita cargar por adelantado todo el universo posible y permite que el contexto evolucione con la tarea.
Estructura y separación. Distinguir instrucciones, evidencia, resultados de herramientas y contenido no confiable reduce ambigüedad y mezcla de funciones.
Frescura y procedencia. Cuando la tarea depende de hechos cambiantes, el contexto debe incluir fuentes actuales y permitir verificar de dónde proviene cada afirmación relevante.
Permisos mínimos. El contexto también incluye qué herramientas y datos puede usar el sistema. Exponer más capacidades de las necesarias aumenta costo y superficie de error.
Cómo trabajar el contexto paso a paso
Definir la tarea y los fallos importantes. Precisar qué resultado se espera, qué errores serían graves y qué información necesita una persona competente para resolverlo.
Inventariar fuentes y estado. Separar reglas permanentes, datos recuperables, memoria, herramientas y artefactos de trabajo.
Elegir qué precargar y qué recuperar. Mantener el contexto base pequeño y traer información dinámica cuando la tarea lo exige.
Ordenar y delimitar. Presentar contexto con estructura explícita, metadata útil y separación entre instrucciones, evidencia y contenido externo.
Compactar y podar. Resumir historial o resultados extensos y descartar información que ya no influye en la decisión actual.
Evaluar con casos reales. Comparar variantes de contexto contra un conjunto representativo de tareas y fallos, no sólo contra demos favorables.
Context Engineering en agentes y tareas de largo horizonte
Los agentes producen nuevos datos en cada paso: resultados de herramientas, archivos, decisiones y observaciones. Si todo se conserva de forma literal, el contexto crece hasta volverse caro y ruidoso. Por eso aparecen técnicas como compacción, notas estructuradas, memoria persistente, recuperación selectiva y subagentes.
Anthropic describe la compacción como resumir el estado relevante para continuar en una nueva ventana y propone la recuperación progresiva como alternativa a precargar todos los datos. OpenAI también usa compacción y un entorno de archivos/herramientas para sostener trabajos largos sin pegar cada artefacto directamente en el prompt.
La ventana de contexto no es una base de conocimiento. Que algo pueda entrar técnicamente no significa que convenga mantenerlo activo durante toda la tarea.
Cómo evaluar si el contexto está bien diseñado
La calidad se evalúa por el comportamiento del sistema, no por cuántos documentos o tokens se cargaron. Google Cloud plantea la ingeniería de contexto como un proceso iterativo: construir un contexto inicial, medir contra datos de referencia, analizar fallos y ajustar.
| Dimensión | Qué observar |
|---|---|
| Calidad | Exactitud, cumplimiento de instrucciones, relevancia y consistencia. |
| Grounding | Si las afirmaciones importantes están sustentadas por las fuentes disponibles. |
| Uso de herramientas | Selección correcta, argumentos adecuados y ausencia de llamadas innecesarias. |
| Costo y latencia | Tokens, llamadas, tiempo de respuesta y trabajo redundante. |
| Robustez | Comportamiento ante datos faltantes, contradicciones, contexto largo y casos límite. |
Ejemplo de Context Engineering
Supongamos un agente que debe preparar un informe semanal de ventas. Un enfoque débil podría pegar en el prompt el manual comercial entero, meses de historial del CRM, todas las métricas disponibles y la descripción de cada herramienta.
Contexto persistente: objetivo del informe, políticas, formato esperado y permisos.
Contexto dinámico: período solicitado, equipo, pipeline y métricas recuperadas del CRM para esa semana.
Herramientas: sólo consultas necesarias para ventas y analytics, con descripciones claras.
Estado intermedio: anomalías detectadas y cálculos relevantes, no todos los outputs crudos.
Verificación: cada cifra crítica se contrasta con la fuente antes de redactar la conclusión.
El modelo puede ser exactamente el mismo. Lo que cambia es la calidad de la información que recibe, cómo está organizada y cuándo aparece.
Errores frecuentes en Context Engineering
Cargar todo “por las dudas”
El exceso de contexto introduce ruido y aumenta costo. Priorizar relevancia y recuperación selectiva.
Intentar arreglar con prompts un problema de datos
Si falta evidencia, el historial es incorrecto o la herramienta devuelve información pobre, reescribir instrucciones no resuelve la causa.
Arrastrar memoria obsoleta
La memoria útil ayer puede ser falsa o irrelevante hoy; necesita políticas de actualización, prioridad y descarte.
Exponer demasiadas herramientas
Un catálogo enorme y solapado dificulta la selección. Anthropic recomienda conjuntos de herramientas claros, diferenciados y evaluados.
No medir el contexto como parte del sistema
Sin evals es difícil saber si una mejora aparente se sostiene en tareas reales o sólo funciona en un ejemplo.
Preguntas frecuentes sobre Context Engineering
¿Qué es Context Engineering?
Context Engineering, o ingeniería de contexto, es la disciplina de diseñar y gestionar la información y los recursos que un modelo o agente recibe durante la inferencia para aumentar la probabilidad de que actúe correctamente.
¿Cuál es la diferencia entre Context Engineering y Prompt Engineering?
Prompt Engineering se concentra en cómo redactar y estructurar instrucciones. Context Engineering abarca además datos recuperados, historial, memoria, herramientas, ejemplos, estado y otros elementos que forman el contexto disponible para el modelo.
¿Context Engineering es lo mismo que RAG?
No. RAG es un patrón para recuperar información externa y añadirla al contexto antes de generar una respuesta. Puede ser una técnica dentro de Context Engineering, pero la ingeniería de contexto incluye muchas otras decisiones.
¿Más contexto siempre mejora el resultado?
No. Agregar información irrelevante, redundante o contradictoria puede degradar el rendimiento. La meta es aportar el contexto suficiente, pertinente y actualizado para la tarea.
¿Qué papel tienen la memoria y las herramientas?
La memoria aporta estado útil entre pasos o sesiones y las herramientas permiten consultar datos o actuar sobre sistemas. Sus descripciones, permisos, resultados y momento de uso también forman parte del contexto que debe diseñarse.
¿Cómo se evalúa una estrategia de contexto?
Con tareas representativas y métricas de calidad, precisión, costo, latencia y seguridad, comparando variantes de recuperación, memoria, herramientas, compacción y estructura del contexto.
Fuentes y referencias
1. Anthropic. Effective context engineering for AI agents. 2025.
2. Google Cloud. ¿Qué es la ingeniería de contexto de la IA?. Actualizado en 2026.
3. Google Cloud Documentation. Build context sets using the context engineering agent.
4. OpenAI. From model to agent: Equipping the Responses API with a computer environment. 2026.
5. Anthropic. Writing effective tools for AI agents. 2025.