El prompt perfecto ya no basta: esto es context engineering

La primera vez que un agente mío empezó a portarse peor, hice lo que haría cualquiera: le agregué más instrucciones al prompt. Más reglas, más ejemplos, más "y acuérdate de esto". Y empeoró.

Me tomó un tiempo entender por qué. No era el prompt. Era todo lo demás que le estaba metiendo al modelo sin darme cuenta. Anthropic le puso nombre a eso en un paper buenísimo, y cambió cómo construyo agentes. Te lo cuento.

El cambio que casi nadie nota

Cuando usas ChatGPT para una pregunta suelta, tu trabajo es prompt engineering: escribir bien esa instrucción. Un turno, una respuesta.

Pero un agente no es un turno. Es un bucle: piensa, llama una herramienta, observa el resultado, vuelve a pensar… decenas de veces. Y en cada vuelta, alguien decide qué información se le pasa al modelo: el system prompt, las herramientas, documentos, memoria, el historial, los resultados de cada tool.

Prompt engineering es escribir una instrucción. Context engineering es curar todo lo que entra a la ventana de contexto, en cada paso.

Esa es la definición de Anthropic: el conjunto de estrategias para curar y mantener el conjunto óptimo de tokens durante la inferencia. Y ojo con la palabra clave: curar. No es escribir más. Es elegir mejor.

Anthropic lo resume en un diagrama que vale la pena mirar de cerca:

Míralo con calma, porque ahí está todo. A la derecha hay un pool enorme de contexto posible —docs, herramientas, memoria, historial, instrucciones— y en cada paso solo un subconjunto, tras la curación, entra a la ventana. Ese filtro, no el prompt, es el trabajo. El salto no es de grado: es pasar de redactar un texto a gestionar un sistema de información.

La idea que lo cambia todo: el contexto es finito

Aquí está el "aha". Solemos pensar que la ventana de contexto es una bolsa: mientras más grande, mejor, mete todo. Falso.

Los modelos sufren lo que Anthropic llama context rot: mientras más tokens metes, peor recuerda el modelo lo que hay dentro. No es un capricho; es la arquitectura. Un Transformer hace que cada token "mire" a todos los demás — con muchos tokens, esa atención se estira demasiado.

La analogía que a mí me funcionó: el modelo tiene un attention budget, como tu memoria de trabajo. Es un escritorio. Si apilas cada papel "por si acaso", no es que tengas más orden: es que ya no encuentras nada.

El contexto es un recurso finito con retornos decrecientes. Cada token que agregas "de más" te cuesta atención sobre lo que sí importa.

Por eso el agente empeoraba cuando yo le echaba más. Le estaba llenando el escritorio.

Cuatro formas de curar bien el contexto

Anthropic aterriza esto en principios concretos. Estos son los cuatro que más me sirvieron.

1. System prompt: la "altitud" correcta. Ni un guion rígido lleno de if/else (frágil, se rompe), ni instrucciones vagas de alto nivel (no guían nada). El punto medio: específico para dirigir el comportamiento, pero flexible para dejar heurísticas fuertes. Organízalo en secciones claras (## Instrucciones, ## Herramientas) y busca el conjunto mínimo que describa por completo lo que esperas (mínimo ≠ corto).

2. Herramientas mínimas y sin solaparse. Si tú, como ingeniero, no sabrías con certeza cuál tool usar, el agente tampoco. Un catálogo inflado de herramientas ambiguas es una de las fallas más comunes. Pocas, claras, que devuelvan resultados token-eficientes.

3. Ejemplos curados, no una lista de casos extremos. Un buen ejemplo vale mil reglas. Pero no metas 30 casos borde intentando cubrir todo: elige unos pocos ejemplos canónicos y diversos que muestren el comportamiento esperado.

4. Contexto just-in-time, no todo por adelantado. Este es el más potente. En vez de precargar todos los documentos, le das al agente referencias ligeras (rutas de archivo, queries, links) y herramientas para traer lo que necesite en el momento. Igual que tú: no te memorizas la biblioteca entera, usas el índice y vas por el libro cuando lo necesitas. Claude Code hace justo esto — lee un CLAUDE.md base y usa grep/glob para explorar el resto bajo demanda.

Cuando la tarea es larga (horas, no minutos)

¿Y si la tarea es tan larga que el historial ya no cabe en la ventana? Tres técnicas, y elegir depende del caso:

• Compaction (compactar): cuando te acercas al límite, resumes la conversación y arrancas una ventana nueva con ese resumen. Preservas decisiones y detalles críticos, y tiras lo redundante (los resultados viejos de tools son lo primero que se puede limpiar). Ideal para tareas conversacionales largas.
• Structured note-taking (memoria agéntica): el agente escribe notas fuera de la ventana (un NOTES.md, un to-do list) y las vuelve a leer cuando las necesita. Claude jugando Pokémon mantenía así el conteo a través de miles de pasos. Ideal para trabajo iterativo con hitos.
• Sub-agentes: en vez de un agente cargando todo el proyecto, subagentes con ventanas limpias hacen el trabajo profundo y devuelven solo un resumen destilado (1.000–2.000 tokens). El agente líder sintetiza. Ideal para investigación y análisis complejos.

La regla de oro que resume todo el paper: encuentra el conjunto más pequeño de tokens de alta señal que maximice la probabilidad del resultado que buscas.

Esto ya lo vivimos en data (y por eso es mi juego)

Cuando leí el paper, me sonó a casa. Llevo años en el mundo de la data —volumetría, calidad, orquestación— y context engineering es, básicamente, esas mismas disciplinas apuntadas a la ventana de contexto del modelo. Mira los paralelos:

• Volumetría. En data aprendes rápido que no escaneas la tabla entera "por si acaso": filtras temprano y proyectas solo las columnas que necesitas. El attention budget es idéntico — no le des al modelo toda la tabla, dale la fila que importa.
• Calidad de datos. Garbage in, garbage out. Años cuidando calidad y gobierno (DAMA) me enseñaron que el problema casi nunca es "falta data": es "sobra ruido". Los high-signal tokens de Anthropic son, literalmente, calidad de datos aplicada al contexto.
• El momento exacto. En un pipeline decides cuándo se mueve cada dato: batch, streaming, on-demand. El contexto just-in-time es exactamente eso — traer el dato en el instante justo, no antes ni de más. Es orquestación, no acumulación.

Fíjate en el giro que viene: los modelos son cada vez más inteligentes, así que necesitan menos ingeniería prescriptiva. El trabajo no desaparece — se mueve. Deja de ser "escribir el prompt perfecto" y pasa a ser gobernar la capa de contexto: qué datos entran, cuándo, desde dónde, con qué calidad y qué gobierno.

Y ahí es donde quien viene de data tiene una ventaja injusta. Esto no es un truco de prompting: es gobierno de datos —volumetría, calidad, latencia, linaje— apuntado a la atención del modelo. Es, palabra por palabra, lo que hago como Data & AI Manager, pero para agentes. La capa de contexto de un agente necesita un dueño, y ese perfil no sale de saber prompts: sale de saber datos.

Si estás construyendo con LLMs, cambia la pregunta: de "¿cómo escribo mejor el prompt?" a "¿qué es lo mínimo de alta señal que este paso necesita ver?". Ese cambio lo cambia todo.

Sigue la serie: "cómo se arma un agente, sin humo"

• Function calling — cómo el modelo pide herramientas (el "actuar" del agente). (publicado)
• ReAct — el bucle pensar → actuar → observar. (próximo)
• Memoria de agentes — corto plazo, largo plazo y el NOTES.md. (próximo)
• RAG — recuperación just-in-time de conocimiento. (próximo)

Referencias

• Anthropic — Effective context engineering for AI agents
• Anthropic — Building effective agents
• Anthropic — How we built our multi-agent research system