Equipos de agentes por $155 en vez de $510: Cohere descubre dónde delegar sale rentable

Los agentes se mudaron a producción

En el último año, los equipos de agentes programadores han dejado de ser demostraciones interesantes para convertirse en proyectos industriales reales. Dieciséis agentes Claude escribieron un compilador de C de 100.000 líneas capaz de compilar el núcleo de Linux, gastando alrededor de 2.000 sesiones y $20.000 en API. El equipo de Cursor lanzó cientos de agentes que escribieron conjuntamente un navegador web con más de un millón de líneas de código en una semana. El proyecto Bun migró su base de código de Zig a Rust en 11 días usando 64 agentes Claude trabajando en paralelo.

Cada uno de estos proyectos entregó código funcional, pero se diferenciaron en la forma de organizarse: el compilador lo construyeron agentes con estatus igualitario, sin orquestador, tomando tareas mediante archivos lock; Cursor aplicó una jerarquía — planificadores que dividían recursivamente el trabajo en subtareas para cientos de trabajadores; Bun asignó roles fijos: un implementador, dos revisores críticos y un corrector por cada tarea.

Comparar estos proyectos entre sí no diría mucho sobre qué decisiones realmente pesaron ni cuánto costaron. Factory publicó una investigación sobre su propio sistema de tres roles (orquestador → implementador → validador en bucle): en una sola tarea (restaurar la biblioteca GDAL), su equipo duplicó el resultado de un solo agente, pero costó 14 veces más y tardó 13 veces más tiempo.

Dónde delegar importa más que cuántos agentes usar

Cohere construyó un banco de pruebas controlado basado en mini-SWE-agent: cada agente trabaja a través de una interfaz bash en un espacio de trabajo compartido, el líder reparte tareas mediante una herramienta delegate_agent y los trabajadores solo ven su propia subtarea. Se investigaron cinco variables:

1. Dónde usa el líder a los trabajadores: un prompt mínimo simplemente ordena dirigir al equipo; uno estructurado (P-I-V) añade etapas explícitas — planificación, implementación, verificación. 2. Cómo espera el líder: síncrono (espera a que todos informen) o asíncrono (sigue trabajando él mismo, revisando actualizaciones cuando lo necesita). 3. Qué modelos en qué roles: equipos homogéneos (todos sobre Sol) frente a heterogéneos (líder sobre Sol, trabajadores sobre Luna). 4. Tamaño del equipo: el líder decide por sí mismo cuántos trabajadores necesita, o el tamaño queda fijo en 2, 4, 8 o 16. 5. Comunicación: a través del líder (por defecto) o directamente entre agentes.

Las pruebas se realizaron sobre el benchmark ProgramBench — 200 programas, desde utilidades (jq, ripgrep) hasta sistemas complejos (SQLite, FFmpeg, un intérprete de PHP). El agente solo ve el binario en funcionamiento y la documentación del programa original, y debe averiguar su comportamiento mediante ingeniería inversa para escribir una nueva implementación. La evaluación es el porcentaje de pruebas de comportamiento superadas.

La planificación paga el doble

Un equipo completo de agentes Sol superó a un solo agente por 9,7 puntos (61,8% frente a 52,1%), pero costó entre 4 y 7 veces más. Un líder asíncrono ahorra tiempo: con un prompt PIV, el equipo termina un 19,5% más rápido con el mismo resultado.

El hallazgo principal: cuando el líder delegó únicamente la planificación (agentes Luna que investigan el programa, averiguan su comportamiento y esbozan un plan), logró un 63,6% de corrección por $249. Eso es exactamente la mitad de los $510 que gasta un equipo que delega las tres etapas, y pierde apenas 0,4 puntos (63,2% frente a 63,6%). La implementación y la verificación dieron resultados notablemente inferiores — entre 58% y 71% con los mismos 16 agentes.

La razón está en el diseño de ProgramBench: el programa objetivo es una caja negra, y su comportamiento hay que descubrirlo mediante pruebas. Los trabajadores-planificadores sondean en paralelo distintas partes de la interfaz, y el líder recopila los informes y escribe el código él mismo. Ese es el paralelismo que más rentabilidad genera.

En el caso de la utilidad dsq: un solo agente con prompt PIV obtuvo un 60%, un equipo que delegó solo la planificación obtuvo entre 76% y 79%, y cada una de sus seis ejecuciones superó a cada ejecución individual. Delegar la implementación o la verificación en las mismas condiciones dio entre 58% y 71%.

Un benchmark secundario, Commit0-Lite (16 bibliotecas de Python con la implementación eliminada pero documentación y pruebas completas), confirmó el patrón: cuando la especificación se da de forma explícita, la etapa de planificación sigue siendo crítica.