En 2025, Andrej Karpathy escribió algo que se hizo viral en los círculos de desarrollo de IA: context engineering, not prompt engineering, is the new skill. Un año después, Gartner lo confirmó nombrando el context engineering como la "capacidad de IA de ruptura de 2026". Si pasaste el último año optimizando cómo redactas instrucciones para el modelo, hay algo que cambia el marco completo.
Prompt engineering vs context engineering: la diferencia real
El prompt engineering se enfoca en cómo redactas la instrucción que le das al modelo. El context engineering pregunta algo más amplio: ¿qué información completa necesita el modelo para hacer bien su trabajo en este paso específico?
La diferencia no es solo semántica. En un sistema simple —una consulta, una respuesta— optimizar el prompt puede ser suficiente. En un sistema agéntico con múltiples pasos, herramientas, memoria y documentos, el prompt es solo una fracción pequeña de lo que el modelo procesa.
El contexto completo que el modelo ve incluye: las instrucciones del sistema, el historial de la conversación o los pasos anteriores del agente, los resultados de las herramientas que llamó, los fragmentos de documentos recuperados por RAG, los ejemplos que usas para guiar el comportamiento (few-shot), y cómo está ordenada toda esa información dentro de la ventana de tokens.
Context engineering es la disciplina de diseñar ese entorno completo de manera deliberada, no solo escribir la instrucción.
Por qué los agentes de IA lo cambiaron todo
En un chatbot básico, el modelo ve: system prompt + mensaje del usuario. El contexto es manejable y estático.
En un agente que planifica y ejecuta tareas de varios pasos, el modelo ve: el historial de todos los pasos anteriores, los resultados de las herramientas que llamó (puede ser mucho texto), el estado actual de la tarea, las instrucciones para el paso actual, y todo eso junto tiene que caber en la ventana de contexto sin perder coherencia.
El 70% de los agentes que fallan en producción no fallan por el modelo. Fallan porque el contexto que le llega al modelo está mal diseñado: hay demasiada información irrelevante, falta información crítica, o la señal se pierde en el ruido.
Qué incluye el context engineering en la práctica
No es teoría abstracta. En un sistema real, context engineering incluye decisiones concretas como:
- ▸¿Cuánto historial de conversación incluyo? ¿Lo sumarizo o lo corto en algún punto?
- ▸¿Cómo formateo los resultados de herramientas para que el modelo los procese sin confusión?
- ▸¿Cuántos fragmentos de RAG recupero? ¿Los ordeno por relevancia o por fecha?
- ▸¿Incluyo ejemplos de salidas esperadas (few-shot) y cuántos son suficientes sin saturar tokens?
- ▸¿Cómo mantengo el estado del agente para que no "olvide" el objetivo a mitad de una tarea larga?
Cada una de estas decisiones afecta directamente la calidad, el costo y la latencia de tu sistema. No es optimizar la redacción del prompt —es arquitectura de información.
El error más común: meter todo y esperar que el modelo se aclare
La tentación inicial es incluir la mayor cantidad de contexto posible y dejar que el modelo lo procese. El problema: los modelos de lenguaje son sensibles a la posición de la información dentro del contexto. Lo que aparece al inicio y al final del context window tiene más peso que lo del medio. Si saturan el contexto con datos irrelevantes, la señal crítica se pierde.
Lo que nadie te dice al principio: a veces menos contexto da mejores resultados. Un contexto bien curado de 2,000 tokens puede superar en consistencia a un contexto desordenado de 8,000. La clave es la relevancia para el paso actual, no el volumen total.
Cómo se ve en acción: un agente con LangGraph
Imagina un agente de análisis de contratos construido con LangGraph. El agente revisa un contrato, identifica cláusulas problemáticas, busca precedentes y genera un resumen ejecutivo.
Sin context engineering: el agente mete el contrato completo (20 páginas) en cada llamada al LLM, más el historial de todos los pasos anteriores. El modelo pierde el hilo, las respuestas son inconsistentes, el costo por ejecución es alto.
Con context engineering: en cada nodo del grafo, el agente pasa solo la sección relevante del contrato (chunked con RAG), el estado actual de la tarea (qué revisó, qué falta), y las instrucciones específicas para ese paso. El resultado es consistente, el costo baja en torno al 60%, y el modelo rara vez alucina porque tiene exactamente lo que necesita.
Esa diferencia —entre un agente que funciona en demos y uno que funciona en producción— es context engineering.
Por qué 2026 es el momento de aprenderlo
Tres fuerzas convergen este año: los agentes de IA pasaron de ser un tema de investigación a ser el centro de los productos de software, las ventanas de contexto se expandieron (algunos modelos llegan a 1M+ tokens) lo que hace más complejo decidir qué incluir, y el costo de inferencia empieza a bajar lo que significa más agentes con más llamadas en producción real.
Los perfiles que el mercado empieza a buscar no son solo "alguien que sepa hacer prompts" —son engineers que entienden cómo diseñar el flujo de información en un sistema de IA de múltiples pasos. Esa es la habilidad que diferencia al AI Engineer que trabaja en un demo del que trabaja en producción.
Cómo aprenderlo con proyectos reales
Context engineering no es un tema que se aprende con un tutorial de 10 minutos. Se aprende construyendo sistemas que fallan y entendiendo por qué. En la ruta AI Agentic Engineer de DataPath, construyes agentes con LangGraph y CrewAI en proyectos aplicados donde te enfrentas exactamente a estos problemas: qué meterle al modelo, cuándo sumarizar, cómo manejar el estado entre nodos.
Si tu punto de partida está en los fundamentos —entender cómo funcionan los LLMs, RAG y las APIs antes de subir a orquestación—, la ruta AI Engineer te da ese piso primero.
Empieza aquí
→ Ruta AI Agentic Engineer: construye agentes de producción con LangGraph, CrewAI y context engineering aplicado
→ Ruta AI Engineer: fundamentos de LLMs, RAG y arquitectura para developers que parten desde cero
