Ingeniería de Contexto: Qué Es y Cómo la Uso para Construir Mejores Agentes de IA

Tabla de contenidos

Publicado en julio de 2026.

TL;DR: La ingeniería de prompts trata sobre la elección de palabras; la ingeniería de contexto trata sobre la arquitectura de la información. Tienes una ventana de contexto finita y cada token es una compensación. Estructuro el contexto del agente en cuatro capas: el prompt del sistema, el historial de conversación, el contenido recuperado y las salidas de herramientas. Tratar la ventana como un presupuesto, no como un lienzo en blanco, ha mejorado la fiabilidad más que cambiar de modelo.

[Nota del operador] Gestiono más de 30 agentes en producción. La mejora que más ha marcado la diferencia en el último año no es un modelo mejor ni un framework más sofisticado — es ser más deliberado sobre qué entra en la ventana de contexto y qué se queda fuera. La ingeniería de contexto es ahora la habilidad principal que busco al evaluar el trabajo con agentes.

La mayoría de las personas aún hablan de la “ingeniería de prompts” como la habilidad crítica para trabajar con IA. La ingeniería de prompts es real e importa. Pero es un subconjunto de una disciplina más amplia — y tratarla como el trabajo completo es la razón por la que muchos agentes que se ven bien en demos se desmoronan en producción.

Por qué “la ingeniería de prompts” se convirtió en el marco equivocado

“Ingeniería de prompts” implica que el palanca clave es el texto que escribes en el prompt del sistema o en el mensaje del usuario. Dedica suficiente tiempo a elaborar las instrucciones correctas, la redacción correcta, el formato correcto, y el modelo hará lo que necesitas.

Eso es cierto hasta cierto punto. Un prompt del sistema bien escrito es necesario. Pero el comportamiento del modelo está determinado por todo lo que hay en la ventana de contexto — no solo por tu prompt del sistema. Está moldeado por:

• El historial de conversación (lo que sucedió en turnos anteriores)
• Los documentos o datos que has recuperado e inyectado
• Los resultados de las llamadas a herramientas que el modelo ha visto hasta ahora
• El recuento de tokens y la posición de cada pieza de información

Si solo piensas en la redacción del prompt e ignoras el resto de lo que llena la ventana de contexto, estás optimizando una entrada mientras dejas las demás sin gestionar. Por eso “ingeniería de contexto” es el marco más preciso para el trabajo serio con agentes.

Qué es realmente la ingeniería de contexto

La ingeniería de contexto es la disciplina de decidir qué información entra en la ventana de contexto del modelo, en qué orden y en qué punto de la conversación.

La ventana de contexto es la memoria de trabajo del modelo. Es finita. Cada token que pones dentro desplaza algo más — o aumenta el costo. Y a diferencia de la memoria de trabajo humana, el modelo no tiene forma de “buscar algo” fuera de lo que hay en la ventana (a menos que le des herramientas para hacerlo). Lo que ve es todo lo que tiene.

La ingeniería de contexto es la práctica de tratar esa ventana como un recurso que se gestiona deliberadamente:

• ¿Qué necesita saber el modelo para completar este paso?
• ¿Qué necesitaba saber en un paso anterior pero ya no necesita?
• ¿Qué es estable entre ejecuciones vs. qué es dinámico por solicitud?
• ¿En qué parte de la ventana debe aparecer cada pieza de información?

Estas no son preguntas sobre redacción de prompts. Son preguntas de arquitectura de información. Y las respuestas determinan la fiabilidad del agente tanto como la selección del modelo.

Las cuatro capas que arquitecto

Cada agente que construyo tiene cuatro capas de contexto distintas. Pienso en cada una de ellas por separado.

Capa 1: El prompt del sistema

Esta es la base estable e independiente del turno. Define quién es el agente, qué puede hacer, qué no puede hacer y cómo debe manejar los casos extremos.

El error que comete la mayoría de las personas aquí es escribir el prompt del sistema una vez y tratarlo como terminado. En la práctica, el prompt del sistema necesita responder tres preguntas explícitamente:

1. ¿Para qué es este agente? (El modelo necesita un alcance preciso, no una misión vaga.)
2. ¿Qué debería hacer cuando la entrada es ambigua o incompleta?
3. ¿Qué no debería hacer nunca? (Las restricciones negativas importan.)

Mantén el prompt del sistema mínimo. Cada oración innecesaria es una sobrecarga que compite con el contenido dinámico donde ocurre el razonamiento real. Apunto a prompts del sistema que sean específicos y cortos en lugar de completos y largos.

Un consejo práctico: si estás usando Claude con la API, usa cache_control en tu prompt del sistema. Un prompt del sistema grande y estable que esté en caché cuesta aproximadamente el 10% de lo que costaría uno sin caché por turno.

Capa 2: Historial de conversación

En un agente de múltiples turnos, el historial de conversación es dinámico y crece con cada turno. Sin gestión, se convierte en el mayor impulsor de inflación de contexto — y la fuente más sigilosa de degradación del agente.

El problema: los turnos anteriores contienen información que el modelo ya no necesita. Mantener todo eso desperdicia tokens y puede confundir al modelo al darle contexto obsoleto del que razonar.

Lo que hago:

• Truncar o resumir turnos antiguos cuando el historial supera un umbral.
• Solo conservar los resultados de las llamadas a herramientas que siguen siendo relevantes.
• Nunca dejar que el historial crezca sin límites en un agente de larga duración.

Capa 3: Contenido recuperado

Esta es la capa que separa los agentes mediocres de los buenos. La mayoría de los agentes necesitan extraer datos externos en tiempo de ejecución — documentos, registros de bases de datos, resultados de búsqueda, respuestas de API.

Dos principios que aplico:

Recuperar solo lo relevante para el paso actual. No inyectes un documento de 50 páginas cuando el paso actual solo necesita una sección.

La posición importa. La información al principio y al final del contexto recibe más peso que la información en el medio. Si hay un fragmento recuperado que el modelo absolutamente debe usar, no lo entierres en el medio de una inyección larga.

Capa 4: Salidas de herramientas

En un bucle agéntico, el modelo llama a herramientas y obtiene resultados. Esos resultados van a la ventana de contexto como bloques de uso de herramientas. Se acumulan. Y a diferencia del historial de conversación, rara vez las personas piensan en gestionarlos.

La solución es la misma: después de que un resultado de herramienta haya cumplido su propósito, no necesitas conservarlo en la ventana. En un agente de múltiples pasos, llevo adelante un resumen estructurado de “lo que hemos establecido hasta ahora” en lugar de la salida bruta de cada paso anterior.

El presupuesto de contexto: qué incluir y qué eliminar

Uso un modelo mental simple: la ventana de contexto es un presupuesto y cada token es un gasto. Antes de cada turno del agente, me pregunto:

• ¿Qué necesita saber el modelo ahora mismo para hacer este paso?
• ¿Qué puedo dejar fuera o resumir sin perder nada importante?
• ¿Qué está duplicado entre capas?

El objetivo es empacar la ventana con la información de la mayor señal posible en cada paso, no ser exhaustivo.

Tres errores de ingeniería de contexto que cometí en producción

1. Marcas de tiempo flotantes en el prefijo estable. Ponía Fecha actual: {{fecha}} en la parte superior de mi prompt del sistema. Esa cadena cambia cada día, lo que invalidaba silenciosamente mi caché de prompts cada 24 horas. Mueve la información volátil — marcas de tiempo, IDs de usuario — al final del contexto, después del prefijo estable.

2. Tratar las salidas de herramientas como solo de adición. Ejecutaba bucles agénticos donde cada resultado de llamada a herramienta permanecía en el contexto. En el turno 8, el modelo razonaba desde un contexto que era 80% salidas de herramientas obsoletas que no necesitaba.

3. Omitir la evaluación en los cambios de contexto. Cuando cambié qué información entraba en la ventana de contexto, pensé que era un cambio “no funcional”. Definitivamente afectó las salidas. Los cambios de contexto son cambios en el comportamiento del modelo.

Mi flujo de trabajo de ingeniería de contexto en la práctica

Antes de escribir una sola línea de código del agente, bosquejo las capas de contexto:

Prompt del sistema:      ~500 tokens, estable, en caché
Presupuesto de historial: ~2000 tokens máx., resumido después de cada paso
Contexto recuperado:     ~1000-3000 tokens por paso, solo fragmentos relevantes
Presupuesto de salidas:  solo paso actual, resumido hacia adelante

La selección del modelo viene después. Una vez que sé qué ingeniería de contexto necesito hacer, elijo el modelo más barato que mantiene el estándar de fiabilidad bajo la configuración de contexto correcta.

Preguntas frecuentes

¿Cuál es la diferencia entre ingeniería de prompts e ingeniería de contexto?

La ingeniería de prompts se centra en la redacción de tu prompt del sistema y los mensajes del usuario. La ingeniería de contexto es la disciplina más amplia: decidir qué información entra en la ventana de contexto completa — incluyendo el historial de conversación, los datos recuperados y las salidas de herramientas — en qué orden y a qué costo de tokens.

¿Qué tan grande debe ser mi prompt del sistema?

Lo más pequeño posible mientras sea específico. Apunto a menos de 800 tokens para la mayoría de los agentes. Un prompt del sistema que intenta anticipar cada escenario termina siendo demasiado largo para que el modelo lo lea de manera fiable.

¿La ingeniería de contexto importa más para algunos modelos que para otros?

Importa para todos ellos, pero las apuestas son más altas con modelos más pequeños. Un modelo de frontera grande a veces puede recuperarse de un contexto mal estructurado; un modelo más pequeño con un presupuesto más ajustado no puede.

¿Cómo sé si mi ingeniería de contexto está funcionando?

Rastrea las mismas métricas que rastrearías para cualquier cambio de fiabilidad: tasa de éxito en tu conjunto de evaluación, costo por resultado exitoso y la distribución de errores por paso.

¿Debería siempre comprimir o resumir el historial?

Para agentes transaccionales cortos: no, la sobrecarga no vale la pena. Para agentes de múltiples turnos que ejecutan más de 5-6 intercambios: sí, siempre. La regla general que uso — una vez que el presupuesto del historial supera el 30% de mi presupuesto de contexto total, empiezo a resumir.