12 errores que vemos cometer a los equipos en su primer sistema ops multi-agente

Un sistema ops multi-agente es un flujo de trabajo en el que dos o más agentes LLM comparten estado y se reparten el trabajo hacia un único resultado de negocio, normalmente bajo un orquestador que mantiene el plan y asigna tareas a subagentes especializados. En la pizarra parece limpio. En producción se rompe de formas predecibles. Análisis recientes sitúan la tasa de fallo en producción de los sistemas LLM multi-agente entre el 41 y el 86,7 por ciento, y alrededor del 79 por ciento de esos fallos viene de especificaciones mal escritas y coordinación rota, no de la calidad del modelo (Augment Code, taxonomía MAST).

TL;DR. La mayoría de los equipos despliegan el orquestador antes que el eval harness, dan a los subagentes estado compartido en escritura, se saltan el verificador y descubren la factura de tokens un lunes por la mañana. La cura es aburrida: cada recurso tiene un dueño, el verificador es un agente distinto del orquestador, los reintentos y los tokens están limitados, y empiezas con dos agentes antes de escalar a diez.

1. Tratar al orquestador como un chatbot

El orquestador no es un asistente de chat con tools extra. Es un planner que tiene que registrar el plan, saber qué posee cada subagente y sobrevivir al agotamiento de tokens a mitad de run. Los equipos que se saltan ese paso escriben un prompt que suena como un system message amistoso y luego ven a los agentes divergir en la primera tarea larga. El equipo de investigación de Anthropic hace que el lead escriba el plan en memoria antes de despachar subagentes, precisamente para que el run sobreviva a un context reset (Anthropic Engineering).

2. Dejar a los subagentes estado compartido en escritura

Si dos agentes pueden escribir sobre la misma fila de base de datos, el mismo archivo o el mismo ticket de Linear, tienes un bug de concurrencia esperando una fecha límite. La regla que aguanta en producción es simple: cada recurso tiene un único dueño. Los agentes que necesitan coordinarse lo hacen mediante un message bus o una task queue, no mediante un registro mutable compartido. Los problemas de especificación y diseño suponen el 41,8 por ciento de los fallos multi-agente en la taxonomía MAST, y la ambigüedad de propiedad es la subcategoría mayor.

3. Saltarse el verificador, o hacer que coincida con el orquestador

Aproximadamente uno de cada cuatro fallos multi-agente ocurre porque el sistema no comprobó bien su propio trabajo, y la verificación incorrecta es el modo de fallo más común con un 9,1 por ciento. El verificador debe ser un agente aparte, con prompt distinto y, idealmente, clase de modelo distinta. Un orquestador que evalúa su propio plan acepta su propio output malo. Hemos visto equipos añadir el verificador solo tras el tercer post-mortem.

4. Ejecutar en síncrono cuando el trabajo paraleliza

La topología por defecto de los subagentes de Claude Code es síncrona. El lead espera a que cada lote de subagentes termine antes de despachar el siguiente. Anthropic lo señaló como un cuello de botella real y observó que el async desbloquearía más paralelismo al coste de una gestión de errores más dura. Si tus subagentes leen de fuentes independientes y nunca necesitan compararse a mitad de tarea, el coste del async merece la pena. Si sí lo necesitan, mantente síncrono y reduce el fan-out.

5. Sin presupuesto de tokens por tarea

La acumulación de tokens en un loop agéntico ingenuo es cuadrática, no lineal. Un loop de 20 pasos donde cada paso genera 1.000 tokens produce unos 210.000 tokens de entrada acumulados, porque toda la historia se reserializa en cada llamada (Augment Code). Se arregla con un chequeo de presupuesto previo a la ejecución y una compactación automática de contexto antes de que se llene la ventana. Sin eso, una sola tarea demasiado celosa un domingo por la noche puede gastar más de lo que un ingeniero senior se lleva a casa en una semana.

6. Sin techo de reintentos

El incidente más común en producción en los sistemas agénticos no es una respuesta equivocada. Es un agente que reintenta, y reintenta, y reintenta. Cada reintento es una llamada completa al proveedor. El contexto se duplica. Un contexto inicial de 4.000 tokens puede llegar a 128.000 en el paso 5, y el coste por paso ha subido 32 veces. En el paso 30 el loop se ha gastado más que el sueldo mensual de un ingeniero competente (TrueFoundry). Limita los reintentos a tres, registra el fallo, sal. Mejor escalar a un humano que desangrarse.

7. Forzar multi-agente sobre trabajo fuertemente acoplado

Anthropic fue directa. Los sistemas multi-agente brillan en problemas que se separan en hilos de investigación paralelos y son menos eficaces en tareas estrechamente interdependientes como el coding. Si en tu grafo de tareas cada nodo lee la salida del nodo anterior, no tienes un problema multi-agente, tienes una ejecución larga de un solo agente con checkpoints. La brecha de coste es real: una configuración multi-agente consume unas quince veces más tokens que un único chat para el mismo resultado.

8. Dejar a los agentes descubrir esquemas en runtime

La contaminación de datos es el modo de fallo externo más común en los sistemas multi-agente. La causa suele ser la misma: un agente llama a una API o consulta una tabla sin esquema estricto, recibe una forma que no entiende y o inventa campos o escribe basura aguas abajo. Entrega a cada agente su esquema en el prompt, valida payloads entrantes con Zod o Pydantic antes de razonar sobre ellos, y rechaza entradas que no parseen.

9. Registrar sólo las salidas finales

Si tus trazas capturan solo la respuesta final, no puedes depurar un fallo multi-agente. Necesitas el plan del orquestador, el prompt y la respuesta de cada subagente, cada tool call, el conteo de tokens por llamada y el veredicto del verificador. Cambios pequeños en los sistemas agénticos se propagan en grandes cambios de comportamiento, y depurar después de un incidente sin trazas a nivel de paso es adivinar. OpenTelemetry con atributos de span para nombre de agente y task ID es la configuración más barata que funciona.

10. Saltarse el eval harness antes de producción

Alrededor del 88 por ciento de los proyectos AI agent nunca llegan a producción, y la razón más frecuente no es la capacidad del modelo. Es que el equipo no tenía un set de evaluación offline, ni una suite de regresión, ni manera de saber si un cambio de prompt mejoraba o empeoraba las cosas. Construye un set de veinte tareas representativas antes de enviar. Ejecuta el loop multi-agente entero contra ellas en cada cambio de prompt o modelo. Sin eso, cada release es una moneda al aire.

11. Elegir la topología equivocada antes de tener telemetría

El panorama de frameworks en 2026 distingue tres modelos de orquestación dominantes: basados en grafo (LangGraph), basados en roles (CrewAI) y enjambres con handoff (OpenAI Agents SDK, Anthropic Agent Teams). Cada uno optimiza un fallo distinto. Los grafos hacen el estado explícito pero rígido. Los roles hacen la colaboración legible pero cara. Los enjambres minimizan el overhead pero hacen el estado difícil de recuperar. Elige la topología que encaje con tu patrón de fallo real, que solo conoces tras una semana de telemetría.

12. Esconder el coste dentro de un wrapper

El último error es organizativo. El equipo que construye el agente ve la latencia y la calidad del modelo. Finanzas ve una factura de 40.000 dólares el día uno del mes. Sin atribución de coste por agente, nadie puede responder a la siguiente pregunta obvia, que es si el agente se está pagando su propia factura. Etiqueta cada llamada al proveedor con un ID de agente, un ID de tarea y un ID de tenant, y empuja el gasto al mismo dashboard que el resto de la unit economics. Un agente que cuesta más de lo que ahorra es una funcionalidad esperando a ser apagada.

El patrón debajo de los doce

Relee la lista y se repite una forma. Los sistemas multi-agente fallan cuando el equipo los trata como chatbots más grandes en lugar de como sistemas distribuidos con un contador de tokens. La versión competente de este trabajo se parece más a una pequeña arquitectura de microservicios con cola que a una conversación de Claude, con presupuestos, fronteras de propiedad, verificadores, reintentos, suites de eval y trazas. El modelo es un componente. Los otros doce son el sistema.