Si en 2024 la palabra de moda era prompt engineering, en 2026 es context engineering. Gartner lo nombró una de sus tendencias tecnológicas estratégicas del año, y no es solo una etiqueta nueva para lo mismo de siempre: cambia cómo se construyen los agentes que de verdad funcionan fuera de un demo.
Qué es exactamente
Prompt engineering optimiza la pregunta: cómo redactas la instrucción para que el modelo responda mejor. Context engineering optimiza las condiciones bajo las cuales el agente responde esa pregunta: qué memoria tiene disponible, qué herramientas puede usar, qué pasó en los últimos diez pasos, qué documentos puede consultar y cuáles no. Gartner lo define como diseñar el contexto en tiempo de ejecución que un agente usa para decidir.
Por qué reemplaza al prompt engineering
La idea detrás de este giro es simple y un poco incómoda: la mayoría de los fallos de un agente no son fallos del modelo, son fallos de contexto. Le pides a un agente que resuelva un ticket de soporte y falla, no porque el LLM sea malo, sino porque nunca tuvo acceso al historial completo del cliente o perdió esa información tres pasos antes. Gartner proyecta que para fin de 2026 el 40% de las aplicaciones empresariales va a tener agentes para tareas específicas, frente a menos del 5% en 2025. Con ese volumen, ya no alcanza con escribir un buen prompt una vez: el contexto hay que diseñarlo como arquitectura.
Un ejemplo que se entiende rápido
Imagina un agente que responde tickets de soporte. Con prompt engineering, el trabajo termina cuando escribes una instrucción clara: "responde de forma empática y resuelve el problema". Con context engineering, el trabajo recién empieza ahí: el agente necesita el historial de compras del cliente, los tickets anteriores que abrió, el estado actual de su pedido en el sistema de logística, y una forma de saber cuándo escalar a un humano en vez de inventar una respuesta. Nada de eso lo resuelve un mejor prompt. Lo resuelve una arquitectura de contexto bien diseñada.
Lo mismo pasa con un agente que arma reportes de datos: puede tener acceso al mejor modelo del mercado, pero si no sabe qué tabla es la fuente de verdad en tu empresa o qué métricas ya están deprecadas, va a producir reportes bonitos y equivocados con la misma seguridad con la que produciría uno correcto.
Cómo se ve esto en la práctica
- ▸Memoria de corto y largo plazo: qué recuerda el agente de esta conversación y qué recuerda de conversaciones pasadas
- ▸Recuperación de información (RAG) solo cuando aporta algo, no como relleno por defecto en cada llamada
- ▸Estado persistente entre pasos del agente, con checkpoints que permiten retomar donde quedó
- ▸Un humano en el loop como parte del diseño del contexto, no como un parche de emergencia cuando el agente se equivoca
Lo que nadie te dice al empezar es que más contexto no es mejor contexto. Meter todo el historial de la conversación en cada llamada solo sube el costo y, muchas veces, confunde al modelo con información irrelevante. La disciplina real de context engineering está en decidir qué se queda afuera, no en cuánto puedes meter.
Los cuatro ingredientes del contexto
Me resulta útil pensar el contexto de un agente en cuatro capas que se diseñan por separado. La primera son las instrucciones: no el prompt completo, sino las reglas fijas que no cambian entre llamadas, como el tono o los límites de lo que el agente puede decidir solo. La segunda es el conocimiento: documentos, políticas, catálogos, todo lo que el agente puede consultar pero que no necesita memorizar de entrada, por eso el RAG entra aquí y no en las instrucciones.
La tercera capa son las herramientas: qué APIs, funciones o sistemas puede invocar, y con qué permisos. Y la cuarta es la memoria: lo que pasó antes, dentro de esta conversación y entre conversaciones distintas. El error más común que veo es tratar estas cuatro capas como una sola bolsa de texto que se concatena y se manda entera al modelo en cada llamada. Separarlas te obliga a decidir, capa por capa, qué entra y qué no.
Cómo empezar a practicarlo
Empieza por auditar un agente que ya tengas (o uno de ejemplo): anota qué contexto recibe hoy y qué contexto necesitaría de verdad para tomar mejores decisiones. La diferencia entre ambas listas es tu primer rediseño. Para implementarlo, LangGraph te da checkpointing y manejo de memoria nativos, y si tu caso necesita varios agentes coordinándose, CrewAI resuelve bien el reparto de contexto entre roles.
Si quieres aprender esto con proyectos reales y no solo con teoría, la ruta AI Agentic Engineer está armada justo alrededor de esta arquitectura: memoria, orquestación y despliegue en producción.
Errores comunes que vas a cometer igual
- ▸Guardar absolutamente todo en memoria de largo plazo, incluyendo intercambios triviales que nunca se vuelven a consultar
- ▸Confundir dar más herramientas con dar mejor contexto: un agente con 40 funciones disponibles decide peor que uno con las 5 que de verdad necesita
- ▸No versionar el contexto: cambias las instrucciones del agente en producción y no puedes saber qué versión generó qué respuesta cuando algo sale mal
Ninguno de estos errores se resuelve leyendo sobre el tema; se resuelven construyendo un agente, viéndolo fallar y ajustando. Por eso insisto en empezar chico: el primer agente real que construyas te va a enseñar más sobre context engineering que diez artículos, este incluido.
El costo que nadie menciona
Meter más contexto no es gratis. Cada token que agregas a la ventana de contexto se paga, y con modelos de un millón de tokens es tentador volcar ahí toda la documentación de la empresa "por si acaso". El resultado suele ser el contrario al que buscas: el modelo tarda más, cuesta más, y en varios casos pierde precisión porque tiene que decidir qué parte del contexto es relevante en vez de que tú se la hayas dado ya filtrada. El caching de prompts ayuda con el costo cuando reutilizas el mismo bloque de contexto entre llamadas, pero no resuelve el problema de fondo: diseñar qué entra y qué no.
Un consejo antes de que te lances a rediseñar todo
No intentes aplicar context engineering a los diez agentes de tu empresa el mismo mes. Elige el que más falla hoy, audítalo, arregla su contexto y mide si bajó la tasa de error. Ese ciclo de una semana te va a enseñar más que cualquier framework teórico, y es el mismo método que vas a repetir con cada agente nuevo que construyas.
Un buen punto de partida, si todavía no tienes un agente propio corriendo: construye uno chico con un solo caso de uso real (por ejemplo, responder preguntas sobre un documento interno) antes de pensar en orquestar varios agentes entre sí. Vas a cometer errores de diseño de contexto en ese primer agente de todos modos; mejor cometerlos a pequeña escala que después de haber invertido semanas en una arquitectura multi-agente completa.
Si quieres practicar esto con otras personas que están resolviendo lo mismo, cada semana hacemos un taller en vivo en la Comunidad AI Builders, desde 19 USD al mes. Y en nuestro catálogo de cursos tienes el resto de las piezas para construir agentes completos.
