Organizaciones multiagente: cuando un agente no alcanza

Si buscas «sistemas multiagente» en Google, verás en los primeros resultados artículos académicos, frameworks y guías introductorias. Poca receta concreta para coordinar agentes distintos en un entorno productivo. Mucho menos evidencia trazable de cómo evitar que se pisen, derrochen tokens o pierdan el objetivo.

Ese hueco se nota cuando un solo agente empieza a fallar. Al principio responde, pero se empantana en tareas largas, repite trabajo y mezcla estilos. No prioriza. No sabe cuándo pedir ayuda ni cuándo parar. Entra en bucles.

Ahí uso organizaciones multiagente. No para «jugar» a tener roles, sino para asignar responsabilidades, contratos y límites. La coordinación importa más que el tamaño del modelo.

Qué es una organización multiagente práctica

Hablo de varios agentes especializados que colaboran bajo una meta común. Cada uno tiene un alcance claro, insumos bien definidos y salidas validadas. No es decorar con títulos. Es diseñar interfaces entre agentes: qué reciben, qué producen y cuándo ceden el turno.

El corazón es la orquestación. Un agente no debe «saber de todo». Debe saber cuándo tomar una decisión y cuándo pasar el testigo. Un planner define el plan, un ejecutor opera herramientas, un crítico audita resultados y un integrador entrega una salida unificada. Los nombres dan igual. Importan los límites.

También importan las reglas de parada. Cada agente tiene un presupuesto de pasos y tokens. Si no llega a un resultado aceptable, devuelve un fallo estructurado. Otro agente decide si reintenta, simplifica o eleva el caso.

Cuándo un agente no alcanza

Lo veo en cuatro situaciones.

Largo aliento. Tareas con varios días de vida, muchas dependencias y entregables intermedios. Un único agente olvida contexto útil, mezcla versiones y no consolida.

Herramientas diversas. Integraciones con varias API, documentos extensos y datos ruidosos. Un solo agente tiende a tocarlo todo y termina haciendo de todo y nada bien.

Control y trazabilidad. Necesitas explicar por qué eligió A y no B. Con un único flujo, la decisión se diluye. Con roles separados, cada paso deja un rastro auditable.

Riesgo y compliance. Hay que filtrar, anonimizar y validar. Separar al que busca del que publica reduce superficie de error y de fuga de datos.

En un escenario, un equipo que dedica veinte horas al mes a revisiones manuales puede reducir ese esfuerzo si el crítico automatizado detecta incoherencias y arma resúmenes de verificación. No hay magia. Hay estructura.

Orquestación: contratos, memoria y control de calidad

Empiezo por los contratos. Cada agente habla en un formato que el siguiente entiende. No improviso campos. Defino qué es «hecho», «suposición», «cita» y «requisito». Cuando el ejecutor no puede verificar, lo marca. El crítico no inventa. Señala huecos y pide más datos.

La memoria se divide en tres capas. Una breve y efímera para el turno actual. Una de trabajo para el hilo del caso. Y una documental para lo que merece persistir. El criterio de persistencia lo toma un agente custodio, no cualquiera que pase por ahí.

El control de calidad no es una pasada final. Es una función con autoridad para bloquear entregas. Evalúa contra criterios formales, no contra «me gusta». Si falta evidencia, devuelve el paquete al buscador. Si sobra palabrería, pide síntesis.

Coste, latencia y presupuesto

Más agentes no significa más coste por defecto. Significa coste visible. Al dividir tareas, ves dónde se quema el tiempo y los tokens. Eso permite ajustar con precisión.

En un escenario, pasar de un agente a tres eleva la latencia de extremo a extremo dos o tres veces si no hay paralelización. Cuando paralelizas lo que no depende, recuperas parte del tiempo. El equilibrio lo da el flujo: primero claridad, luego velocidad.

El presupuesto se pone por agente y por caso. Límite de pasos, límite de llamadas y límite de tokens. Si el plan supera el presupuesto, el planner recorta alcance o propone fases. Prefiero un «no llego con este presupuesto» explícito antes que un «lo intenté» opaco.

Empezar pequeño y crecer con criterio

Arranco con un vertical estrecho y una métrica de éxito operativa. No prometo «resolver todo el proceso». Prometo mover una aguja medible. Con eso, diseño dos o tres roles que se necesiten de verdad y un conjunto de pruebas que cubra los casos críticos.

Si la función es comercial, separo investigación, redacción y validación. En ese punto encaja un enfoque de agentes de IA para vender que aísla la prospección de la negociación y del seguimiento. Cada paso exige datos y criterios distintos. La orquestación evita que el mismo agente cambie de voz y de objetivos sin aviso.

Cuando el bucle básico rinde, meto paralelización segura. Investigo varias fuentes a la vez, pero integro con un único criterio. Los conflictos no se esconden. Se elevan y se resuelven con reglas claras.

Señales de que el diseño va bien

La conversación entre agentes se hace más corta y más informativa. Hay menos vueltas vacías. Las salidas mantienen estilo y estructura. Si pido rehacer una parte, el sistema no destruye lo que estaba bien.

Otra señal: el diario de decisiones se puede leer. Puedo seguir el hilo desde la meta hasta cada evidencia. Si otro operador toma el relevo, entiende rápido qué falta y por qué.

También se nota en los fallos. Cuando algo cae, cae con explicación. No aparezco con un «error desconocido». El sistema dice qué intentó, dónde se trabó y qué propone como siguiente paso.

Riesgos y mitigación

Los agentes se pueden influir mal entre sí. La «infección por prompt» no es solo web. Un agente podría pasarle a otro una instrucción engañosa. Lo corto con saneamiento de mensajes y con validadores que no obedecen órdenes fuera de protocolo.

Otro riesgo es el eco. Si todos los agentes usan la misma fuente, refuerzan una suposición equivocada. Por eso marco diversidad de fuentes y pido contradicciones explícitas. El integrador arbitra y documenta el criterio.

También está el abuso de herramientas. Un ejecutor con permisos amplios puede dejar credenciales expuestas o sobreconsultar. Limito ámbitos, firmo cada acción y registro trazas. Si hay dudas, puedo reproducir el paso.

Por último, el desalineamiento. Si la meta cambia y nadie actualiza el plan, los agentes siguen un norte viejo. Mantengo un artefacto de objetivo vivo y con versión. El planner lo consulta antes de cada ciclo.

Por qué vale la pena

Un solo agente rinde para tareas cortas y con poca variabilidad. Cuando la realidad se complica, los sistemas multiagente ordenan el trabajo, exponen los trade-offs y sostienen la calidad. No es una moda. Es ingeniería de procesos aplicada a modelos generativos.

La clave no está en el número de agentes, sino en su coordinación. Roles claros, contratos simples, memoria con criterio y evaluaciones que importan. Con eso, escalar deja de ser improvisación y pasa a ser diseño.

Publico automatizaciones funcionando en @WhatsMarketing_es.

Si quieres que mire tu caso, escríbeme. Trabajo desde Buenos Aires, siendo malagueño, con clientes en Ciudad de México, Argentina, el resto de Latinoamérica y España.