Imagina que contratas a un consultor brillante. Tiene dos doctorados, habla siete idiomas, y resuelve problemas que tú ni sabías que tenías. Le sientas en una sala y le dices: «necesito que refactorices la autenticación del proyecto».
El consultor te mira, asiente, y pregunta: «¿Qué proyecto?»
No le has dado acceso al código. No le has explicado la arquitectura. No sabe si usas tokens JWT o cookies de sesión. No sabe qué lenguaje usáis, ni cuántos microservicios hay, ni por qué el último intento de migración acabó en desastre.
Ese consultor es tu LLM. Y tú acabas de cometer el error que comete el 90% de la gente que trabaja con agentes de IA: preocuparte por el cerebro en vez de preocuparte por lo que el cerebro ve.
Prompt engineering está muerto. Larga vida a context engineering.
Llevo meses viendo la misma conversación en cada foro, en cada thread de Twitter, en cada reunión de equipo: «¿GPT-5 o Claude Opus?», «¿qué modelo es mejor para código?», «¿cuál razona mejor?».
Y la respuesta, cada vez que hago las cuentas, es la misma: da igual. Bueno, no da exactamente igual. Pero la diferencia entre un modelo top y otro modelo top es marginal comparada con la diferencia entre darle buen contexto o darle basura.
Un modelo mediocre con contexto perfecto gana a un modelo top con contexto basura. Siempre. Sin excepciones.
Esto tiene un nombre: context engineering. Y no, no es lo mismo que prompt engineering.
Prompt engineering es escribir un buen prompt. Es elegir las palabras correctas, estructurar la petición, añadir ejemplos. Es importante, pero es solo una pieza.
Context engineering es diseñar todo lo que el modelo ve: qué información entra, en qué orden, qué se descarta cuando no cabe, qué se comprime, qué se preserva a toda costa. Es arquitectura de la información para LLMs.
Dicho en cristiano: prompt engineering es redactar una buena pregunta. Context engineering es decidir qué libros tiene el alumno en el pupitre antes de empezar el examen.
Las cuatro fases de la memoria: un ciclo de vida que no ves
OpenAI publicó recientemente dos Cookbook articles que desmontan cómo funciona la gestión de contexto en agentes con memoria a largo plazo. No es RAG. No es una base de datos vectorial. Es un sistema de estados que funciona como un cuaderno de campo con reglas estrictas.
El patrón es local-first y state-based: un objeto de estado estructurado que viaja con el agente y se actualiza en cada fase.
flowchart TD
A["1. INJECTION\n(inicio de sesión)"] --> B["2. DISTILLATION\n(durante conversación)"]
B --> C["3. CONSOLIDATION\n(post-sesión)"]
C --> D["4. TRIMMING\n(preservación)"]
D -->|"Nueva sesión"| A
A1["Renderiza estado como YAML\n+ memorias globales (máx 6)\n+ reglas de precedencia"] -.-> A
B1["save_memory_note()\nValida durabilidad\nExige accionabilidad\nRechaza PII y especulación"] -.-> B
C1["Job asíncrono\nMergea session → global\nDeduplicación con LLM\nFiltra notas efímeras"] -.-> C
D1["TrimmingSession: últimas N\nReinyecta notas recortadas\nen system prompt"] -.-> D
style A fill:#2d3748,stroke:#4a9eed,color:#fff
style B fill:#2d3748,stroke:#ed9a4a,color:#fff
style C fill:#2d3748,stroke:#9a4eed,color:#fff
style D fill:#2d3748,stroke:#4aed5c,color:#fff
Fase 1: Injection — el pupitre del examen
Cuando arranca una sesión, el agente monta su contexto inicial. No es aleatorio. Es una estructura concreta:
- YAML frontmatter con el estado del usuario (preferencias, configuración).
- Lista de memorias globales: máximo 6, ordenadas por recencia. ¿Por qué 6? Porque más de 6 compiten entre sí por atención del modelo y empiezan a diluirse. Menos es más.
- Bloque
<memory_policy>con reglas de precedencia explícitas.
Las reglas de precedencia son clave: Input actual > Memoria de sesión > Memoria global > Recencia dentro del mismo scope. Si el usuario te dice «ahora uso Vim» pero tu memoria global dice «usa VS Code», gana lo que acaba de decir. Parece obvio, pero sin reglas explícitas el modelo a veces se aferra a lo que «recuerda» por encima de lo que le estás diciendo.
Fase 2: Distillation — capturar sin contaminar
Durante la conversación, el agente puede capturar memorias en tiempo real con una herramienta tipo save_memory_note(). Pero no todo vale. La herramienta tiene guardrails estrictos:
- Valida durabilidad: «el usuario quiere pizza esta noche» no es una memoria duradera. Se rechaza.
- Exige accionabilidad: la memoria tiene que servir para algo en sesiones futuras.
- Rechaza PII: nombres completos, direcciones, números de tarjeta. Fuera.
- Rechaza especulación: «creo que el usuario prefiere Python» no es un hecho. Es una suposición.
- Requiere confirmación del usuario: antes de guardar, pregunta.
Este filtro es brutal, y con razón. Una memoria contaminada envenena todas las sesiones futuras. Es como si tu cuaderno de campo tuviese una nota falsa: cada vez que lo consultas, tomas decisiones basadas en información incorrecta.
Fase 3: Consolidation — la limpieza nocturna
Después de cada sesión, un job asíncrono recoge las notas de sesión y las fusiona con la memoria global. No es un append. Es una consolidación inteligente:
- Deduplicación asistida por LLM: si dos notas dicen lo mismo con palabras diferentes, se fusionan.
- Filtrado de notas efímeras: cualquier cosa con «this time», «today», «ahora mismo» se descarta.
- Resolución de conflictos por recencia: si una nota nueva contradice una vieja, gana la nueva.
Piensa en esto como la persona que limpia tu escritorio al final del día. No tira todo — guarda lo importante, consolida los post-its que dicen lo mismo, y tira los que ya no aplican.
Fase 4: Trimming — cortar sin perder
Cuando el historial crece demasiado, hay que recortar. TrimmingSession conserva solo las últimas N intervenciones. Pero — ojo al dato — las notas de memoria que vivían en los turnos recortados no se pierden. Se reinyectan en el system prompt del siguiente turno.
Es como arrancar las hojas viejas de un cuaderno pero copiar las notas importantes a la primera página antes de tirarlas.
Trimming vs Summarization: dos filosofías, un dilema
Para gestionar la memoria a corto plazo (el historial de conversación dentro de una sesión), hay dos técnicas fundamentales. Cada una con ventajas y trampas.
flowchart LR
subgraph Trimming["Trimming (Last-N Turns)"]
direction TB
T1["Historial completo\n(40 turnos)"]
T2["Cortar turnos 1-30"]
T3["Conservar turnos 31-40\n(intactos, sin alterar)"]
T1 --> T2 --> T3
end
subgraph Summarization["Summarization (Compression)"]
direction TB
S1["Historial completo\n(40 turnos)"]
S2["LLM resume turnos 1-30\nen ~400 tokens"]
S3["Inyectar resumen sintético\n+ turnos 31-40"]
S1 --> S2 --> S3
end
style Trimming fill:#1a2332,stroke:#4a9eed,color:#fff
style Summarization fill:#2a1a32,stroke:#9a4eed,color:#fff
Trimming: la guillotina determinística
Escanea el historial hacia atrás, conserva las últimas N intervenciones completas, y todo lo anterior desaparece.
Ventaja: fidelidad total del contexto reciente. Lo que queda no ha sido alterado, resumido ni interpretado. Son los mensajes originales, tal cual.
Desventaja: amnesia abrupta. El turno N-1 existe con todo detalle. El turno N-2 no existe en absoluto. No hay degradación gradual — hay un corte binario entre «recuerdo todo» y «no recuerdo nada».
Es como la memoria de un goldfish con un disco duro externo: los últimos 10 segundos los tiene perfectos, todo lo anterior simplemente no existe.
Summarization: la compresión con riesgo
Cuando el historial supera un umbral, un LLM comprime lo antiguo y lo inyecta como un par sintético user/assistant al principio de la conversación. El prompt de resumen tiene principios estrictos:
- Preservar milestones (decisiones tomadas, acuerdos).
- Mantener orden temporal.
- Detectar contradicciones y marcarlas.
- Hechos inciertos marcados como «UNVERIFIED».
- Máximo 400 tokens por resumen.
Ventaja: conservas la esencia de toda la conversación. No hay amnesia abrupta. El modelo «sabe» que hace 30 turnos decidisteis usar PostgreSQL en vez de MongoDB, aunque ya no tenga los mensajes originales.
Desventaja: compounding errors. Si un hecho erróneo entra en el resumen, envenena todo el comportamiento futuro. Y como el resumen se genera con un LLM, no es inmune a alucinaciones. Un modelo que resume mal genera un resumen incorrecto que el siguiente turno trata como verdad absoluta.
Tiene morro que te pisas: usas un LLM para resumir el historial de otro LLM, y si el primero se equivoca, el segundo hereda el error sin saberlo.
Para distinguir lo real de lo sintético, cada registro lleva metadata de observabilidad: {"synthetic": bool, "kind": "...", "summary_for_turns": "..."}. Así al menos puedes auditar qué parte del contexto es original y qué parte es un resumen.
Esto ya lo estás haciendo (y no lo sabías)
Si usas Claude Code, ya tienes un sistema de context engineering funcionando. Solo que no lo diseñaste tú — lo diseñó Anthropic. Pero si te paras a mirar, las piezas encajan:
Tu CLAUDE.md global + CLAUDE.md por proyecto + archivos SKILL.md = injection manual. Estás decidiendo qué contexto ve el modelo al arrancar cada sesión. Eres tú quien elige qué «libros van al pupitre».
El directorio ~/.claude/projects/*/memory/ donde Claude Code guarda notas entre sesiones = implementación directa del patrón injection + distillation. El modelo captura hechos durante la sesión y los recupera en la siguiente.
La compresión automática de contexto que Claude Code hace cuando la conversación se alarga = trimming + summarization. No lo ves porque es transparente, pero cada vez que tu sesión supera cierto umbral, parte de la conversación se comprime.
Los skills (/blog, /commit, etc.) = inyección de contexto especializado bajo demanda. En vez de cargar todo el contexto posible al principio, cargas solo el que necesitas cuando lo necesitas.
Y aquí viene lo que me parece más interesante: la calidad de tus CLAUDE.md determina la calidad de tu agente mucho más que el modelo que uses. Un CLAUDE.md bien estructurado — con convenciones claras, paths correctos, decisiones de arquitectura documentadas — convierte a cualquier modelo decente en un asistente útil. Un CLAUDE.md vacío o desordenado convierte al mejor modelo del mundo en un consultor brillante encerrado en una habitación sin luz.
Prompt debt: la deuda técnica que no ves
¿Conoces el concepto de technical debt? Código que funciona pero que acumula problemas futuros. Atajos que pagas después.
Context engineering tiene su propia deuda: prompt debt. Son todos esos ficheros de configuración, instrucciones, memorias y notas que se acumulan y que nadie mantiene.
Un CLAUDE.md con instrucciones contradictorias. Memorias globales que ya no aplican. Skills con paths que cambiaron hace tres meses. Reglas de precedencia implícitas que nadie documentó.
Cada pieza de contexto obsoleto es ruido. Y el ruido compite con la señal por la atención del modelo. Más ruido → peores resultados. No porque el modelo sea peor, sino porque le estás dando basura mezclada con información útil y esperando que sepa distinguirlas.
La higiene de tu capa de context engineering es tan importante como la higiene de tu código. Quizás más, porque un bug en el código falla ruidosamente. Un bug en el contexto falla silenciosamente — el modelo simplemente toma decisiones peores sin que nadie se dé cuenta.
Lo accionable: qué puedes hacer hoy
Toda esta teoría está muy bien, pero ¿qué haces con ella un martes por la mañana?
1. Audita tu CLAUDE.md (o equivalente). ¿Tiene instrucciones contradictorias? ¿Paths que ya no existen? ¿Reglas que ya no aplican? Limpia. Cada línea que sobra es ruido.
2. Ordena tu contexto por estabilidad. Lo que nunca cambia va primero (convenciones, stack). Lo que cambia a menudo va al final (tarea actual). Esto maximiza cache hits y reduce costes. No es cosmético — es económico.
3. Establece reglas de precedencia explícitas. Si el usuario dice una cosa y la memoria dice otra, ¿quién gana? Si no lo defines, el modelo decide por ti. Y te la juegas.
4. Filtra agresivamente. No todo merece ser recordado. Una decisión de arquitectura, sí. Que el usuario prefiere tabs sobre spaces, quizás. Que hoy llovía cuando empezó la sesión, no.
5. Distingue contexto real de sintético. Si usas summarization, marca los resúmenes como tales. Cuando algo falle, necesitas saber si el modelo estaba trabajando con datos reales o con un resumen potencialmente incorrecto.
6. Trata el mantenimiento del contexto como deuda técnica. Ponlo en el backlog. Revísalo periódicamente. No es glamuroso, pero es lo que separa a un agente que curra de uno que alucina.
El skill que nadie pone en el CV
Context engineering es el skill invisible. No sale en las ofertas de trabajo. No tiene certificación. No hay un curso de 40 horas en Udemy con un diploma al final.
Pero es lo que separa a la gente que «usa ChatGPT» de la gente que construye agentes que funcionan. Es la diferencia entre preguntarle algo a un LLM y diseñar un sistema donde el LLM tiene todo lo que necesita para darte la respuesta correcta.
La próxima vez que tu agente haga algo estúpido, antes de culpar al modelo, mira qué contexto le estabas dando. Hay muchas probabilidades de que el problema no sea el cerebro — sea lo que el cerebro estaba viendo.
Y eso, a diferencia del modelo, sí lo controlas tú.
Fuentes: Los dos artículos de OpenAI Cookbook sobre Context Engineering for Long-Term Personalization y Short-Term Memory Management with Sessions. Si te interesa cómo funciona el bucle interno de un coding agent, lee Tu AI coding agent es un while loop con delirios de grandeza. Y si quieres entender por qué el orden del prompt afecta al coste, Por qué el 99% de lo que envías a Claude ya lo tiene en caché.
Read this article in English.
