Una especificación es un contrato

Este artículo compara dos maneras de poner a trabajar a un grupo de agentes.

Organizar por rol. Dale a cada agente un puesto, un almacén compartido de conocimiento del negocio y una forma de pedir ayuda a los demás. Marblism funciona así. Vende siete empleados de IA a negocios, mantiene un almacén central de conocimiento al que llama the Brain (el cerebro), donde cada elemento puede llegar a algunos o a todos los empleados, y sus empleados “se comunican con otros empleados de IA” cuando una tarea necesita otra habilidad. Las acciones delicadas, como enviar un correo o publicar algo, esperan la aprobación del dueño.

Organizar por contrato. Escribe primero la especificación. Divide el trabajo según sus dependencias. Dale a cada trabajador un contrato: lo que recibe, la forma de lo que devuelve, los archivos que le pertenecen, la prueba que debe pasar. Verifica antes de integrar.

Nosotros construimos de la segunda manera. Nuestro trabajo se basa en especificaciones y contratos compartidos, y el backend y el front end los usan de forma distinta. Nuestro método enuncia dos de sus reglas como contrato antes de repartir y terminado significa verificado. Esto es lo que dicen las fuentes públicas sobre trabajar así, incluido dónde se queda corto.

Dónde vive el control

La documentación de Claude Code enumera cinco maneras de trabajar en varias tareas a la vez. En cuatro de ellas, Claude o un script coordina a los agentes. Este artículo se fija en una diferencia: quién decide qué se ejecuta después. La quinta, agent view, es una sola pantalla para lanzar y vigilar sesiones en segundo plano (vista previa de investigación).

• Subagentes. Decide Claude, turno a turno. Una tarea secundaria corre dentro de una sesión, en su propia ventana de contexto, y devuelve un resumen.
• Equipos de agentes. Decide el agente líder, turno a turno. Los compañeros se envían mensajes y comparten una lista de tareas. Experimental.
• Workflows. Decide el script. Los resultados intermedios viven en variables del script, y una sola ejecución puede reunir de decenas a cientos de agentes.
• Proyectos. Un coordinador abre un hilo por cada tarea. Cada hilo en la nube es su propia sesión y su propio sandbox, y los hilos en la nube comparten los repositorios, archivos, instrucciones y memoria del proyecto. Beta pública.

Fuentes: Subagentes, Equipos de agentes, Workflows, Proyectos, consultadas el 2026-10-25.

En los workflows, parte del contrato se verifica automáticamente: la forma de lo que vuelve. Una llamada agent() puede llevar un esquema JSON. El runtime valida la salida y, si sigue fallando tras cinco intentos, la llamada falla. Escribe ultracode en un prompt y Claude arma un workflow para esa tarea.

El contrato

Nuestra Guía de orquestación pública, extraída de 208 sesiones y 469 envíos a agentes en abril de 2026, dice: “Los contratos de interfaz antes de la implementación son la regla”. Cada envío en paralelo empieza por asignar “manifiestos que no se solapan, uno por agente”. Nada se da por terminado por la palabra de un agente: “El ‘terminado’ de un agente no cuenta como terminado hasta que se verifique de forma independiente”.

El informe de Anthropic sobre su sistema de investigación dice casi lo mismo sobre lo que necesita cada trabajador: “un objetivo, un formato de salida, orientación sobre las herramientas y fuentes que usar, y límites claros de la tarea”. La guía de Anthropic sobre sistemas multiagente describe un experimento en el que agentes de planificación, implementación, pruebas y revisión “gastaron más tokens en coordinarse que en el trabajo en sí”. Ese experimento dividió trabajo de programación por roles, y la guía lo describe en una sola frase, así que no dice nada directo sobre productos como Marblism. El consejo de la guía es dividir por contexto, y señala una interfaz limpia como un buen límite: “Con un contrato de API bien definido, el trabajo de frontend y de backend puede avanzar en paralelo”. Un patrón que, según dice, “funciona bien de forma constante en distintos dominios” es un agente de verificación aparte.

El backend funciona con contratos. El front end, con especificaciones y memoria.

En nuestro trabajo de backend, las especificaciones y los contratos compartidos organizan a los trabajadores y deciden cómo se reparte el trabajo.

En el trabajo de front end, nuestras especificaciones y la memoria del espacio de trabajo compartido llevan a los trabajadores a recursos que orientan el resultado, guiados por la intención del cliente.

La investigación se genera junto con el trabajo y también orienta el resultado.

Los proyectos de Claude Code tienen su propia capa compartida: memoria que cada hilo en la nube lee al empezar, archivos que cada hilo en la nube puede leer, repositorios que cada hilo en la nube clona. El informe de Anthropic recomienda algo parecido dentro de un solo sistema: subagentes que “guardan su trabajo en sistemas externos y luego devuelven referencias ligeras al coordinador”.

Lo que dicen las fuentes en contra

• El gasto puede explicar las mejoras. En el sistema de investigación de Anthropic, el uso de tokens por sí solo explicó la mayor parte de la varianza del rendimiento en un benchmark, BrowseComp. Con presupuestos de razonamiento iguales, los sistemas de un solo agente “igualan o superan de forma constante” a los multiagente en razonamiento de múltiples saltos (multi-hop).
• Programar es el caso difícil. Un estudio de Google Research, Google DeepMind y el MIT (revisado en abril de 2026) informa que SWE-bench Verified “muestra una ligera degradación en todas las arquitecturas MAS”, es decir, en cada configuración multiagente que probó.
• Lo más simple suele ganar. En las comparaciones de Anthropic en varios despliegues empresariales, un solo agente con skills “superó con frecuencia” tanto a un diseño de un solo prompt como a los diseños con subagentes en calidad, “a menudo con menor costo y latencia por tarea”.
• Las escrituras en paralelo son el punto débil. Cognition, la empresa detrás de Devin, dice que los sistemas multiagente “funcionan mejor hoy cuando las escrituras se mantienen en un solo hilo”.
• Los contratos pueden serializar el trabajo. En un preprint de 2026 con un solo autor, una puerta de admisión previa a la escritura elevó mucho el éxito de integración, pero serializó casi todas las ejecuciones, y el estudio no demostró una aceleración en tiempo de reloj.
• Un esquema comprueba la forma. No comprueba si la respuesta es correcta.

Mi respuesta, desde mi propio trabajo: los envíos bien gobernados y bien investigados toman menos tiempo y producen resultados notablemente mejores, con más consistencia. Lo veo en programación y más allá, y tiene que ver con el protocolo: el sistema en su conjunto, una serie de verificaciones y hooks. El protocolo resuelve problemas como las escrituras en paralelo y aparta las tareas más simples de los protocolos complejos.

Costo

La documentación de Claude Code dice que un workflow “puede usar bastantes más tokens que resolver la misma tarea en una conversación”, ejecuta hasta 16 agentes a la vez por defecto y muestra un aviso de “Large workflow” por encima de 25 agentes o 1.5 millones de tokens proyectados. En las pruebas de Anthropic, las implementaciones multiagente “suelen usar de 3 a 10 veces más tokens que los enfoques de un solo agente para tareas equivalentes”.

Una especificación es un contrato

Escríbela primero. Entrégasela a cada trabajador. Contrasta el resultado con ella. El plan de estudios está en la Guía de orquestación.

Las citas de fuentes en inglés son traducciones nuestras.