De prompt engineering a context engineering: el cambio real en sistemas con LLMs
1 de mayo de 2026
El prompt engineering no murió. Pero dejó de ser el problema difícil.
Durante 2023 y 2024, todo el mundo escribía prompts como si ahí estuviera la clave. En 2026, eso ya quedó corto.
El problema real ahora es otro: qué contexto ve el modelo en cada momento. Y eso tiene nombre: context engineering.
Puede ser que en dos años llamemos a esto de otra manera. No importa. Lo que importa es lo que hay debajo del nombre.
Lo que cambió, sin vueltas
Cuando trabajabas con un LLM vía chat, había un input y un output. Vos escribías, el modelo respondía. Hacer un buen prompt era gran parte del laburo. Lógico.
Pero los sistemas reales ya no son chats.
Son agentes que hacen 30 turnos seguidos, llaman herramientas, leen documentos, mantienen estado entre sesiones, delegan a sub-agentes. En esa arquitectura, el prompt original es solo una parte más de todo lo que el modelo termina viendo.
El resto del contexto incluye:
- la conversación previa
- los resultados de tools
- documentos recuperados (RAG)
- memoria de sesiones anteriores
- el system prompt
- definiciones de tools
- ejemplos few-shot
- output de sub-agentes
Toda esa pila se arma dinámicamente en cada turno. El modelo no responde en base al prompt: responde en base a todo eso junto.
Optimizar solo el prompt es como obsesionarte con la fuente del email cuando el destinatario está mal.
Un ejemplo concreto del cambio
Antes: el system prompt era el "nucleo". "Sos un asistente que responde dudas técnicas. Sé claro, conciso, da ejemplos." Iterabas esa frase veinte veces buscando la combinación mágica de palabras. Ahora: el system prompt es estable y corto. Lo que cambia entre llamadas es qué documentos trajiste con RAG, qué tools exponés según la pregunta, qué parte del historial mantenés vivo, qué memoria recuperaste de sesiones anteriores. La inteligencia se movió del prompt al sistema que arma el contexto.
Qué es context engineering, en una frase
Es la disciplina de diseñar el sistema que decide qué meter en el contexto del modelo en cada turno.
No es una técnica. Es una capa de arquitectura. Decisiones tipo:
- ¿Qué tools le expongo al modelo en este turno? ¿Todas o solo las que aplican?
- ¿Cuánto del historial guardo? ¿Resumo, comprimo, descarto?
- ¿Qué traigo de memoria a largo plazo? ¿Cuándo lo trigereo?
- ¿Cuándo delego a un sub-agente vs cuándo sigo en este?
- ¿Qué cacheo para no procesarlo de nuevo?
- ¿En qué orden van los mensajes? Spoiler: importa muchísimo.
Cada una es una decisión de software engineering. No es buscar palabras mágicas. Es diseñar un sistema que arme el input correcto para cada situación.
Más contexto NO es mejor
Esta es la parte que poca gente entiende.
La intuición sería: "si el modelo tiene más info, decide mejor". Falso. Los LLMs tienen tres patologías que aparecen apenas el contexto se llena:
Instruction drift
El modelo arranca siguiendo el system prompt. A los 20 turnos, lo ignora. No es que se "olvide": las instrucciones nuevas, los tool results y los mensajes del usuario pesan más en su atención que las reglas del principio.
Recency bias
Lo último que leyó tiene más peso que lo que leyó al principio. Cualquier regla crítica que hayas puesto al inicio compite con muchísimo ruido posterior.
Compaction loss
Cuando algún sistema (Claude, Cursor, lo que sea) comprime el contexto para que entre, pierde cosas. Decisiones arquitectónicas tomadas hace 30 turnos, nombres de variables, restricciones del usuario. Y no te avisa.
La conclusión es contraintuitiva: el trabajo del context engineer es decidir qué dejar afuera, no qué meter adentro.
Las decisiones que realmente importan
En la práctica, context engineering se reduce a cuatro decisiones recurrentes:
Selección de tools
No le des al modelo todas las tools que tenés. Filtrá según la fase de la tarea. Un agente investigando no necesita las tools de escritura. Un agente debuggeando no necesita las tools de research. Esto reduce alucinaciones de tool use y baja costo.
Compresión de historial
En conversaciones largas, los primeros turnos pierden valor rápido. Estrategias: resumir turnos viejos, descartar tool outputs que ya se procesaron, mantener solo los mensajes que cambian estado.
Recuperación de memoria
Memoria persistente bien hecha no es "guardar todo y traerlo siempre". Es traer lo relevante para esta query específica. RAG sobre tu propia memoria, básicamente.
Delegación
Cuando una tarea se complica, no estires el contexto: lanzá un sub-agente con contexto nuevo que haga ese pedazo y devuelva un resumen. El agente principal se queda lean.
Caching, scoping, compression, delegation. Cosas que ya hacés en cualquier backend serio.
Esto se conecta con cosas que ya conocés
Nada de esto es realmente nuevo si trabajaste en sistemas.
Las metáforas mentales son las mismas que ya tenés:
- Tools disponibles ≈ feature flags
- Historial comprimido ≈ caché con TTL
- Memoria recuperada ≈ query de DB con WHERE bien pensado
- Sub-agente delegado ≈ worker con su propio contexto
- Prompt cache ≈ memoización
Le estás dando al modelo algo más parecido a un runtime dinámico que a un input estático.
El cambio mental
Prompt engineering te ponía en modo escritor. Pensabas en palabras, ejemplos, instrucciones.
Context engineering te pone en modo arquitecto. Pensás en flujo de información, en qué necesita el modelo en cada momento, en cómo orquestás lo que entra y lo que sale.
Cierre
El prompt ya no es el programa.
Es apenas una parte del input.
El programa ahora es el sistema que decide qué ve el modelo.