El costo de contexto descartado revela cuánto paga un agente por información que nunca usa

Los agentes pagan por mucho contexto que entra a la ejecución y nunca participa realmente en la decisión. Documentos completos, historiales largos, respuestas de tools y recuerdos pueden ocupar miles de tokens aunque el resultado final dependa de unas pocas afirmaciones. El costo de contexto descartado intenta hacer visible esa diferencia: cuánto texto fue cargado, procesado o recuperado pero no terminó sustentando ninguna decisión, cita, acción o estado relevante. No busca castigar la exploración; busca distinguir evidencia útil de ruido que se transporta por comodidad arquitectónica.

Medirlo exige registrar linaje suficiente para saber qué piezas de contexto influyeron en el resultado. No hace falta una atribución perfecta a nivel de token. Puedes identificar documentos recuperados, mensajes consultados, tool outputs y fragmentos citados o utilizados para completar campos. Después calculas qué volumen quedó fuera de la cadena de evidencia. Si una ejecución carga diez documentos y solo dos aportan información a la salida, los ocho restantes forman parte del contexto descartado. La métrica puede expresarse en tokens, costo monetario o porcentaje del contexto total.

La segmentación por origen revela dónde la arquitectura está siendo demasiado generosa. Tal vez el problema vive en memoria conversacional que se adjunta entera, en un RAG que devuelve demasiados chunks o en tools que responden objetos enormes aunque el agente necesita tres campos. Cada fuente requiere una intervención distinta. Para memoria, resume o selecciona por relevancia; para RAG, mejora retrieval y reranking; para tools, crea una respuesta normalizada y mínima. Reducir contexto útil por error empeora calidad, así que el objetivo es retirar lo que sistemáticamente no participa.

El costo descartado también afecta latencia y estabilidad, no solo la factura de tokens. Un contexto enorme tarda más en transferirse, aumenta la superficie donde pueden aparecer instrucciones irrelevantes y obliga al modelo a distinguir señales entre detalles que no cambian la tarea. Además, cuando las ejecuciones son largas, esos residuos se acumulan con cada paso. Observar p50 y p95 de contexto descartado por clase de tarea permite encontrar workflows donde el crecimiento del prompt es estructural. Una tarea que empieza ligera y termina duplicando contexto en cada iteración probablemente necesita una política de compresión.

Las pruebas deben comprobar que una reducción de contexto no destruye decisiones correctas. Toma un corpus de tareas, mide qué partes del contexto nunca se utilizaron y crea una versión más selectiva. Después compara exactitud, herramientas elegidas, costo y latencia. Si el sistema mantiene calidad y reduce tokens, encontraste desperdicio real. Si la calidad cae, alguna información aparentemente “descartada” estaba ayudando indirectamente al razonamiento. La métrica es una señal para experimentar, no una orden ciega de recortar hasta alcanzar el prompt más pequeño posible.

Una arquitectura agentic madura trata el contexto como presupuesto y no como bodega infinita. Cada pieza que entra debería justificar por qué puede ser útil para la tarea actual y existir un mecanismo para olvidar lo que dejó de aportar. Medir contexto descartado obliga a hacer visible ese costo de oportunidad. La meta no es que todo fragmento termine citado, sino que el sistema deje de pagar sistemáticamente por transportar información que nunca cambia una decisión. Cuando eso ocurre, la eficiencia deja de depender solo del precio del modelo y empieza en el diseño del contexto.

Cierre operativo. El contexto también es infraestructura: lo que entra sin aportar consume dinero, tiempo y atención del modelo aunque nunca aparezca en el resultado. En la práctica, conviene mide contexto cargado frente a contexto utilizado y segmenta desperdicio por memoria, RAG y tool outputs antes de ampliar el workflow.