Lección 5: Fallos y coordinación

Objetivos de aprendizaje:

• Explicar por qué no se puede tomar al pie de la letra a un subagente que dice estar «listo», y por qué necesitas una forma independiente de verificar
• Reconocer los dos fallos comunes en la colaboración multiagente: trabajo duplicado y resultados en conflicto
• En la etapa de integración de resultados, saber cómo deduplicar y cómo manejar salidas contradictorias

Requisitos: haber completado la Lección 4, ser capaz de distinguir los tres patrones de colaboración y el handoff | Anterior: Lección 4 << | Siguiente: Lección 6 >>

Dos subagentes investigan cada uno el plan inicial del mismo proveedor de nube. Uno reporta que arranca en $20 al mes, el otro dice $25 — y ambas salidas se marcan con confianza como «verificado, sin errores». Las lecciones anteriores cubrieron todas cómo montar una colaboración multiagente; esta cubre dónde se rompe después de haberla construido — no se puede confiar en el estado autorreportado de un subagente, trabajo duplicado, resultados en conflicto — y qué debería hacer el orquestador con cada caso.

Que un subagente diga «listo» no significa que lo haya hecho bien

Cuando un subagente devuelve un resultado, normalmente le añade una línea como «completo» o «verificado, sin errores». Esa afirmación no es evidencia — es solo el propio resumen que hace el subagente de su propia salida, y ese resumen puede estar equivocado. La observación oficial del comportamiento del agente es exactamente esta: "Claude stops when the work looks done. Without a check it can run, "looks done" is the only signal available, and you become the verification loop: every mistake waits for you to notice it."¹ Por eso el consejo oficial es "Have Claude show evidence rather than asserting success."¹

La documentación oficial llama a esto la brecha de confiar-entonces-verificar (trust-then-verify gap): "The trust-then-verify gap. Claude produces a plausible-looking implementation that doesn't handle edge cases. Fix: Always provide verification (tests, scripts, screenshots). If you can't verify it, don't ship it."¹ Ese consejo se escribió pensando en escribir código, pero la misma lógica aplica a cualquier delegación: lo que un subagente devuelve se lee con fluidez, tiene el formato correcto, parece hecho con cuidado — y todo eso es solo «de apariencia plausible», que no es lo mismo que ser realmente correcto. Si el orquestador toma la palabra a un subagente de que está «listo» y empalma la salida directamente en el resultado final, se ha saltado la verificación por completo.

Cómo verificar: fija un estándar comprobable para la salida de un subagente

«No tomarlo al pie de la letra» es fácil de decir; lo difícil es cómo verificar. Leerlo una vez y decidir que «se ve bien» no es verificación — eso sigue atascado en la primera mitad de la brecha de confiar-entonces-verificar. El enfoque fiable es definir primero un estándar concreto y comprobable, y luego medir la salida del subagente contra él.

Un estándar usado en un sistema de producción se ve así: "We used an LLM judge that evaluated each output against criteria in a rubric: factual accuracy (do claims match sources?), citation accuracy (do the cited sources match the claims?), completeness (are all requested aspects covered?), source quality (did it use primary sources over lower-quality secondary sources?), and tool efficiency (did it use the right tools a reasonable number of times?)."² Lo que comparten estos cinco criterios es que cada uno se puede comprobar de forma concreta, no puntuar por impresión. La exactitud factual se puede comprobar línea por línea contra las fuentes que el subagente citó; la completitud se puede comprobar contra cada requisito enumerado en la descripción de la tarea, para ver si todos quedaron cubiertos; la eficiencia de herramientas se puede leer directamente del registro de llamadas, para juzgar si hubo llamadas obviamente redundantes o duplicadas.

Llevando esto a tu propia configuración de colaboración, el primer paso para verificar la salida de un subagente no es preguntar «¿esto se ve bien?», sino preguntar «para esta tarea, ¿qué criterios puedo comprobar de forma concreta?» — enuméralos, y luego mide la salida contra cada uno.

Trabajo duplicado: varios subagentes haciendo lo mismo

La Lección 3 cubrió cómo una descripción de tarea que no es lo bastante detallada lleva a subagentes que "misinterpreted the task or performed the exact same searches as other agents."² Esa es la causa raíz, pero el fallo normalmente solo aflora en el momento en que se agregan los resultados — el orquestador recibe varias salidas de subagentes y descubre que dos de ellas se solapan fuertemente, cubriendo lo mismo con palabras distintas.

El trabajo duplicado no es un error catastrófico en sí mismo — el contenido no está mal, solo desperdicia los tokens y las llamadas que deberían haber cubierto otro ángulo. Pero es una señal: los límites de tarea de algunos subagentes no se trazaron con la suficiente claridad, y vale la pena volver a revisar las descripciones de tarea del paso de despacho, en lugar de solo deduplicar a mano este lote de resultados y darlo por hecho. Cuando detectes trabajo duplicado, en vez de solo borrar el contenido repetido, vale más averiguar por qué se repitió — si las dos descripciones de tarea se solapaban en alcance, o si los subagentes derivaron cada uno hacia la misma dirección, la más obvia.

Resultados en conflicto: dos subagentes llegan a conclusiones contradictorias

Más peliagudo que el trabajo duplicado es un conflicto de resultados — como la escena que abrió esta lección: dos subagentes investigan cada uno por su cuenta y devuelven conclusiones que se contradicen, uno diciendo que el plan inicial arranca en $20 al mes, el otro diciendo $25. No puedes lidiar con esto «simplemente eligiendo uno» o «partiendo la diferencia» — ambos enfoques arriesgan servir un número equivocado como conclusión final.

Cuando te topes con un conflicto de resultados, el orden sensato es: primero mira en qué basó cada lado su respuesta — ¿consultaron fuentes distintas, uno usando la página actual en vivo del proveedor y el otro usando por accidente una página vieja en caché?; si se puede rastrear la base, normalmente puedes decir cuál es más fiable y reemplazar el poco fiable; si la base en sí no puede zanjar quién tiene razón, no tomes tú la decisión durante la integración — marca la contradicción tal cual para revisión humana, o levanta un nuevo subagente específicamente para verificar ese punto de desacuerdo. El problema que expone un conflicto de resultados suele ser más preocupante que el trabajo duplicado — significa que al menos una salida de subagente está mal, y si la dejas caer en el resultado final sin manejarla, has empaquetado un error no verificado como una conclusión «lista».

Integración de resultados y deduplicación: qué hace el orquestador para cerrar

Coser varias salidas de subagentes en un resultado final no es cuestión de concatenarlas una tras otra — significa volver a recorrer las categorías de problema de arriba: ¿hay contenido duplicado que necesite fusionarse, hay conclusiones contradictorias que necesiten verificarse o marcarse, cada afirmación se remonta a una base correspondiente? Este último punto es especialmente fácil de pasar por alto — la Lección 3, «Escribir prompts para la delegación», mencionó que el sistema de producción montó un agente dedicado, descrito como "a CitationAgent, which processes the documents and research report to identify specific locations for citations. This ensures all claims are properly attributed to their sources."² La misma lógica se sostiene en la etapa de integración: una vez que varias salidas de subagentes se juntan en un pozo común, es fácil que haya una atribución errónea — apuntar como conclusión sobre la empresa de la que se encargaba el subagente B unos datos que encontró el subagente A. Verificar la atribución de fuente de cada afirmación en la etapa de integración importa tanto como verificar si los hechos en sí son exactos.

Deduplicar, verificar conflictos y comprobar la atribución de fuentes — esos tres juntos son el trabajo real del paso de «agregar», y no, como advirtió la Lección 2, solo concatenar las respuestas en bruto de los subagentes y darlo por hecho.

Resumen

• «Listo» o «verificado, sin errores» cuando un subagente devuelve algo es solo un autorreporte, no evidencia. Sin una comprobación que pueda ejecutar, «parece listo» es la única señal disponible¹; la documentación oficial es explícita en que Claude "produces a plausible-looking implementation that doesn't handle edge cases", y si no puedes verificarlo, no lo entregues.¹
• La verificación no puede quedarse en «se lee bien» — define criterios comprobables para la tarea específica, como la rúbrica con la que trabajó el LLM juez oficial, donde la exactitud factual, la exactitud de las citas, la completitud, la calidad de las fuentes y la eficiencia de herramientas se pueden comprobar cada una línea por línea.²
• El trabajo duplicado es una consecuencia común de límites de tarea que no se trazaron con claridad², que normalmente aflora solo cuando se agregan los resultados; detectar un duplicado no es solo borrar el contenido de más, vale la pena volver a revisar las descripciones de tarea del paso de despacho.
• Los resultados en conflicto — dos subagentes llegando a conclusiones contradictorias — no se pueden manejar eligiendo uno al azar ni partiendo la diferencia; verifica primero la credibilidad de la base de cada lado, y cuando no puedas ordenarlas, marca el conflicto tal cual para revisión humana.
• La etapa de integración hace tres cosas a la vez: deduplicar, verificar conflictos y comprobar si la atribución de fuente de cada afirmación está mal asignada² — ese es el trabajo real del paso de «agregar», y no solo concatenar las respuestas en bruto de los subagentes.

>> Lección 6: Práctica: Construir un pipeline de revisión de dos agentes