El harness invisible: la capa que decide el coste real de la IA agéntica en empresa
Publicado el
El diseño de la orquestación determina el coste de un sistema agéntico más que el modelo. Cómo pensarlo antes de desplegar.
Cuando una empresa empieza a desplegar agentes de IA, la conversación suele girar alrededor de los propios agentes: qué modelo usar, qué tareas automatizar, qué casos de uso priorizar. Rara vez se habla del harness, la capa de orquestación que decide cómo se coordinan esos agentes. Y ahí está el error.
Un trabajo reciente en arXiv (cs.AI), “The Harness Effect: How Orchestration Design Sets the Token Economics of Enterprise Agentic AI”, pone nombre al fenómeno. La tesis es clara: en sistemas agénticos empresariales, el diseño de la orquestación determina la economía de tokens de forma más decisiva que el modelo subyacente. Puedes contratar el mejor modelo disponible y arruinar el proyecto con un harness mal pensado.
El harness como director de proyecto
El harness no es el agente. Es la capa que coordina a los agentes: decide qué contexto recibe cada uno, cuándo invocan herramientas, cómo se transfieren información entre sí, cuándo termina una tarea y cuándo no.
La analogía más útil es la del director de proyecto en consultoría. Puedes tener un equipo de analistas brillantes, pero si el director les pasa el expediente completo de 300 páginas cada vez que hace una pregunta, el proyecto se encarece sin que nadie sea más productivo. Un buen director da a cada persona exactamente lo que necesita, en el momento en que lo necesita.
Con los agentes de IA ocurre lo mismo. El contexto que recibe cada agente se mide en tokens. Cada token tiene un coste. Y en sistemas con decenas de agentes coordinando en paralelo, ese coste se multiplica con cada decisión de orquestación.
Los tokens como señal de diseño
La economía de tokens no es solo una cuestión de factura. Es una señal de calidad del diseño.
Un sistema donde los agentes se pasan contexto completo en lugar de resúmenes, donde los bucles no tienen condiciones de salida claras, donde los agentes llaman herramientas redundantes porque nadie centraliza el estado, consume tokens de forma desproporcionada. No porque los modelos sean ineficientes, sino porque la arquitectura de coordinación lo es.
Es un problema estructural, no de modelo. Y corregirlo requiere pensar en la orquestación antes de desplegar, no después de recibir la primera factura de API.
Los errores más frecuentes en empresa
Hay tres patrones que se repiten cuando una organización ignora el diseño del harness:
Contexto inflado. Cada agente recibe el historial completo de la tarea, aunque solo necesite los últimos dos pasos. Los tokens de contexto se acumulan conversación tras conversación hasta que el coste escala sin que la utilidad lo haga.
Bucles sin condición de salida. Un agente llama a otro que llama a un tercero que devuelve el control al primero sin criterio de terminación definido. El sistema da vueltas y la factura sube.
Estado no centralizado. Varios agentes leen el mismo dato de la misma fuente por separado porque nadie gestiona el estado compartido. Trabajo duplicado, coste duplicado.
Ninguno de estos errores es un fallo del modelo de lenguaje. Son fallos de diseño de la orquestación.
Lo que cambia cuando se diseña bien
Un harness bien diseñado hace tres cosas concretas: reduce el contexto que recibe cada agente al mínimo necesario para su tarea, define condiciones de terminación explícitas para cada flujo, y centraliza el estado para que los agentes no dupliquen trabajo.
El resultado no es solo un sistema más barato. Es un sistema más fiable. Los bucles desaparecen. Los agentes tienen menos contexto irrelevante que procesar, lo que reduce los errores de razonamiento. La arquitectura escala sin que el coste se dispare.
En los pipelines agénticos que construyo para este sistema, el patrón se repite: las primeras versiones pasan demasiado contexto, tienen condiciones de salida ambiguas y resultan caras. Las iteraciones posteriores son más baratas y más robustas, casi siempre por cambios en la orquestación, no en el modelo.
El punto de partida práctico
Antes de desplegar el primer agente en producción, vale la pena hacerse tres preguntas: ¿Qué contexto necesita exactamente este agente para hacer su tarea? ¿Cuándo termina su tarea, y quién lo decide? ¿Comparte estado con otros agentes, y cómo se gestiona ese estado?
Si no hay respuesta clara para las tres, el harness no está diseñado. Está improvisado. Y la diferencia, a escala, se paga en euros.
¿Cómo está diseñada la capa de orquestación en los sistemas agénticos que tienes en marcha o en construcción?