Context Engineering: Por Qué Reemplazó al Prompt Engineering en 2026

Durante dos años la conversación giró en torno al prompt: cómo redactar mejor la instrucción, qué frases mágicas añadir, cómo pedirle al modelo que "piense paso a paso". En 2026 esa discusión quedó atrás, y no porque el prompt dejara de importar, sino porque se volvió la parte fácil.

La disciplina que separa a un agente que funciona de uno que no se llama context engineering: diseñar qué información entra en la ventana de contexto del modelo en cada turno. Si el prompt optimiza la pregunta, el context engineering optimiza las condiciones bajo las que esa pregunta se responde.

El cambio de escala

Un chatbot recibía una pregunta y devolvía una respuesta. Un agente hace algo distinto: mantiene una conversación larga, consulta herramientas, recibe resultados, decide el siguiente paso y repite. En cada uno de esos turnos hay que decidir qué meter en el contexto.

Y ahí aparece el problema real: la ventana de contexto es finita, cuesta dinero, y —lo que casi nadie dice— el rendimiento se degrada mucho antes de llenarla. Un agente con demasiado contexto irrelevante no es un agente mejor informado: es uno distraído, que pierde la instrucción importante entre ochenta mensajes de historial.

Los cuatro insumos que compiten por el espacio

Instrucciones. Quién es el agente, qué puede y qué no puede hacer, cómo debe escalar. Es lo que antes llamábamos prompt, y hoy es solo una cuarta parte del problema.

Definiciones de herramientas. Cada herramienta disponible ocupa espacio en el contexto solo por estar declarada. Un agente con cuarenta herramientas gasta una porción considerable de su ventana en describirlas, y además elige peor: demasiadas opciones parecidas confunden la selección. Menos herramientas y mejor descritas casi siempre gana.

Memoria. El historial de la conversación crece sin parar. La decisión de qué conservar, qué resumir y qué descartar es una de las que más impacto tiene y de las que menos se piensan.

Datos recuperados. Los hechos de tu empresa que el agente necesita para responder. Aquí es donde se decide si el agente dice la verdad o improvisa.

Las cuatro estrategias

Seleccionar

Traer solo lo relevante para este turno, no todo lo que podría ser útil. Meter el catálogo completo en el contexto es la solución más común y la peor: cuesta más, responde peor y encima el modelo tiende a mezclar productos parecidos. La alternativa es recuperar los tres o cuatro hechos pertinentes en el momento.

Comprimir

Cuando la conversación se alarga, resumir los turnos viejos conservando lo que cambia decisiones —qué producto le interesa, qué presupuesto mencionó, qué ya se le cotizó— y soltar el resto. Un resumen de cuatro líneas suele ser más útil que cuarenta mensajes completos.

Aislar

En lugar de un agente que lo sabe todo, varios agentes especializados, cada uno con su propio contexto acotado y su propio conjunto reducido de herramientas. Es la lógica que desarrollamos en crews multi-agente: dividir para que cada contexto se mantenga limpio.

Escribir fuera

Lo que el agente aprende no tiene por qué vivir en la conversación. Puede escribirse a un almacén externo —una nota, un registro, un grafo— y recuperarse cuando haga falta. Así la memoria deja de competir por el espacio del contexto y sobrevive entre conversaciones distintas.

Dónde encaja el grafo de conocimiento

Las dos estrategias más difíciles —seleccionar bien y escribir fuera— son exactamente el problema que resuelve un grafo de conocimiento. En lugar de decidir qué documentos meter en el contexto, el agente consulta una red estructurada de entidades y relaciones, y trae los hechos concretos que necesita.

La diferencia con la búsqueda por similitud de un sistema RAG clásico es que el grafo devuelve hechos con relaciones y con vigencia, no fragmentos de texto parecidos a la pregunta. Para el context engineering eso es enorme: entra menos texto, y el que entra es más denso en información útil.

Cuatro errores que vemos seguido

• Pegar el catálogo completo en el prompt. Funciona en la demo con doce productos y se derrumba con mil doscientos.
• Acumular herramientas. Cada una que agregas empeora la selección de todas las demás. Si dos hacen algo parecido, sobra una.
• Historial infinito. Conservar todo por si acaso, hasta que la instrucción principal queda sepultada y el agente empieza a ignorarla.
• Tratar el prompt como la palanca. Cuando el agente falla, la reacción instintiva es reescribir instrucciones. Casi siempre el problema es que le llegó el contexto equivocado.

La pregunta que ordena todo

Cuando un agente responde mal, antes de tocar el prompt vale la pena preguntarse: ¿tenía en el contexto lo que necesitaba para responder bien?

Si la respuesta es no, ningún ajuste de redacción lo va a arreglar — el problema es de recuperación de datos. Si la respuesta es sí y aun así falló, entonces sí toca revisar instrucciones. Distinguir entre esos dos casos es, en la práctica, casi todo el trabajo.