El arnés de IA del escritor reduce el gasto en tokens en casi un 40%, sin sacrificar la precisión

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:

• 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».