Context engineering: la disciplina central para construir agentes de IA

En 2024 todo el mundo hablaba de prompt engineering. En 2026, los equipos serios que construyen agentes hablan de context engineering. No es marketing: es un cambio real de disciplina, porque los agentes funcionan radicalmente distinto a los chatbots.

Anthropic publicó en septiembre de 2025 un paper de referencia titulado Effective context engineering for AI agents donde formalizan la práctica. Este artículo lo desgrana en castellano sin perder rigor. Forma parte de la guía de agentes de IA.

Definición

Context engineering es la disciplina de gestionar qué información llega al modelo en cada paso de su ejecución, de forma que el modelo tenga lo que necesita y nada más.

Tres palabras clave:

• Gestionar — no es un prompt único, es un sistema vivo.

• Cada paso — los agentes ejecutan muchos turnos; cada turno es una decisión.

• Lo que necesita y nada más — exceso de contexto degrada tanto como déficit.

Por qué prompt engineering no basta para agentes

Un prompt engineer optimiza un prompt único: "tú eres X, haz Y, devuelve Z". Funciona perfecto para chatbots, donde una entrada produce una salida.

En un agente, el flujo es:

Turno 1: prompt → tool call
Turno 2: resultado de tool → prompt + nuevo contexto → otro tool call
Turno 3: resultado nuevo → prompt + 2 contextos → decisión
...
Turno 30: prompt + 30 contextos → output final

A medida que el agente itera, el contexto crece. Con 30 turnos, el contexto puede pasar de 5.000 a 200.000 tokens. Y aquí ocurren tres problemas que el prompt engineering no resuelve:

1. Context rot: el modelo "olvida" partes intermedias, prioriza inicio y final del contexto.

2. Coste explosivo: cada turno paga por el contexto acumulado de los anteriores.

3. Pérdida de foco: información irrelevante de turnos previos contamina decisiones nuevas.

Context engineering es la disciplina que ataca estos tres problemas a la vez.

Los cuatro pilares del context engineering

1. Selección: qué entra al contexto

No metas en contexto todo lo que tengas. Selecciona en cada turno solo lo necesario.

Ejemplo malo: agente de soporte que en cada turno carga el catálogo entero de productos (50.000 tokens).

Ejemplo bueno: agente que primero clasifica la consulta, y solo carga la sección del catálogo relevante (2.000 tokens).

Técnicas concretas:

• RAG dirigido por intent — busca embeddings solo de la categoría detectada.

• Tools de "fetch on demand" — el LLM pide info cuando la necesita, no por defecto.

• Resúmenes precomputados — en vez del documento entero, un resumen de 200 tokens.

2. Compresión: cómo cabe lo que necesitas

Cuando hay demasiado, comprime. Hay tres niveles:

Compresión literal: reformular para usar menos palabras. "El usuario, que es cliente premium desde 2023 y tiene un plan anual" → "Cliente premium 2023, plan anual".

Resumen de turnos previos: cada N turnos, sustituye los últimos por un resumen. "En los 5 turnos anteriores, el agente investigó X, descartó Y, y decidió enfocar en Z".

Compactación visual: usa tablas, listas, JSON compacto en vez de prosa.

3. Persistencia: qué guarda y dónde

No todo necesita estar en el contexto activo del LLM. Algunas cosas deben vivir fuera y traerse cuando hagan falta.

Capas típicas:

• Working memory (en contexto): los últimos turnos, el plan actual.

• Scratchpad (archivo o variable): notas que el agente toma para sí mismo.

• Memoria de sesión (DB): info que persiste durante una ejecución larga.

• Memoria de largo plazo (vector DB o KV store): info que persiste entre ejecuciones.

Anthropic introdujo la memory tool en agosto 2025 precisamente para esto. La memoria deja de ser un prompt y pasa a ser una herramienta.

4. Orquestación: quién maneja qué

Cuando un agente se vuelve complejo, particiona el trabajo. En vez de un agente con contexto gigante, varios subagentes con contextos especializados.

Patrón multi-agente:

• Agente coordinador (contexto: plan general, ~5K tokens).

• Subagente de investigación (contexto: tools de búsqueda + tema, ~20K tokens).

• Subagente de análisis (contexto: datos del subagente investigador, ~30K tokens).

• Subagente de redacción (contexto: análisis + estilo, ~10K tokens).

Cada subagente trabaja en su silo, devuelve resultado destilado al coordinador. Ver el patrón completo de subagentes.

Técnicas concretas que cambian resultados

Just-in-time loading

En vez de meter toda la documentación en el system prompt, expón un tool read_docs(section) y deja que el LLM la pida cuando la necesite. Beneficio típico: -70% en tokens del system prompt.

Tool result trimming

Cuando una tool devuelve 10.000 tokens (ej: búsqueda web), no metas los 10.000. Procesa el resultado, extrae lo relevante, devuelve 1.000 al contexto del agente.

Sliding window con anclas

Para conversaciones largas:

• Mantén siempre los primeros N tokens (system prompt + objetivo).

• Mantén siempre los últimos M tokens (turnos recientes).

• Comprime o descarta lo de en medio.

Structured output como interfaz

En vez de devolver prosa que ocupará espacio en futuros turnos, fuerza al LLM a devolver JSON estructurado. Comprime mejor y es más útil.

Cacheo agresivo

Anthropic ofrece prompt caching con descuento del 90% en cache hits. Toda parte del contexto que no cambie entre turnos (system prompt, tools schema, docs) debería ir en caché. Reduce factura agente medio entre 50% y 80%.

Errores comunes

"Más contexto = mejor respuesta"

Falso. Pasados ~50K tokens, la calidad empieza a degradarse. Estudios de "needle in a haystack" muestran que los modelos pierden información de la parte media del contexto. Mejor 20K bien curados que 200K mezclando relevante con ruido.

Cargar todo el historial conversacional

Si el agente lleva 50 turnos, no metas los 50 íntegros. Resume turnos 1-40 a 500 tokens y mantén turnos 41-50 enteros.

No diferenciar instrucciones de datos

Mezclar el system prompt con resultados de tools en un solo bloque confunde al modelo. Usa roles claros (system, user, tool) y delimitadores (<context>, <task>, <output>).

Ignorar el coste del context window

Cada turno multiplica. Si el contexto crece de 5K a 100K en un agente de 20 turnos:

• Turno 1: paga por 5K.

• Turno 20: paga por 100K.

• Total: pagas el equivalente a ~1M tokens si nunca compactas.

Con enrutamiento inteligente y caching puedes reducir esto un 60-90%.

Cómo se ve en código

Ejemplo simplificado con Claude Agent SDK:

from claude_agent_sdk import Agent, Tool

# Pilar 1: selección — el LLM pide info cuando la necesita
@Tool
def fetch_product(product_id: str) -> str:
    return db.get_product(product_id).summary()  # 200 tokens, no 5.000

# Pilar 3: persistencia — scratchpad para notas propias
@Tool
def save_note(note: str) -> str:
    scratchpad.append(note)
    return "saved"

# Pilar 2: compresión — resumir si el contexto crece
agent = Agent(
    model="claude-opus-4-7",
    tools=[fetch_product, save_note],
    system_prompt="...",
    auto_compact_threshold=50_000  # comprime cuando llegue a 50K
)

result = await agent.run("Analiza pedidos del Q1 y detecta anomalías")

El detalle: el agente no recibe los pedidos en el prompt. Los pide cuando los necesita, los resume, anota en scratchpad, y comprime cuando el contexto crece.

Context engineering vs prompt engineering

No es que prompt engineering esté muerto. Es que dentro del context engineering sigue existiendo — pero como un componente, no como toda la disciplina.

Cuándo invertir en context engineering

Si construyes:

• Un chatbot simple (1 turno) → prompt engineering basta.

• Un asistente con 2-3 turnos → prompt engineering + algo de control de contexto.

• Un agente real (5+ turnos, tools) → context engineering es la disciplina central.

A partir de un agente de 10 turnos o que toque APIs externas, ignorar context engineering te lleva a sistemas lentos, caros y poco fiables. Antes de echarle más GPU o cambiar de modelo, audita el contexto.

Conclusión

Context engineering es a los agentes lo que arquitectura de software es a una aplicación: lo que diferencia un sistema mantenible y barato de uno caótico y caro. En 2026 los equipos que construyen agentes serios — Anthropic, OpenAI, Cursor, Claude Code — tratan el contexto como un recurso escaso que hay que gestionar deliberadamente.

Para profundizar:

• Agentes de IA en 2026: guía completa — pillar del cluster.

• Cómo crear un agente con Claude desde cero — práctica.

• Subagentes de Claude Code — patrón multi-agente.

• Cómo Claude Code gestiona el loop — context engineering en producción.

Fuentes verificadas

• Effective context engineering for AI agents — paper de referencia, Anthropic, septiembre 2025.

• Memory and context management — docs oficiales Anthropic.

• Prompt caching — docs oficiales con benchmarks de coste.

• Datos verificados el 27 de abril de 2026.