Asana afirma haber reducido 76 veces el coste estimado de ejecución de uno de sus agentes de navegador y haber multiplicado por cinco su velocidad. El dato procede de un estudio técnico publicado el 8 de octubre de 2026 por Asana y StackAI y ampliado por OpenAI un día después. La mejora no se obtuvo simplemente sustituyendo un modelo caro por otro barato. El cambio decisivo fue reorganizar cómo el agente conservaba, recortaba y reutilizaba su historial de navegación.
El caso es útil porque muestra un problema que aparece cuando un agente trabaja durante muchos pasos: cada nueva llamada puede volver a enviar instrucciones, herramientas, texto extraído de páginas y capturas de pantalla. Si ese contexto cambia continuamente, la caché deja de ser reutilizable y el coste crece aunque el objetivo de la tarea sea sencillo. Asana convirtió ese problema en un experimento controlado de 144 ejecuciones, más una prueba de seguimiento de 12 ejecuciones.
Qué optimizó exactamente Asana
La empresa estaba trabajando con un agente de navegador integrado en StackAI, la plataforma que adquirió para automatizar procesos entre aplicaciones. Este tipo de agente puede abrir páginas, recopilar información, completar formularios y encadenar acciones sin que el usuario tenga que programar cada paso.
El agente ya reutilizaba mediante caché sus instrucciones fijas y la definición de sus herramientas. Sin embargo, no conseguía aprovechar de la misma manera el historial creciente de páginas visitadas. En cada paso eliminaba la captura anterior y recortaba fragmentos antiguos de texto para mantenerse dentro de un presupuesto de contexto. Cada modificación alteraba una parte previa de la solicitud y rompía el prefijo estable que la caché necesita para reutilizar tokens.
El resultado era paradójico: el sistema tenía caché, pero gran parte del contexto se volvía a procesar a precio completo. Además, al borrar información demasiado pronto, el agente podía perder hechos ya encontrados y verse obligado a visitar de nuevo páginas anteriores.
Las tres modificaciones principales
1. Incluir el historial en la estrategia de caché
El primer cambio consistió en colocar un marcador de caché después del resultado más reciente de una herramienta. Así, no solo las instrucciones iniciales, sino también una parte extensa del historial de navegación podía permanecer estable entre llamadas sucesivas.
La lección práctica es que almacenar únicamente el prompt del sistema no basta para agentes largos. En una tarea de varios pasos, la mayor parte de la entrada puede acabar siendo el rastro acumulado: textos, observaciones, respuestas de herramientas y referencias visuales.
2. Podar capturas en lotes, no una por una
En lugar de eliminar la captura anterior en cada paso, el flujo optimizado permitía acumular hasta 20 capturas y después conservaba solamente la más reciente. Durante aproximadamente 19 llamadas consecutivas, la parte anterior del historial permanecía sin cambios y podía reutilizarse.
Este método de poda por lotes no significa que 20 sea un número universal. Depende del modelo, la ventana de contexto, el tamaño de las imágenes y la duración habitual de las tareas. Lo importante es el principio: si cada llamada reescribe el pasado, la caché pierde valor; si el historial es casi inmutable y solo se compacta en momentos definidos, la reutilización aumenta.
3. Aumentar el presupuesto de historial
Asana comparó presupuestos de 120.000 y 480.000 caracteres. Con el límite pequeño, GPT‑6.1 Sol solo produjo una respuesta final en 3 de 18 ejecuciones de las configuraciones analizadas; con el presupuesto grande, terminó las 18 y devolvió la respuesta correcta en todas.
Conservar más contexto puede parecer contrario al objetivo de ahorrar. Sin embargo, un presupuesto demasiado estricto provoca recortes, destruye segmentos reutilizables y puede obligar al agente a repetir trabajo. La eficiencia no consiste siempre en enviar menos información, sino en enviar de forma estable la información necesaria.
Cómo se diseñó el estudio
GPT‑6 Astra, ejecutado mediante Codex, auditó el código, instrumentó las solicitudes, lanzó pruebas y analizó las trazas. Los responsables humanos definieron el objetivo, eligieron las propuestas que debían probarse y revisaron las conclusiones. Asana utilizó Command como registro de las sesiones, solicitudes, resultados y cambios que posteriormente llegaron a producción.
El estudio comparó seis políticas de caché e historial, dos presupuestos de contexto y cuatro modelos. Cada condición se ejecutó tres veces. La tarea era recopilar seis campos de cada uno de 32 libros de un catálogo público de demostración; en total, el agente debía localizar 192 datos.
Los modelos rivales se anonimizaron como A, B y C. El modelo B era el que utilizaba originalmente el flujo de producción y tenía un precio equivalente al de GPT‑6.1 Sol. Esta anonimización impide comparar marcas concretas, pero permite estudiar el efecto del diseño del agente y del modelo elegido sobre el coste y el tiempo.
Asana calculó los costes con los contadores de tokens de cada proveedor y contrastó las respuestas con una referencia preparada de forma independiente. Según la empresa, todas las mejores configuraciones localizaron correctamente los 192 hechos.
De 36,21 dólares a 0,47 por ejecución
En el modelo B, el flujo original costaba al menos 36,21 dólares por ejecución estimada. Algunas pruebas alcanzaron el límite de pasos antes de terminar, por lo que esa cifra es un mínimo, no necesariamente el coste total que habrían alcanzado sin el tope.
Aplicando el flujo optimizado al mismo modelo B, el coste bajó a 1,24 dólares: una reducción de 29 veces. Al usar GPT‑6.1 Sol con la misma estrategia, el promedio quedó en 0,47 dólares. Frente al punto de partida del modelo B, el descenso comunicado fue de 76 veces.
El tiempo también cambió. La configuración original necesitaba al menos 22,5 minutos, mientras que el flujo optimizado con GPT‑6.1 Sol tardó alrededor de cuatro minutos. En esa configuración, el 89 % de la entrada se leyó desde caché.
La propia documentación de GPT‑6.1 Sol indica que la entrada en caché cuesta menos que la entrada nueva. Por tanto, aumentar el porcentaje de contexto reutilizado puede cambiar radicalmente el coste de una tarea repetitiva, incluso sin reducir de forma drástica el número de pasos.
Qué significa realmente la cifra de 76 veces
La cifra no demuestra que cualquier agente de navegador vaya a ser 76 veces más barato. Se refiere a una tarea concreta, un flujo inicial concreto, unos modelos determinados y una comparación cuyo punto de partida era especialmente ineficiente. Tampoco equivale a una reducción general del precio de Asana ni a una garantía para todos los clientes de StackAI.
Sí demuestra algo más transferible: en agentes con historiales largos, el diseño del contexto puede pesar tanto como la tarifa del modelo. Cambiar de proveedor sin corregir un historial que se reescribe a cada paso puede dejar intacta la principal fuente de desperdicio.
La comparación también mezcla dos mejoras: la optimización del flujo redujo 29 veces el coste en el modelo B y el paso a GPT‑6.1 Sol aportó una reducción adicional de 2,6 veces respecto a ese modelo B ya optimizado. Separar ambas capas evita atribuir toda la ganancia únicamente al modelo.
Qué puede aplicar una empresa pequeña
Una pyme no necesita reproducir 144 ejecuciones para obtener valor del estudio. Puede empezar por registrar cinco métricas: coste por tarea, duración, número de pasos, porcentaje de entrada en caché y tasa de finalización correcta. Sin esos datos, una automatización puede parecer económica porque termina rápido en algunos casos mientras repite navegación o falla silenciosamente en otros.
También conviene distinguir entre información fija y contexto creciente. Las reglas, esquemas de herramientas y criterios de salida deberían permanecer estables. Las observaciones nuevas deberían añadirse al final siempre que sea posible. La compactación puede hacerse en puntos definidos, evitando reescribir el historial completo en cada turno.
Para quien esté empezando con automatizaciones, una base visual o local puede ayudar a comprender primero disparadores, nodos, credenciales y control de errores. En FormateConIA hemos analizado tanto una formación sobre automatización en local con n8n como el ebook Domina N8N desde Cero. Son enfoques comerciales distintos, pero ambos permiten entender por qué medir el flujo completo es tan importante como elegir el modelo.
La caché no sustituye a los límites de seguridad
El estudio advierte que ningún agente debería crecer sin control. Si se desvía del objetivo, el historial se acerca al límite de contexto; si la caché se rompe, cada llamada vuelve a pagarse a precio completo. Límites de pasos, tokens y coste por ejecución reducen el impacto de una sesión defectuosa.
El control tampoco se limita al presupuesto. Un agente que navega, completa formularios o ejecuta acciones debe respetar permisos y requerir aprobación cuando corresponda. La comparación con el Arena Alignment Index sobre agentes que actúan sin permiso recuerda que una ejecución barata no es una ejecución segura.
Asana mantuvo revisión humana en el proceso experimental: una persona fijaba el objetivo y los criterios, revisaba las propuestas y validaba los cambios antes de producción. Ese reparto evita confundir autonomía operativa con ausencia de responsabilidad.
El contexto como parte de la arquitectura
Durante mucho tiempo, la ingeniería de prompts se concentró en redactar mejores instrucciones. En agentes de larga duración, la arquitectura del historial es igual de importante. Hay que decidir qué se conserva, qué se resume, cuándo se eliminan imágenes y cómo se registra la evidencia necesaria para verificar el resultado.
El caso de Asana muestra cuatro capas que deberían medirse por separado:
- Prompt fijo: instrucciones, políticas y definición de herramientas.
- Memoria de trabajo: páginas, resultados y observaciones de la sesión actual.
- Poda o compactación: reglas para reducir el historial sin destruir información necesaria.
- Registro externo: trazas que permiten auditar y comparar ejecuciones sin depender de la memoria de una sola sesión.
Esta separación también aparece en agentes empresariales más amplios. Nuestro análisis del agente universal de Gemini para el trabajo explica por qué la integración con datos, permisos y aplicaciones determina el valor real mucho más que una demostración aislada del modelo.
Una lista práctica antes de optimizar
- Elegir una tarea reproducible. Debe tener una respuesta comprobable y una dificultad representativa del uso real.
- Guardar las trazas. Sin solicitudes, contadores y resultados no es posible saber dónde se consume el presupuesto.
- Separar el coste del modelo y el del diseño. Primero optimizar el flujo; después comparar modelos sobre la misma configuración.
- Medir calidad, no solo precio. Una ejecución barata que omite datos o no termina no es una mejora.
- Revisar el historial estable. Comprobar si las primeras partes de la solicitud cambian innecesariamente.
- Probar varios presupuestos. Un contexto excesivamente pequeño puede generar más repeticiones y fallos.
- Definir topes. Establecer límites de pasos, tiempo, tokens y coste.
- Mantener revisión humana. Los cambios de producción deben pasar por una validación independiente.
Limitaciones que no deben ocultarse
El estudio fue realizado y publicado por las empresas implicadas, no por un equipo académico independiente. Las medias proceden de tres ejecuciones por condición y las cuentas variaban entre pruebas. Los valores de dispersión mostrados en la publicación son aproximaciones reconstruidas a partir de gráficos, porque no se publicaron todos los datos individuales.
Además, la tarea consistía en recopilar datos de un catálogo de demostración. No cubre por sí sola procesos con autenticación compleja, webs dinámicas, cambios frecuentes de interfaz, decisiones ambiguas o consecuencias económicas reales.
Asana señala que el seguimiento sin poda resultó ligeramente más barato en una prueba posterior. Eso no convierte la ausencia de poda en una regla universal: tareas más largas, ventanas pequeñas o tarifas de caché diferentes pueden necesitar compactación. La conclusión correcta es medir con el propio flujo, no copiar un número fijo.
Preguntas frecuentes
¿Qué es un agente de navegador?
Es un sistema que utiliza un modelo y herramientas para observar páginas, desplazarse, hacer clic, extraer información o completar acciones. A diferencia de un chatbot que responde una sola pregunta, mantiene un historial de varios pasos.
¿Por qué romper la caché encarece tanto una tarea?
Porque el proveedor solo puede reutilizar la parte inicial que permanece idéntica. Si el agente modifica continuamente capturas o texto antiguo, gran parte de la entrada debe procesarse otra vez como contenido nuevo.
¿Más contexto siempre es mejor?
No. Debe ser suficiente para conservar los hechos necesarios, pero necesita límites. Un historial descontrolado aumenta latencia y riesgo de coste. La clave es combinar un presupuesto adecuado, estructura estable y compactación cuando sea necesaria.
¿GPT‑6.1 Sol fue 76 veces más barato por sí solo?
No. La mejora total combina una arquitectura de historial más eficiente con el cambio de modelo. El flujo optimizado redujo 29 veces el coste en el modelo B; GPT‑6.1 Sol redujo después el coste otras 2,6 veces frente al modelo B optimizado.
¿Qué debería medir primero una empresa?
Coste por tarea completada correctamente, duración, pasos, entrada nueva frente a caché y porcentaje de ejecuciones que alcanzan el resultado esperado. La métrica importante no es el precio de una llamada aislada, sino el coste de una tarea útil y verificada.
Conclusión
El experimento de Asana no ofrece una receta universal, pero sí una advertencia concreta: un agente puede gastar mucho no porque el modelo sea necesariamente caro, sino porque su historial cambia de forma que impide reutilizarlo. Mantener el contexto estable, podar en lotes y ajustar el presupuesto al modelo permitió reducir el coste estimado desde al menos 36,21 dólares hasta 0,47 y acortar una ejecución de más de 22 minutos a unos cuatro.
La lección más importante es metodológica. Antes de cambiar de modelo, hay que instrumentar el flujo, conservar trazas, medir la calidad y localizar qué parte del contexto se vuelve a pagar. Solo entonces puede saberse si la mejora procede de una caché mejor utilizada, de un modelo más eficiente o de ambas cosas.