Teníamos un agente de compras con acceso a un manual de proveedores de 200 páginas, 45 contratos vigentes y la solicitud de compra actual. Le pedí que evaluara al proveedor más barato. Me respondió con datos de un contrato que había vencido hace dos años.

El modelo no era malo. El contexto sí.

En el post anterior mostré los datos: los modelos pierden precisión a medida que crece el contexto. Todos — sin excepción. Este post es el complemento práctico: ya sabemos que la ventana es limitada, ahora la pregunta es qué meter en ella.

El contexto es un presupuesto, no un almacén

Cada token que entra a la ventana de contexto compite por la atención del modelo. Anthropic lo describe como buscar “el conjunto más pequeño de tokens de alta señal”. No se trata de meter todo lo que podría ser relevante. Se trata de meter solo lo que es relevante para esta llamada específica.

Y acá está la distinción que importa: ingeniería de prompts es cómo preguntas. Ingeniería de contexto es qué información está presente cuando el modelo procesa tu pregunta.

El presupuesto se reparte entre cuatro componentes:

• System prompt — las instrucciones y personalidad del agente
• Definiciones de herramientas — qué puede hacer y cómo
• Datos recuperados — documentos, registros, resultados de búsqueda
• Historial de conversación — todo lo dicho antes en la sesión

La mayoría de despliegues que reviso en clientes tienen el mismo problema: sobreinvierten en uno de estos componentes y dejan los demás desnutridos. Un system prompt de 4,000 tokens que no deja espacio para los datos que el agente realmente necesita. O herramientas duplicadas que consumen tokens sin agregar capacidad.

Anatomía de un contexto que funciona

System prompts: la altitud correcta

Un system prompt efectivo define el rol del agente y sus restricciones, además del formato de salida esperado. Usa secciones claras (XML o markdown) para que el modelo pueda encontrar lo que necesita. E incluye exclusiones explícitas — qué no debe hacer el agente es tan importante como qué sí.

El error más común: escribir un manual de operaciones dentro del system prompt. A partir de ~1,500 tokens, el rendimiento del system prompt se vuelve decreciente. Cada instrucción adicional compite con las anteriores por la atención del modelo.

Herramientas: cada definición cuesta

Cada herramienta que defines consume tokens con su nombre y descripción, más el esquema completo de parámetros. Si tienes herramientas que se solapan (buscar_cliente y consultar_cliente que hacen casi lo mismo), estás pagando doble por la misma capacidad, y además confundes al modelo sobre cuál usar.

Las definiciones deben ser autocontenidas. Si un modelo necesita leer el system prompt para entender cómo usar una herramienta, la definición está incompleta. Si tus herramientas exponen APIs, el diseño de las definiciones se conecta directamente con tu estrategia de APIs para integración con IA.

Datos recuperados: la sección con más desperdicio

Acá es donde se pierde la mayoría del presupuesto. Un agente que necesita dos párrafos de un contrato recibe las 50 páginas completas. Un agente de soporte que necesita un artículo de la base de conocimiento recibe diez “por si acaso”.

La diferencia en la práctica:

	Contexto ingenuo	Contexto diseñado
Agente de compras	Manual completo (200 págs) + todos los contratos + solicitud = ~180K tokens	Sección relevante del manual + contrato del proveedor específico + solicitud = ~8K tokens
Precisión	~68%	~89%
Costo por llamada	~$1.80	~$0.08

Mismo modelo. Misma tarea. Los tokens que eliminamos eran ruido que diluía la atención.

Cargar bajo demanda, no por adelantado

El patrón más efectivo que usamos en IQ Source es la carga progresiva. En vez de darle al agente toda la información al inicio, le das identificadores livianos y la capacidad de pedir datos cuando los necesita.

Un ejemplo real: un agente de escalación de soporte técnico. La versión original cargaba el ticket completo, el historial del cliente, los términos del contrato y la base de conocimiento. Todo al inicio, sin saber si lo necesitaría.

La versión rediseñada arranca solo con los metadatos del ticket: ID del cliente, categoría del problema, nivel de prioridad. El agente analiza y decide: ¿Necesito ver el contrato? Lo pide a través de una herramienta. ¿Necesito el historial? Lo solicita. Los datos llegan justo cuando hacen falta.

El resultado en un proyecto de revisión de documentos: tokens activos bajaron de ~45K a ~12K. La precisión subió de ~72% a ~91%. No cambiamos el modelo. Cambiamos cuándo y qué información recibía.

Tres técnicas para agentes que trabajan horas

Cuando un agente necesita operar durante horas — procesando un pipeline de aprobaciones, revisando documentación regulatoria, monitorizando un despliegue — la ventana se llena inevitablemente. Estas técnicas lo resuelven:

Compactación automática

El modelo autorresume las partes más antiguas de la conversación. En el post sobre ventanas de contexto cubrí esto en detalle: Claude Opus 4.6 reduce ~58% del uso de tokens automáticamente.

Pero hay una trampa: la compactación pierde detalle. Si tu proceso es regulado y necesitas la trazabilidad exacta de cada paso, guarda los originales en un sistema externo antes de que se compacten.

Scratchpads estructurados

El agente escribe sus hallazgos en un archivo o base de datos externa a medida que trabaja. Cuando el contexto se recorta, los hallazgos persisten. El agente lee sus propias notas de vuelta cuando las necesita.

Es como un investigador que toma notas en un cuaderno: si pierde la memoria de corto plazo, sus notas le dicen qué ya encontró y qué le falta.

Arquitectura de subagentes

Un agente padre orquesta. Los subagentes arrancan con ventanas limpias, procesan tareas específicas y devuelven resúmenes condensados (~1-2K tokens cada uno). Donde un solo agente con toda la información podría procesar decenas de miles de tokens con precisión decreciente, cada subagente trabaja con exactamente lo que necesita.

Si quieres profundizar en la orquestación de agentes en operaciones empresariales, lo cubrimos en detalle en ese post.

Lo que vemos mal en la mayoría de despliegues

Después de revisar decenas de implementaciones de agentes en clientes, estos son los tres antipatrones que aparecen una y otra vez:

System prompt tipo enciclopedia. 4,000+ tokens cubriendo cada excepción posible. El modelo no ignora esas instrucciones — compiten activamente con las instrucciones importantes. Pasados los ~1,500 tokens, cada regla adicional diluye las anteriores. La solución: mueve las excepciones a herramientas que el agente llame solo cuando las necesite.

Información duplicada entre capas. La descripción de una herramienta repite lo que dice el system prompt, que a su vez repite lo que ya está en los datos recuperados. En una auditoría reciente encontramos ~25% de redundancia en los tokens de un agente de atención al cliente. Eliminamos duplicados y la precisión subió sin cambiar nada más.

Contexto estático para tareas dinámicas. El agente siempre recibe los mismos 15K tokens de políticas de la empresa, sin importar si está clasificando un ticket de soporte o redactando una propuesta comercial. El contexto debería adaptarse al tipo de tarea — un clasificador necesita ejemplos, un generador necesita restricciones, una búsqueda necesita datos.

Checklist antes de desplegar tu próximo agente

Antes de poner un agente en producción, haz este ejercicio:

Presupuesta tu contexto. Calcula cuántos tokens tienes disponibles después del system prompt y las herramientas. Si tu modelo tiene 200K tokens y entre prompt y herramientas ya consumes 8K, tu presupuesto real para datos y conversación es 192K — pero la precisión real se degrada mucho antes de ese límite.

Audita redundancia. Lee cada token que recibe tu agente. Literalmente. Resalta lo que aparece más de una vez. Si la misma información está en el system prompt y en la descripción de una herramienta, sobra en uno de los dos.

Prueba con ablación de contexto. Elimina fragmentos del contexto y mide si la precisión cambia. Si puedes quitar un bloque de 3K tokens y la precisión no baja, esos tokens eran ruido. Eran costo sin valor.

Diseña la recuperación según el tipo de tarea. No todas las llamadas del agente necesitan los mismos datos:

• Clasificación → necesita ejemplos etiquetados
• Generación → necesita restricciones y formato
• Búsqueda → necesita los datos relevantes, no instrucciones sobre cómo buscar

El modelo no es el cuello de botella

Cada vez que un cliente nos dice “el agente no funciona bien, ¿deberíamos cambiar de modelo?”, lo primero que revisamos es el contexto. En la mayoría de los casos — diría que ~80% — el problema no es el modelo. Es que el modelo recibe demasiada información irrelevante y muy poca información relevante.

La ingeniería de contexto no es un proyecto de una vez. Es mantenimiento continuo, igual que optimizar consultas de base de datos o refactorizar código. Cada vez que cambias un flujo de trabajo, los datos disponibles o las herramientas del agente, el contexto necesita ajuste.

Si ya tienes agentes desplegados o un piloto corriendo, mándanos el system prompt, las definiciones de herramientas y un ejemplo de datos recuperados para un agente. Lo revisamos y te enviamos un reporte de ingeniería de contexto — qué sobra, qué falta y dónde se están desperdiciando tokens. Sin reunión, solo los archivos. Escríbenos acá.