La IA empresarial se enfrenta a una paradoja del retorno de la inversión. Si bien aplicar más computación al modelo básico más sólido funciona bien en experimentos de productos, los costos se vuelven insoportables cuando el producto se implementa en producción.
A papel nuevo de los investigadores de Writer proporciona una solución accesible para los equipos de ingeniería. El estudio analiza sistemáticamente la optimización de los diferentes componentes de la capa de orquestación que envuelve el modelo básico, también conocido como el arnés de IA.
Al optimizar el aprovechamiento, los investigadores muestran reducciones dramáticas en tokens por tarea, una caída en el costo por tarea exitosa de hasta un 61% y una calidad que se mantiene estable, todo sin cambiar el modelo básico subyacente.
Debido a que el arnés está totalmente bajo el control del desarrollador y no requiere ningún ajuste del modelo, los equipos de ingeniería pueden aplicar estos hallazgos para crear aplicaciones de IA altamente rentables.
La crisis del ROI del tokenmaxxing
El estado actual de la ingeniería de IA está plagado de «tokenmaxxing«, una tendencia de la industria en la que los desarrolladores dependen de ventanas de contexto masivas y del consumo de tokens de fuerza bruta como sustitutos de un buen diseño del sistema.
En lugar de diseñar flujos de trabajo elegantes, los desarrolladores han importado un reflejo del desarrollo de software tradicional: generar, ejecutar, fallar, devolver el error y más contexto a la ventana y volver a intentarlo.
«Teams tokenmaxx porque es la solución más barata en este momento y porque así es literalmente como trabajan la mayoría de los ingenieros hoy en día», dijo a VentureBeat Waseem AlShikh, CTO y cofundador de Writer. Debido a que este enfoque tiene éxito con bastante frecuencia en tareas de codificación, se ha convertido en el reflejo predeterminado para cualquier otra carga de trabajo de agencia. El peligro es que las caídas de precios por token oculten la ineficiencia subyacente.
«Su factura es tokens por tarea multiplicada por precio por token, y la mayoría de los equipos sólo miran el segundo número», dijo AlShikh. «En las cargas de trabajo agentes, los tokens por tarea se agravan (cada iteración del bucle retransmite el contexto creciente) y se agrava más rápido de lo que caen los precios. El recorte de precios se convierte en un anestésico. Enmascara el hecho de que el bucle en sí está sangrando».
Tokenmaxxing conduce a varios modos de falla empresarial. Los equipos dirigen tareas sencillas a modelos fronterizos premium de forma predeterminada. Utilizan el LLM como un índice de búsqueda diferido, llenando la ventana contextual con documentos sin procesar en lugar de recuperar respuestas exactas. Lo más destructivo es que construyen bucles agentes sin restricciones que se salen de control cuando el modelo encuentra un error. Debido a que los tokens de salida cuestan significativamente más que los tokens de entrada en todos los principales proveedores de modelos, la ejecución ineficiente de tareas actúa como un asesino silencioso del presupuesto.
La industria ha introducido varias técnicas de eficiencia para frenar estos costos, pero en gran medida se quedan cortas porque tratan el modelo de forma aislada:
-
Compresión inmediata condensa el texto de entrada para ahorrar espacio, pero ignora cómo el sistema secuencia esas entradas en flujos de trabajo complejos.
-
razonamiento presupuestado limita los pasos computacionales que puede tomar un modelo, lo que a menudo degrada la calidad de la salida si el flujo de trabajo no se enruta de manera inteligente.
-
codificación concisa obliga a los modelos a generar un código mínimo para guardar tokens de salida, pero no hace nada para resolver las llamadas de herramientas ineficientes.
-
Decodificación especulativa utiliza un modelo borrador más pequeño para acelerar la generación de texto de un modelo más grande, optimizando la velocidad de inferencia sin abordar arquitecturas de agentes infladas.
Estos esfuerzos fracasan porque optimizan el motor ignorando la transmisión. No analizan la capa de orquestación, lo que deja sin resolver las ineficiencias arquitectónicas subyacentes.
Desempacando el arnés: las palancas de la eficiencia
El arnés es la capa de orquestación que enruta, formatea y convierte el LLM subyacente en un sistema funcional.
Las palancas principales de la optimización del aprovechamiento incluyen el almacenamiento en caché de avisos del sistema, la compactación del historial de interacciones, la gestión de herramientas, las estrategias de recuperación y la gestión de errores. Estos son los puntos de intervención más accesibles para los equipos de ingeniería que buscan mejorar el rendimiento de la IA.
Como señalan los investigadores de Writer en el estudio: «Si el arnés es la capa que compone las llamadas al trabajo del modelo, también es la capa que fija el precio del trabajo».
Históricamente, los desarrolladores han tratado el arnés como un código adhesivo desechable diseñado simplemente para conectar una API a una interfaz de usuario. El estudio señala que el arnés debe ahora ser tratado como un objeto de primera clase: un artefacto de software primario que requiere sus propias pruebas, control de versiones y diseño riguroso.
Para las empresas, esto reformula la decisión de «propiedad versus alquiler».
«Las empresas pasan meses evaluando modelos y luego alquilan su orquestación, lo que significa que están optimizando la palanca más pequeña y subcontratando la más grande», dijo AlShikh. «Quien sea dueño del arnés es dueño de la economía de su unidad, y un marco abierto adaptado para demostraciones no está adaptado para su factura».
Dentro de los experimentos
Para aislar el impacto de la capa de orquestación, los investigadores realizaron experimentos en seis modelos básicos que abarcaban múltiples proveedores y clases de peso: Claude Sonnet 4.6, Gemini 3.1, Gemini Flash 3.5, Qwen 3.6, GLM 5.1 y el propio modelo de Writer, Palmyra X6.
Sus experimentos compararon un bucle de agente de producción convencional congelado con el Writer Agent Harness terminado en las mismas 22 tareas empresariales bloqueadas, que abarcan capacidades como conexión a tierra y recuperación, flujos de trabajo de varios pasos, uso de herramientas y generación de contenido. Al mantener constantes los modelos y las tareas, podrían aislar los efectos de la propia capa de orquestación.
El arnés optimizado generó una caída significativa en los costos, reduciendo el costo combinado por tarea en un 41 %, de 21 centavos a 12 centavos. Esto se logró en gran medida reduciendo drásticamente el consumo de tokens, y el número de tokens por tarea cayó un 38 %, de 14,2 mil a 8,8 mil.
El arnés está diseñado para delegar tareas como la búsqueda a subagentes especializados. Un subagente recibe solo la herramienta y la consulta específica que necesita, recupera los datos exactos y devuelve un resumen limpio y limitado al agente principal, evitando que la ventana de contexto principal se llene con resultados de búsqueda sin procesar.
Las tasas de éxito de las tareas se mantuvieron estables incluso cuando el uso de tokens disminuyó, pasando del 78% al 81%, una ganancia que los investigadores describen como direccional en lugar de estadísticamente significativa en el tamaño de su muestra, lo que significa que la calidad no se vio afectada incluso cuando los costos disminuyeron.
La latencia de las tareas de un extremo a otro también se redujo significativamente, reduciendo el tiempo medio del reloj de pared en un 44 %, de 48 segundos a 27 segundos, debido al almacenamiento en caché rápido y a la eliminación de bucles de razonamiento sin salida.
Sin embargo, los investigadores también encontraron límites a la orquestación de múltiples agentes. Los modelos más pequeños como Gemini Flash 3.5 y Qwen 3.6 obtuvieron puntuaciones muy por debajo de un umbral de confiabilidad utilizable en tareas de delegación de subagente (0,45 y 0,42, respectivamente); la capacidad simplemente no es confiable todavía en modelos más livianos.
La orquestación de subagente solo cruzó un umbral de confiabilidad utilizable en los dos modelos más fuertes probados: el Palmyra X6 del escritor (0,86) y Claude Sonnet 4.6 (0,85).
El manual del desarrollador: conclusiones prácticas y compensaciones
Los hallazgos del estudio se traducen en un manual para desarrolladores empresariales que crean flujos de trabajo agentes a escala. El primer paso es implementar lo que AlShikh llama «aviso de dos zonas» y «descarga de contexto».
Estructura para el almacenamiento en caché del mensaje del sistema (el mensaje de dos zonas): Las API LLM modernas ofrecen almacenamiento en caché rápido, pero los desarrolladores deben estructurar sus cargas correctamente para activarlo. Los desarrolladores deben separar la «zona estable» de la «zona volátil». Coloque elementos estáticos e inmutables (p. ej., reglas básicas, esquemas de herramientas grandes y procedimientos operativos estándar) en la parte superior del mensaje. Los elementos dinámicos, como la consulta específica del usuario o el estado reciente de la tarea conversacional, deben agregarse en la parte inferior. Este orden permite que el arnés reutilice el prefijo almacenado en caché en cientos de llamadas. «Esa separación única hace que el almacenamiento en caché rápido realmente funcione y evita que usted vuelva a pagar por las mismas instrucciones en cada uno de los treinta pasos de un agente», dijo AlShikh.
Administre el contexto con la descarga de contexto: Evite el relleno de contexto, donde cada vuelta de un bucle se agrega a un mensaje monolítico hasta que la ventana alcanza su máximo. En su lugar, mueva el historial y los artefactos intermedios fuera de la ventana a un almacenamiento recuperable y retire solo lo que necesita el paso actual. Si es posible, delega tareas a subagentes de propósito único para evitar la sobrecarga del contexto. Como señala AlShikh, «la partida más importante en el gasto de los agentes no es el razonamiento, sino el reenvío de cosas que el modelo ya ha visto».
Cree bucles resilientes y redefina los KPI: Los bucles de agentes no administrados agotan rápidamente los presupuestos de API. Los equipos deben comenzar a realizar un seguimiento de los tokens de finalización por millón (CPM) para comprender los verdaderos costos de las tareas, pero el arnés en sí debe contener barreras físicas. «El principio fundamental es que nunca se le pide al modelo que controle su propio gasto», dijo AlShikh. «La valla tiene que vivir debajo del modelo, en código, en tu lado de la API». Esto requiere tres controles rigurosos:
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.
-
Presupuestos de tokens estrictos por tarea: La ejecución termina cuando se gasta el presupuesto, sin excepciones.
-
Cercado de generación: Límites de pasos, llamadas de herramientas y profundidad de recursividad para detener agentes no convergentes.
-
Gobernanza del gasto fallido: Limite lo que puede gastar una ejecución después de su primera validación fallida para que una tarea fallida no se convierta en la más costosa.
Evite complejidades innecesarias: La optimización de la capa de orquestación conlleva una sobrecarga de ingeniería. Si se encuentra en la etapa de creación de prototipos y exploración, esa sobrecarga no está justificada: repita rápidamente con un modelo sólido y un arnés liviano. Una vez que esté escalando a millones de solicitudes por día, los ahorros de la optimización del aprovechamiento se vuelven sustanciales.
Sin embargo, los equipos deben ser conscientes del «apalancamiento». Agregar andamiaje estructural requiere que el modelo sostenga y obedezca ese contexto. Si un modelo es demasiado pequeño, gastará su capacidad limitada analizando el andamio en lugar de realizar la tarea, lo que hará que la precisión disminuya y los tokens aumenten. La regla para agregar características de orquestación complejas es estrictamente matemática: «Si una característica agrega más tokens de coordinación de los que elimina tokens de tareas para ese modelo específico, córtela», dijo AlShikh. «Nada en el arnés es gratis».
El futuro del arnés empresarial
La era de tokenmaxxing y de tratar las ventanas contextuales como cubos sin fondo está llegando a su fin. Lanzar más computación a sistemas mal diseñados no es una estrategia viable para las empresas que necesitan demostrar un retorno de sus inversiones en IA.
A medida que los modelos básicos evolucionen para absorber la planificación, la selección de herramientas y el razonamiento de varios pasos de forma nativa en sus pesos, el papel del arnés pasará de compensar la debilidad del modelo a hacer cumplir la política empresarial.
«Lo que nunca entra en el modelo es lo ‘permitido’: presupuestos, permisos, límites de datos, pistas de auditoría, interruptores deterministas», dijo AlShikh. «Dentro de cinco años, el arnés será más delgado pero más importante. Habrá menos andamios y más gobernanza. Por muy capaz que sea el modelo, alguien externo a él todavía tiene que definir lo que puede gastar, ver y tocar. Esa capa pertenece a la empresa y nunca debería alquilarse».
