El debate honesto

Objetivo de maestría

decidirás si una tarea es apta para aislamiento multi-agente aplicando los criterios documentados de Anthropic y el contraargumento de Cognition. Importa porque copiar la arquitectura de moda sin leer sus condiciones de aplicabilidad es cómo se construyen sistemas frágiles caros.

1.1El problema

Dos publicaciones, dos días seguidos de junio de 2025. Las dos hablan de lo mismo. Dicen lo contrario.

El 12 de junio, Cognition publica "Don't Build Multi-Agents". Su tesis es tajante: "in 2025, running multiple agents in collaboration only results in fragile systems". · fuente: corpus E.2 (cognition.ai, 12 jun 2025). El 13 de junio, Anthropic publica su sistema de investigación multi-agente. Su titular: su orquestador con sub-agentes superó al single-agent Opus 4 en un 90,2%. · fuente: corpus E.1 (anthropic.com, 13 jun 2025).

Tu equipo ha leído el segundo post. Te piden partir Magallanes en sub-agentes "porque Anthropic lo hace". ¿Quién tiene razón?

Los dos. Y si no entiendes por qué los dos, copiarás la arquitectura equivocada para tu caso. Anthropic describe research read-heavy paralelizable. Cognition describe el fallo del trabajo write-heavy acoplado. No es una pelea: es un mapa de cuándo cada cosa aplica.

Esta lección te da ese mapa. Al terminar, ante un encargo concreto sabrás decidir —con criterios escritos, no por intuición— si lo aíslas o no. Y sabrás defender el "no" con la misma firmeza que el "sí".

1.2Qué vas a poder hacer

Al terminar serás capaz de:

Leer las cifras de Anthropic con su matiz exacto: qué es eval interna, qué es cota superior, qué es coste.
Citar las dos condiciones que Cognition pone sobre el contexto compartido y las decisiones acopladas.
Aplicar una checklist de decisión (¿paralelizable? ¿read o write-heavy? ¿excede la ventana? ¿valor?) a un encargo y emitir un veredicto justificado.
Reconocer un caso donde el aislamiento NO compensa y argumentar por qué.

Necesitas saber antes:

De N3 (gate C3): tu Magallanes ya tiene el contexto mínimo viable. Lo recuperamos en 1.3.
De N0·L2 (/cursos/context-engineering/diagnostico/los-cuatro-modos-de-morir): qué era el modo "clash" y qué palanca adelantaba. También en 1.3.
El esqueleto congelado de Magallanes: el agente de deep research en LangGraph con sus 3 tools (buscar, leer, escribir_seccion).

1.3Recupera

Antes de seguir, responde de memoria. Esto reactiva lo anterior y engancha lo nuevo.

De N3: en tu Magallanes con contexto mínimo viable, ¿qué partidas redujiste para que cupiera lo esencial?
De N0·L2: el cuarto modo de morir era "información o tools que entran en conflicto". ¿Cómo se llamaba y qué palanca lo atacaba?
¿Cuál de las 3 tools de Magallanes es la única que produce el informe, frente a las dos que solo leen?

Comprueba tu respuesta

Curaste el toolset (solo las tools de alto impacto) y moviste conocimiento a just-in-time: identificadores ligeros que cargas en runtime en vez de meterlo todo upfront. · fuente: corpus D.1/D.3 (gate C3, tools-y-jit).
Context Clash — "When you accrue new information and tools in your context that conflicts with other information in the context". La palanca que lo adelantaba era isolate (dividir el contexto). · fuente: corpus A.3 (Breunig) y B.2 (Martin).
escribir_seccion produce el informe. buscar y leer solo consultan. Esta frontera read/write es el eje de todo el nivel. · fuente: esqueleto congelado de Magallanes (N4).

1.4El concepto

Vamos a leer los dos posts en orden, con sus cifras honestas. Esta sección es densa en números con matices: cada cifra significa algo distinto de lo que parece a primera vista. Lee primero el bloque entero, luego vuelve a cada número y comprueba qué mide exactamente.

La posición de Anthropic, con las cifras leídas bien

Anthropic construyó un sistema orchestrator-workers: un agente lead (Opus 4) que delega en sub-agentes (Sonnet 4) y reúne sus resultados. Ese sistema superó al single-agent Opus 4 en un 90,2%. · fuente: corpus E.1.

Antes de citar ese 90,2% en una reunión, lee la letra pequeña. No es un benchmark externo. Es su eval interna, con una rúbrica LLM-as-judge sobre cuatro ejes: factual/citation accuracy, completeness, source quality y tool efficiency. · fuente: corpus E.1. La diferencia importa: un benchmark externo lo reproduce cualquiera; una eval interna la define quien la publica. El número es real; su alcance, acotado.

Tres cifras más, cada una con su trampa de lectura:

El multi-agente usa ~15× los tokens de un chat; un agente solo, ~4×. · fuente: corpus E.1/A.6. Esto NO es un argumento en contra por sí mismo. Es el precio. La pregunta correcta es si el valor de la tarea lo paga.
El token usage explica el 80% de la varianza de rendimiento en BrowseComp. · fuente: corpus E.1. Volveremos a esta cifra: da munición a los dos bandos a la vez.
El parallel tool calling recortó el tiempo de investigación "up to 90%" en queries complejas. · fuente: corpus E.1. Lee "up to": es una cota superior, el mejor caso, no la media. Citarlo como típico es el error nº1 con este post.

Lo más valioso del post no son las cifras: son las condiciones. Anthropic dice cuándo compensa: breadth-first queries con direcciones independientes simultáneas; tareas que exceden una ventana; alto valor que justifica los tokens; paralelización pesada. Y dice cuándo NO: dominios donde todos los agentes deben compartir contexto o con muchas dependencias. Excluye coding de forma explícita: "fewer truly parallelizable tasks… LLM agents are not yet great at coordinating and delegating to other agents in real time". · fuente: corpus E.1.

Guarda esa lista. Es la checklist de decisión de esta lección.

La posición de Cognition, palabra por palabra

Walden Yan, en Cognition, no dice "el multi-agente nunca funciona". Dice algo más preciso. Sus dos principios, verbatim:

"Share context, and share full agent traces, not just individual messages."

"Actions carry implicit decisions, and conflicting decisions carry bad results."

· fuente: corpus E.2.

Lee el segundo despacio. Una acción —escribir una línea de código, elegir un color— lleva dentro decisiones que nadie escribió: estilo, supuestos, convenciones. Si dos sub-agentes actúan en paralelo sin verse, toman decisiones implícitas incompatibles que luego nadie puede reconciliar.

Su ejemplo es Flappy Bird: dos sub-agentes paralelos producen decisiones visuales y técnicas que no encajan, y el agente final no las puede unir. · fuente: corpus E.2. Su alternativa: single-threaded, más un modelo especializado que comprima "a history of actions & conversation into key details, events, and decisions". · fuente: corpus E.2.

La síntesis del curso: condiciones de aplicabilidad, no contradicción

Aquí está el mapa. El debate no es un desacuerdo; es una división de territorio. Anthropic gana en research read-heavy paralelizable: los sub-agentes responden sin escribir en paralelo. Yan describe el otro territorio: write-heavy acoplado, donde las escrituras paralelas chocan. · fuente: corpus E.2 (lectura del curso).

El propio Yan lo dice del Claude Code de Anthropic, verbatim:

"it never does work in parallel with the subtask agent, and the subtask agent is usually only tasked with answering a question, not writing any code".

· fuente: corpus E.2. Es su interpretación, no doc oficial. Pero encaja con la síntesis: los sub-agentes que responden no chocan; los que escriben sí.

Ahora la cifra que da munición a los dos bandos. El 80% de la varianza la explica el token usage. Anthropic la lee así: gastar más tokens, bien repartidos en sub-agentes paralelos, sube el rendimiento. Cognition la lee al revés: el rendimiento es tan sensible al uso de tokens que un reparto mal coordinado degrada rápido. El mismo dato, dos lecturas. Por eso el dato no decide solo: hace falta la condición.

MAST: el mapa de cómo fallan estos sistemas

Cuando el multi-agente falla, ¿cómo falla? Hay una taxonomía para eso.

MAST (Multi-Agent System Failure Taxonomy) es la primera taxonomía empírica de fallos en sistemas multi-agente. Define 14 modos de fallo en 3 categorías —system design issues, inter-agent misalignment, task verification—. Se construyó sobre 1.600+ trazas anotadas con un acuerdo entre anotadores de Cohen's κ=0,88. · fuente: corpus E.5 (arXiv:2503.13657, mar 2025).

La analogía: MAST es como un manual de modos de fallo de un motor. No te dice si tu motor fallará. Te da el vocabulario para nombrar el fallo cuando ocurra, en vez de decir "se rompió". Dónde falla la analogía: un manual de motor lista frecuencias de avería fiables. Aquí las frecuencias por modo no son verificables, así que solo usamos las categorías, no los porcentajes.

Esa última advertencia es una regla dura. Verás cifras como "15,7% step repetition" circulando: no las cites. El corpus solo soporta la taxonomía y sus tres categorías, nunca las frecuencias por modo. · fuente: corpus E.5 (⛔ frecuencias).

Contraejemplo: dónde el propio Anthropic te diría que no

Toma el caso opuesto al de Anthropic. Imagina paralelizar la escritura del informe de Magallanes: dos sub-agentes redactando secciones distintas a la vez, cada uno con escribir_seccion.

Eso es write-heavy puro. Las dos secciones tomarán decisiones de tono, estructura y terminología que chocarán. Nadie podrá reconciliarlas después. Es el fallo de Flappy Bird trasladado a prosa. El propio post de Anthropic no lo respaldaría: cae en su "cuándo NO". · fuente: corpus E.1/E.2. Por eso, en este nivel, escribir_seccion vive solo en el orquestador.

1.5Míralo funcionar

Vamos a aplicar la checklist a tres encargos reales de Magallanes. La checklist son las cuatro preguntas de Anthropic, una por columna:

¿Es paralelizable? ¿Hay direcciones independientes que avanzan a la vez?
¿Read o write-heavy? ¿Los sub-agentes responden (leen) o producen el artefacto (escriben)?
¿Excede una ventana? ¿El trabajo cabe en un solo hilo o no?
¿El valor lo paga? ¿La tarea vale el coste ~15×?

Un "sí" en las cuatro es señal verde. Un "no" en read/write, o que la tarea quepa de sobra, suele bastar para descartar. Veamos.

Encargo (a): panorama de 10 subtemas independientes sobre 200 documentos

Pregunta	Respuesta
¿Paralelizable?	Sí — 10 subtemas con direcciones independientes.
¿Read o write-heavy?	Read — cada worker busca y lee; devuelve un resumen.
¿Excede la ventana?	Sí — leer los documentos necesarios suma más que una ventana entera.
¿El valor lo paga?	Sí — es el encargo central, de alto valor.

Veredicto: apto. Cae justo en el "cuándo compensa" de Anthropic: breadth-first, direcciones independientes, excede la ventana. · fuente: corpus E.1. Es el encargo que vertebra el nivel.

Encargo (b): refactorizar el informe manteniendo coherencia entre secciones

Pregunta	Respuesta
¿Paralelizable?	No de forma segura — las secciones dependen unas de otras.
¿Read o write-heavy?	Write — el trabajo es producir prosa coherente.
¿Excede la ventana?	No necesariamente — el informe cabe.
¿El valor lo paga?	Irrelevante: ya falla en read/write.

Veredicto: no apto. Es write-heavy con decisiones acopladas: el fallo que Yan describe. Paralelizar la coherencia la rompe. · fuente: corpus E.2.

Encargo (c): una pregunta puntual que cabe en media ventana

Pregunta	Respuesta
¿Paralelizable?	No hay nada que repartir.
¿Read o write-heavy?	Read ligero.
¿Excede la ventana?	No — cabe en media ventana.
¿El valor lo paga?	No — pagarías coordinación a cambio de nada.

Veredicto: no apto. El aislamiento no compra nada aquí: no hay ventana que rescatar ni paralelismo que aprovechar, y sí coordinación que pagar. La pauta de effort scaling de Anthropic lo confirma: "Simple fact-finding requires just 1 agent with 3-10 tool calls". · fuente: corpus E.1. Un solo agente basta.

Self-explanation

Antes de leer la respuesta, intenta tú: ¿por qué el dato del 80% de la varianza da munición a los DOS bandos?

Razónalo y comprueba

Da munición a Anthropic por esto: si el rendimiento sube con los tokens bien usados, repartir el trabajo en sub-agentes paralelos deja gastar muchos más tokens productivos. Cada worker tiene su ventana. Más tokens útiles que un solo hilo, más rendimiento. · fuente: corpus E.1.

Da munición a Cognition porque la misma sensibilidad corta en ambos sentidos. Si el rendimiento depende tanto del uso de tokens, un reparto mal coordinado degrada igual de rápido. Workers que duplican lecturas, que se pisan, que devuelven ruido. La sensibilidad no distingue tokens bien gastados de mal gastados.

La lección: una correlación no trae su propia receta. El 80% dice que los tokens importan mucho; no dice cómo repartirlos. Esa decisión la toman las condiciones —paralelizable, read vs write—, no la cifra.

Si pensaste que el dato "demuestra" que el multi-agente es mejor, revisa. El 80% demuestra que el uso de tokens predice el rendimiento. No demuestra que paralelizar siempre mejore ese uso.

1.6Hazlo tú

Andamiaje decreciente: primero un caso con datos, donde decides; luego un caso sin datos, donde decides qué medir.

Ejercicio 1 — un caso con datos: veredicto justificado

Encargo nuevo para Magallanes:

"Compara las rutas comerciales de tres potencias marítimas del siglo XVI. Cada comparación necesita leer ~8 documentos. El cliente paga por un informe de referencia que se citará durante años."

Aplica la checklist (las cuatro preguntas) y emite un veredicto justificado. No basta "sí" o "no": cita qué criterio de Anthropic o de Cognition lo sostiene.

Criterio de corrección + feedback

¿Paralelizable? Sí — tres comparaciones con direcciones independientes.
¿Read o write-heavy? Read — los workers leen documentos y devuelven comparaciones destiladas; el informe lo une el orquestador.
¿Excede la ventana? Probablemente — tres comparaciones × ~8 documentos cada una; conviene medirlo, pero apunta a sí.
¿El valor lo paga? Sí — informe de referencia, alto valor.

Veredicto: apto, con effort scaling moderado. Cae en "direct comparisons might need 2-4 subagents with 10-15 calls each" de Anthropic. · fuente: corpus E.1. Tres workers exploradores, uno por potencia; el orquestador une.

Feedback formativo: si justificaste con el criterio correcto (breadth-first + comparación), dominas lo esencial — esa es la dimensión 1 de la rúbrica C4. Si dijiste "apto" sin nombrar el criterio, tu respuesta es correcta pero no defendible ante una revisión; vuelve a la checklist de 1.5 y ánclalo a una condición verbatim del post.

Ejercicio 2 — un caso SIN datos: qué medirías primero

Ahora un encargo donde no tienes los números:

"Investiga el impacto de las especias en la economía europea." Eso es todo lo que sabes.

No decidas todavía. En vez de un veredicto, lista qué medirías primero para poder decidir. Es el eco del método de N0: ante "falla a veces" no priorizabas; medías. Aquí, ante "investiga", no decides; primero acotas.

Comprueba tu respuesta

Antes de decidir si aislar, mediría:

¿Cuántos subtemas independientes hay? Si el encargo se descompone en direcciones paralelas o es un hilo único. Decide la pregunta "¿paralelizable?".
¿Cuántos documentos hay que leer y cuánto pesan? Estima si la lectura excede una ventana. Decide "¿excede la ventana?". El context sweep de N0 (/cursos/context-engineering/diagnostico/el-context-sweep) te dio el método para esta estimación.
¿El entregable es read-heavy (un resumen) o write-heavy (prosa coherente larga)? Decide la columna read/write.
¿Qué valor tiene el encargo? Decide si paga el ~15×.

Feedback: si saltaste directo a "lo aíslo" sin medir, revisa. El encargo vago es exactamente donde se cometen los errores caros: aíslas algo que cabía en media ventana, o intentas paralelizar algo write-heavy. Medir primero es lo que separa la decisión de ingeniería de la copia de moda.

Normaliza el error: es común leer "15×" como argumento en contra siempre. No lo es. El ~15× es el precio; la pregunta correcta es si el valor de la tarea lo paga, no si es alto en abstracto. · fuente: corpus E.1.

1.7Comprueba

Sin pistas. Gate de maestría: distinguir lo que el corpus soporta de lo que no.

Te pasan estas cuatro afirmaciones sobre el debate. Marca cuáles soporta el corpus y corrige las que no, con la versión exacta.

"Anthropic demostró en un benchmark externo que el multi-agente supera al single-agent en un 90,2%."
"Cognition afirma que el multi-agente nunca funcionará."
"Los dos posts salieron el mismo día."
"Los workers de research de Anthropic escriben código en paralelo."

Criterio de corrección + feedback

Falsa en un punto clave. El 90,2% es real, pero NO es un benchmark externo: es su eval interna con rúbrica LLM-as-judge. Corrección: "en su eval interna". · fuente: corpus E.1.
Falsa. Cognition acota a 2025 y al caso colaborativo acoplado: "in 2025, running multiple agents in collaboration only results in fragile systems". No dice "nunca". Su propia alternativa usa un modelo especializado de compresión. Corrección: describe un fallo de condiciones, no una imposibilidad. · fuente: corpus E.2.
Falsa. Cognition fue el 12 de junio; Anthropic, el 13. Días consecutivos, no el mismo día. · fuente: corpus E.2 (corrección §8.6).
Falsa. Los workers de research de Anthropic responden: buscan, leen y devuelven resúmenes. No escriben código en paralelo —eso es justo el caso write-heavy que ambos posts evitan—. · fuente: corpus E.1/E.2.

Feedback formativo: si marcaste la 1 y la 4 como falsas, dominas el núcleo del nivel — son las dos confusiones que llevan a copiar mal la arquitectura. Si diste por buena la 1, repasa 1.4: "eval interna" vs "benchmark externo" no es un matiz cosmético; decide cuánta confianza puedes poner en la cifra. Gate: necesitas la 1 y la 4 corregidas para superar este punto — el mismo núcleo que acabas de leer.

1.8Conecta

Acabas de construir el criterio de decisión, no de memorizar un debate. Esta lección ES la dimensión 1 de la rúbrica C4.

La rúbrica C4 abre con esto, verbatim:

"Decisión justificada — criterios documentados aplicados (paralelizable, read-heavy, excede ventana, valor); reconoce explícitamente un caso donde NO compensa."

· fuente: rúbrica C4 (03-arquitectura.md). Hoy practicaste las dos mitades: el veredicto con criterios y el caso donde no compensa. Sin las dos, esa dimensión no pasa.

Y ya tienes el mapa del territorio. Sabes que Anthropic y Cognition no se contradicen: dividen el espacio entre research read-heavy paralelizable y trabajo write-heavy acoplado. Sabes leer el 90,2% como eval interna, el "up to 90%" como cota, el ~15× como precio a evaluar. Y sabes nombrar los fallos con MAST, sin inventar frecuencias.

Falta la mecánica. Decidiste si aislar; aún no sabes qué compra el aislamiento cuando sí aplica. ¿Cómo es que un sub-agente, leyendo decenas de miles de tokens, te devuelve solo mil y aun así basta? Esa es la palanca que L2 abre.

Cierra el arco que abrimos en 1.1: tenías dos posts que parecían pelearse y un equipo que quería copiar al ganador. Ahora tienes una checklist que decide caso a caso, y la firmeza para decir "no" cuando el encargo no lo pide.

1.9Reflexiona

Tómate un minuto. Responder esto por escrito consolida lo aprendido mejor que releer.

¿Qué aprendiste? Resume en una frase por qué Anthropic y Cognition no se contradicen.
¿Qué sigue sin estar claro? ¿Tienes clara la diferencia entre read-heavy y write-heavy, y por qué decide el veredicto? Si no, vuelve a 1.4, a la síntesis del curso.
¿Qué harías distinto? La próxima vez que alguien proponga "partir el sistema en agentes porque [empresa famosa] lo hace", ¿qué cuatro preguntas le harías antes de aceptar?

Esto requiere práctica. La intuición de "este encargo sí, este no" llega aplicando la checklist a casos reales, no leyendo los posts. En L2 verás el mecanismo por el que un sub-agente compra contexto; en L3 lo orquestarás en LangGraph.