AWS: una sola herramienta recortó un 95% los tokens por script, y las habilidades bajo demanda, un 97% el prompt

Imagine que le pide a un agente de IA: «Analiza los datos de ventas y haz un informe en DOCX». El agente carga los datos, calcula por categorías, dibuja cinco gráficos, comprueba las estadísticas y redacta el documento. Todo ello lleva unos 15 minutos y más de 150 mil tokens, mientras que la ventana de contexto (la memoria de trabajo del modelo) de Claude Sonnet 4.

5 en Amazon Bedrock es de 200 mil. Si cada script escrito y cada resultado se acumulan en esa memoria, se agota enseguida: el agente falla a mitad de la tarea, pierde precisión o quema presupuesto, porque los tokens se pagan. El equipo de AWS ha mostrado en el proyecto abierto Deep Insight cómo evitarlo.

Las dos cifras principales: una herramienta en lugar de dos reduce en torno a un 95% los tokens que añade cada script, y la carga de habilidades bajo demanda recorta el prompt del sistema en torno a un 97%. Para quien desarrolla agentes, es una vía directa de hacerlos más baratos y fiables.

Por qué un contexto saturado es un problema

El problema no es solo que la ventana pueda agotarse. Anthropic describe el efecto context rot: cuantos más tokens hay en el contexto, peor recuerda el modelo la información necesaria. Los datos obsoletos estorban, y cualquier error obliga a reiniciar todo el pipeline. Por eso AWS ha reunido técnicas de los artículos de ingeniería de Anthropic y de las funciones de Strands Agents SDK en cuatro capas de «ingeniería de contexto». Esta es la segunda parte de una serie; Deep Insight es una solución multiagente para análisis de datos basada en Strands Agents SDK y Amazon Bedrock AgentCore, y todos los ejemplos se muestran sobre ella.

Capas 1 y 2: separar a los agentes y limitar sus respuestas

La primera capa es la arquitectura. Cada agente especializado tiene su propia ventana, y al coordinador solo le llega un resumen comprimido. En Deep Insight la jerarquía es esta: Coordinator, Planner, Plan Reviewer, Supervisor y los agentes de trabajo Coder, Validator, Reporter, Tracker y Auditor. El estado compartido es un diccionario shared_state con solo cuatro campos: el último mensaje del agente anterior, las notas comprimidas clues, la lista de comprobación del plan y un registro breve. Gracias a ello, incluso Coder, el agente más «voraz», se mantiene dentro de los 25 mil tokens.

La segunda capa son los prompts. El aislamiento no basta: si un agente responde con mucha extensión, el contexto de Supervisor se infla igualmente. Por eso los prompts fijan presupuestos de respuesta: Coder, 1000–1500 tokens; Validator, 800; Reporter, 1000. El formato es el mismo para todos: estado, tareas completadas, conclusiones clave con cifras y lista de archivos. Hay además una regla poco evidente: cada script es autosuficiente, es decir, incluye sus propias importaciones y carga los datos desde la caché por sí mismo. Las variables no se conservan entre ejecuciones, pero a cambio el código antiguo puede eliminarse del contexto sin problema.

Capa 3: en el contexto solo hay referencias; los datos, en archivos

Aquí está el ahorro más notable. Lo habitual es que el agente tenga dos herramientas: «escribir archivo» y «ejecutar». Entonces cada script de 100 líneas entra entero en el historial de la conversación, y tras varios análisis acumula más de mil líneas de código. En Deep Insight, una sola herramienta, write_and_execute_tool, hace los dos pasos y devuelve un resumen corto: «Escritas 105 líneas, ejecutado con éxito, análisis de cinco categorías completado». El código queda en disco y en el contexto hay unas tres líneas. Según la estimación de AWS para este ejemplo, el ahorro es de alrededor de un 95% de tokens por script.

También funcionan otras técnicas del mismo tipo:

• El módulo común coder_analysis_utils.py se crea una sola vez, y sus funciones se importan con dos líneas en lugar de las 20–30 que el agente tendría que escribir de nuevo cada vez.
• El archivo all_results.txt hace de bloc de notas: Coder añade ahí los detalles, y Supervisor recibe un mensaje de unos 30 tokens.
• Los archivos sustituyen al traspaso directo de datos entre agentes: calculation_metadata.json va de Coder a Validator, citations.json, de Validator a Reporter, y audit_findings.json, de Auditor a Reporter.
• Las habilidades (Skills) se cargan bajo demanda. En el prompt del sistema hay un catálogo de unos 500 tokens, y el agente solo abre la guía completa SKILL.md (unos 3 mil tokens) cuando la necesita. Si se pegaran todas las guías de golpe, serían más de 20 mil tokens en cada llamada. De ahí el ahorro de alrededor de un 97%, y además se puede añadir una habilidad nueva sin volver a desplegar.

Salvedades y qué hacer en la práctica

Las cifras proceden de la implementación de referencia de la propia AWS y de un único ejemplo ilustrativo con un script de 105 líneas, no de un benchmark independiente. En su tarea el efecto será distinto: cuanto más largos sean los scripts y más pasos haya, más se notará. La cuarta capa es la verificación por agentes independientes (Validator, Auditor) y los limitadores de protección contra el desbordamiento del contexto. En el proyecto es la última línea de defensa por si las tres primeras capas dejan pasar algo.

El orden práctico es este: separe los contextos entre roles, fije presupuestos de respuesta en los prompts y saque lo pesado —código, tablas, resultados— a archivos, pasándolo mediante referencias. El primer paso más barato es fusionar «escribir» y «ejecutar» en una sola herramienta. El patrón agents-as-tools de Strands Agents SDK aporta aislamiento a nivel de framework, así que no será necesario reescribir la orquestación desde cero.