Context engineering

El arte y la ciencia de curar estratégicamente la información que entra en la ventana de contexto del LLM — garantizando que reciba solo los datos necesarios para el paso actual. Aborda directamente los modos de fallo de “todo al prompt” (alucinación, latencia, costo, lost in the middle). Posicionada como más amplia y más importante que la “prompt engineering” en aplicaciones reales — especialmente en agentes.

Definición técnica

Dos fases obligatorias (yc-root-access-ai-y-agentes Q7):

1. Reunir (recall): maximizar la recuperación de todos los tokens posiblemente relevantes para la tarea.
2. Espigar/depurar (precisión): maximizar la precisión, eliminar lo irrelevante, dejar solo el conjunto más limpio.

Un prompt en aplicaciones reales = instrucciones + contexto. La ingeniería de prompts trata solo la primera mitad.

Por qué importa más que prompt engineering

Cuatro argumentos densos (yc-root-access-ai-y-agentes Q7):

1. Los LLMs son funciones puras: en inferencia, modulo temperatura/finetuning, la única variable que mejora calidad es lo que entra. Optimizar el prompt sin optimizar el contexto es atacar la variable equivocada.
2. Recall basura → modelo basura: muchos devs creen tener problema de prompting cuando tienen problema de retrieval/curación.
3. Degradación en contexto largo: las ventanas de millones de tokens no rescatan al modelo — evals muestran que el razonamiento cae precipitadamente con longitud.
4. Agentes son especialmente vulnerables: operan en loops largos, respuestas de herramientas inyectan JSON denso, sub-agentes acumulan historia. Sin compactación intencional, el agente se ahoga.

Jerarquía de fallos en un agente (yc-root-access-ai-y-agentes):

1. Información errónea
2. Información faltante
3. Exceso de ruido

Ninguna se resuelve con mejor prompting.

Context rot y la “dumb zone”

Context rot — degradación rápida del rendimiento del agente conforme la ventana de contexto crece, aunque los modelos modernos tengan ventanas de 1M+ tokens.

Síntoma	Mecanismo
Lost in the middle	Modelo presta menos atención al material central de un context window grande
Dumb zone	Al ~40-50% de capacidad del context, el modelo pierde capacidad de razonamiento — entra en estado “torpe”
Costo y latencia lineales	Tokens × precio × por llamada — saturar contexto sale económicamente caro
Más alucinaciones	Información ruidosa o fragmentada inflada en el contexto incrementa fabricación

Cinco palancas operativas

Fuente principal: ai-engineer-rag-context-agregada.

1. Sub-agentes para aislar contexto (delegation)

No para antropomorfizar roles, sino fundamentalmente para controlar contexto.

• El sub-agente recibe ventana en blanco, ejecuta su tarea (leer doc extensa, buscar en código), y devuelve solo el resumen/respuesta sintetizada al agente principal.
• El contexto principal se mantiene limpio y enfocado.
• Conecta con agent-memory (handoff packet estructurado).

2. Progressive disclosure de herramientas

• No inyectar descripciones completas de cientos de APIs en el system prompt — abruma al modelo y agota tokens.
• Exponer descripciones de una línea + herramienta de búsqueda de skills.
• El agente carga detalles técnicos solo cuando decide que los necesita.
• Patrón equivalente a mcp-protocol como capa de descubrimiento dinámico.

3. Compactación intencional / smart truncation

• No permitir que el historial se acumule infinitamente.
• Truncamiento inteligente: mantener instrucciones iniciales (cabeza) + interacciones más recientes (cola), guardar/resumir el medio en memoria externa.
• Variante operativa: pedir al agente que comprima su progreso en un documento markdown actualizado antes de avanzar (ej. plan vivo).

4. Reiniciar sesiones ante trayectorias negativas

Si el agente toma un camino equivocado y pasas turnos corrigiéndolo, estás envenenando su contexto.

• El modelo aprende estadísticamente que equivocarse es parte del flujo → tiende a volver a cometer errores.
• Mejor: pedir resumen del estado actual → limpiar contexto → empezar sesión nueva con el plan corregido.
• Es la práctica equivalente a “borrar el chat y reabrir” en herramientas tipo Claude/Cursor cuando el agente se desvía.

5. Externalizar memoria

• Evitar RAG estático y ciego inyectando datos directamente al prompt.
• Escribir decisiones de arquitectura, especificaciones y reglas en archivos externos (agent.md, claude.md, agents.md) o BDs vectoriales/grafos.
• Equipar al agente con herramienta de “memoria” que le permita guardar y recuperar proactivamente docs específicos en el contexto exacto en que son útiles.

Tensión con context window infinito (cross-link)

Los context windows de 1M+ tokens parecen deprecar context engineering — pero no:

1. Episodic memory entre sesiones sigue requiriendo store externo.
2. Costo por token escala linealmente — económicamente inviable a escala.
3. Lost in the middle documentado independientemente.

La memoria externa no es workaround del context window — es arquitectura más eficiente que el “todo en prompt”. Misma tesis que agent-memory.

Conexiones

• agentic-ai — context engineering es la disciplina que mantiene a los agentes funcionando. Sin ella, los agentes fallan cuando la tarea se vuelve compleja.
• agent-memory — context engineering es la disciplina de decidir qué entra al working memory en cada paso; agent memory es el almacén persistente que alimenta esa decisión.
• agentic-patterns — todos los patrones (Sub-agents, Plan-and-Execute, Hierarchical) son decisiones de context engineering disfrazadas de arquitectura.
• vibe-coding — la “Zona Torpe” / Dumb Zone es exactamente el mismo concept que hace fallar agentes de coding cuando el contexto se contamina con trayectorias largas. En Cursor/Aider/Cline, lo que diferencia un buen prompt de un mal prompt es qué archivos pasaste como contexto, no la redacción.
• comprehension-debt — el agente que externaliza memoria a claude.md no exime al humano de hold la arquitectura — la asimetría persiste.
• graphrag — un subgrafo bien recortado es una forma específica de context engineering aplicada a RAG estructurado.
• grandma-exploit — los exploits clásicos atacan vía prompt injection. Defensas a nivel de retrieval/contexto (qué se permite entrar) son complementarias a defensas de prompt (cómo se redacta).
• prompts-agents-curados — el playbook del usuario para Cursor/Aider implícitamente hace context engineering al definir reglas de qué archivos cargar.

Posición en el wiki

• Concept triangulado: dos batches independientes (YC Root Access + AI Engineer Conference 2025) convergieron sobre el mismo concepto en la misma fecha (mayo 2026).
• Refuerza topics agentes-ia-arquitectura y ia-y-desarrollo.

Fuentes

• ai-engineer-rag-context-agregada — fuente principal de las 5 palancas operativas (13 charlas).
• ai-engineer-agentes-mcp-evals-agregada — cross-link con sub-agents pattern.
• yc-root-access-ai-y-agentes — definición técnica + 4 razones por las que importa más que prompt engineering (Q7).
• Charlas referenciadas dentro del notebook YC (no ingeridas individualmente):
  • Context Engineering: Lessons Learned from Scaling CoCounsel
  • Advanced Context Engineering for Agents
  • Context Engineering for Engineers

Preguntas abiertas

• ¿Existe métrica formal de “context efficiency” (info útil / tokens consumidos) que se pueda automatizar como gate en CI/CD?
• ¿Cuándo el costo de gestionar memoria externa supera el costo de pasar más contexto crudo? Sigue siendo empírico, no hay regla.
• ¿Cómo se mide cuándo el modelo entra en la dumb zone? La “regla 40-50%” es heurística — falta benchmark formal.
• Para vibe-coding solitario (Cursor/Aider): ¿es overkill o el mismo principio aplica? Probablemente aplica — los días en que Cursor “se vuelve tonto” suelen ser por contexto inflado, no por mal prompt.