Sistemas multiagente de marketing: arquitectura, gobernanza y evaluación
Un sistema multiagente de marketing coordina dos o más componentes de IA o agentes acotados que desempeñan funciones distintas dentro de un flujo de trabajo definido, con un contexto compartido, traspasos explícitos, permisos, evaluación y derechos de decisión reservados a las personas. Un sistema multiagente no es necesariamente autónomo, y tampoco es siempre preferible a un único flujo de trabajo controlado. La arquitectura adecuada depende de si la complejidad añadida compensa de verdad su coste.
Resumen ejecutivo
Cada vez más equipos llaman «sistema multiagente» a cualquier cadena de prompts, o añaden agentes a un flujo de trabajo antes de definir el estado compartido, los permisos, el método de evaluación y la responsabilidad humana que esos agentes van a necesitar. El resultado es más complejidad sin que aumente la evidencia de valor adicional. Una arquitectura multiagente solo aporta valor cuando la separación de funciones genera un beneficio operativo medible y superior al coste de coordinación, evaluación, seguridad y mantenimiento que introduce. Esta guía explica cuándo se justifican de verdad varios agentes y cuándo rinde mejor un único flujo de trabajo controlado, qué patrones de arquitectura son habituales, cómo funciona el Agent Contract que rige a cada agente acotado y cómo deben escalar la evaluación, la observabilidad y las puertas de decisión humanas a medida que crece la complejidad del sistema.
Ideas clave:
- No toda cadena de pasos asistidos por IA es un sistema multiagente, y no toda tarea se beneficia de convertirse en uno.
- Una arquitectura multiagente solo se justifica cuando la especialización genera un beneficio medible que supera su coste de coordinación y mantenimiento.
- Cada agente de un sistema acotado opera bajo un Agent Contract, el mismo instrumento de gobernanza que kōdōkalabs emplea para las tareas individuales asistidas por IA en el Agentic Drafting, aplicado aquí al nivel de cada componente.
- La evaluación debe hacerse tanto en cada agente como en el sistema completo. Un sistema puede fallar aunque todos sus componentes superen su propia prueba.
- Más agentes y más autonomía no son mejores por sí mismos. La arquitectura correcta es la que responde a las necesidades reales de la tarea.
¿Qué es un sistema multiagente de marketing?
Un sistema multiagente de marketing es un flujo de trabajo definido en el que dos o más componentes de IA acotados, cada uno con una función propia, se coordinan mediante un contexto compartido, traspasos explícitos y permisos definidos para producir un resultado, con derechos de decisión humanos integrados en los puntos adecuados y no dados por supuestos. La palabra «acotado» importa: cada agente tiene un ámbito concreto y limitado de responsabilidades, herramientas y autoridad, en lugar de un mandato abierto para hacer todo lo que parezca útil.
Sistema multiagente, automatización de flujos y sistema de un solo agente
Estos tres enfoques suelen confundirse, pero son arquitecturas realmente distintas, con ventajas e inconvenientes diferentes.
| Enfoque | Descripción | Más adecuado para |
|---|---|---|
| Automatización de flujos de trabajo | Una secuencia definida de pasos, algunos automatizados, sin decisiones independientes de la IA en cada fase | Procesos previsibles y bien estandarizados |
| Sistema de un solo agente | Un único componente de IA que resuelve una tarea de principio a fin, posiblemente con varias herramientas | Tareas que no se benefician de una especialización por funciones |
| Sistema multiagente | Varios componentes de IA especializados y acotados que se coordinan en una tarea compartida | Tareas en las que las funciones especializadas distintas aportan un valor real |
Un sistema no se vuelve «multiagente» solo porque llame a un modelo más de una vez en secuencia. Eso suele ser simplemente un flujo de trabajo de un solo agente con varios pasos. La diferencia relevante está en si el sistema tiene funciones realmente distintas y acotadas, cada una con su propio contrato, sus herramientas y su evaluación, que se coordinan entre sí.
Cuándo se justifican varios agentes
El Agent Architecture Decision Test de kōdōkalabs evalúa, a partir de ocho factores, si un enfoque multiagente está realmente justificado para una tarea concreta.
| Factor | Qué evalúa |
|---|---|
| Separabilidad de la tarea | Si la tarea se divide de forma natural en subtareas distintas e independientes |
| Beneficio de la especialización | Si un agente especializado rinde de verdad mejor que uno generalista en su subtarea |
| Límites de las herramientas (en inglés) | Si las distintas subtareas requieren acceso a herramientas diferentes y separables |
| Tamaño del contexto | Si el contexto completo de la tarea desbordaría el contexto de trabajo efectivo de un solo agente |
| Paralelismo | Si las subtareas pueden ejecutarse de forma simultánea y no solo en secuencia |
| Evaluación independiente | Si el resultado de cada subtarea puede evaluarse por sus propios méritos |
| Aislamiento de fallos | Si aislar el fallo de una subtarea evita que contamine todo el sistema |
| Coste de mantenimiento | Si el beneficio compensa el coste continuo de mantener varios componentes coordinados |
Una tarea que puntúa bien en la mayoría de estos factores es una candidata razonable para un enfoque multiagente. Una tarea que puntúa mal en casi todos (por ejemplo, una que no se divide de forma natural, no se beneficia de la especialización y no necesita paralelismo) probablemente se resuelve mejor con un único flujo de trabajo bien diseñado.
Conviene aplicar este test de forma explícita y no fiarse de la intuición, porque la intuición suele apuntar en la dirección equivocada. Una tarea que parece lo bastante compleja como para «necesitar» varios agentes resulta con frecuencia, al examinarla con más detalle, una única tarea compleja que un solo flujo de trabajo bien especificado puede resolver en secuencia: que la tarea sea compleja no implica automáticamente que repartirla entre varios agentes acotados sea la respuesta correcta a esa complejidad. El test existe precisamente para separar «esta tarea es difícil» de «esta tarea tiene funciones realmente separables que se benefician de la especialización», dos propiedades distintas que se confunden con sorprendente frecuencia.
Cuándo es mejor un único flujo de trabajo controlado
El error de arquitectura multiagente más habitual en marketing es añadir agentes a una tarea que se serviría mejor con un único flujo de trabajo bien especificado y con fases claras. Los sistemas multiagente introducen una carga real de coordinación: hay que gestionar el estado compartido, diseñar y probar los traspasos, acotar los permisos de cada agente y evaluar en varios niveles. Para una tarea bien estandarizada, que no requiere funciones especializadas realmente distintas ni ejecución en paralelo, esa carga es puro coste sin beneficio alguno. Un único flujo de trabajo controlado, que puede seguir contando con ayuda de la IA, es más sencillo de construir, más fácil de mantener y más fácil de entender cuando algo sale mal.
Hay además un coste menos evidente que conviene nombrar: la complejidad organizativa. Un sistema multiagente suele requerir que más personas lo entiendan y lo mantengan con el tiempo: alguien tiene que responsabilizarse del contrato de cada agente, alguien tiene que interpretar los resultados de la evaluación entre agentes y alguien tiene que poder razonar sobre cómo un cambio en un agente puede repercutir en los demás. Un único flujo de trabajo, en cambio, suele poder ser entendido, mantenido y mejorado por una sola persona competente. Los equipos que valoran si construir un sistema multiagente deberían sopesar no solo el coste técnico de coordinación que describe el test de decisión, sino también este coste organizativo: haber creado algo que ahora exige más conocimiento institucional especializado para seguir funcionando bien.
Patrones habituales de arquitectura multiagente
Unos pocos patrones recurrentes cubren la mayoría de los casos de uso multiagente legítimos en marketing.
| Patrón | Descripción |
|---|---|
| Cadena secuencial | Los agentes operan uno tras otro y cada uno se apoya en el resultado del anterior |
| Enrutador y especialistas | Un agente enrutador clasifica la tarea y la dirige al agente especialista adecuado |
| Planificador y ejecutor | Un agente planificador divide la tarea en pasos; uno o varios agentes ejecutores los llevan a cabo |
| Investigador, redactor y revisor | Agentes distintos se ocupan de la investigación, la redacción y la revisión como funciones separables |
| Especialistas en paralelo con síntesis | Varios agentes trabajan a la vez en distintos aspectos; un paso de síntesis combina sus resultados |
| Bucle de evaluación | Un agente evaluador comprueba el resultado de otro agente y pide una revisión si no cumple los criterios |
La elección del patrón debe derivarse directamente de lo que arroje el Agent Architecture Decision Test. Una tarea con mucho potencial de paralelismo encaja con el patrón de especialistas en paralelo; una tarea que exige un refinamiento progresivo encaja con el bucle de evaluación.
El Agent Contract
Cada agente de un sistema multiagente acotado opera bajo un Agent Contract, el mismo instrumento de gobernanza que kōdōkalabs define de forma canónica en su página de la metodología Agentic Drafting, aplicado aquí al nivel de un agente concreto dentro de una arquitectura mayor y no al de una tarea de redacción individual. En lugar de definir un concepto distinto y rival, esta página usa los mismos campos: finalidad, entradas permitidas y prohibidas, herramientas y permisos, fuentes obligatorias, esquema de salida, reglas de validación, señalización de la confianza y de la incertidumbre, comportamiento ante fallos y escalado (incluidos los límites de reintentos y las condiciones de parada), reglas de traspaso al siguiente agente de la secuencia, una persona responsable con nombre y apellidos, versión y requisitos de registro.
Aplicar un único Agent Contract coherente tanto a la redacción individual asistida por IA como a las arquitecturas multiagente tiene una ventaja práctica que va más allá de la coherencia: la disciplina de gobernanza que un equipo desarrolla en un contexto se traslada directamente al otro, sin tener que aprender y mantener dos sistemas paralelos de reglas.
Conocimiento compartido, estado y memoria
Los sistemas multiagente necesitan una forma definida de decidir qué contexto se comparte entre agentes y qué queda reservado a un único agente. Un agente con acceso sin restricciones a todo lo que han producido los demás pierde las ventajas de aislamiento que justificaban separar las funciones, mientras que un agente con muy poco contexto compartido puede duplicar trabajo o contradecir una decisión que otro agente ya tomó. El estado compartido debe nutrirse de la base de conocimiento de marketing con IA gobernada de la organización y no de un mecanismo ad hoc propio del sistema multiagente, de modo que se apliquen de forma coherente las mismas reglas de autoridad y actualidad.
Acceso a herramientas y límites de permisos
Cada agente debe tener acceso únicamente a las herramientas que requiere su función concreta. Un agente de investigación no necesita permisos de publicación; un agente de redacción no necesita poder modificar sistemas de producción. Acotar los permisos de cada agente, en lugar de conceder por comodidad un conjunto amplio de permisos a todos, limita el daño que puede causar el fallo o la manipulación de un solo agente y hace que el comportamiento del sistema sea más fácil de entender durante la revisión.
Traspasos, esquemas de salida y condiciones de terminación
Un traspaso entre agentes necesita un esquema de salida definido, es decir, qué espera recibir exactamente el agente receptor, para que la información no se degrade ni se malinterprete al pasar de un componente a otro. Las condiciones de terminación fijan cuándo debe detenerse el sistema: una finalización correcta, un estado de fallo definido o un límite de reintentos alcanzado sin éxito. Un sistema multiagente sin condiciones de terminación claras corre el riesgo de entrar en un bucle indefinido o de pasar un resultado incompleto como si estuviera terminado.
Puertas de decisión humanas
Los sistemas multiagente no eliminan la necesidad de las puertas de decisión humanas que se describen en Human-in-the-Loop AI. Al contrario: la complejidad añadida de una arquitectura multiagente hace más importante, no menos, colocar las puertas humanas con criterio. Una puerta después del paso final de síntesis, antes de que cualquier resultado de consecuencias importantes siga adelante, sigue siendo esencial por muchos agentes especializados que hayan contribuido a producirlo.
Evaluación en el nivel del agente y del sistema
Evaluar únicamente el resultado final de un sistema multiagente deja pasar los fallos que ocurren a mitad del proceso. Un agente que produce de vez en cuando un resultado con un defecto sutil puede propagarlo a través de varios agentes posteriores antes de que aflore de un modo que la evaluación final detecte, y para entonces resulta mucho más difícil diagnosticar el origen real del problema. Una evaluación eficaz se hace en los dos niveles: cada agente se evalúa con las reglas de validación de su propio Agent Contract, y el sistema en su conjunto se evalúa con los criterios de éxito de la tarea de principio a fin. Un sistema que supera la evaluación de extremo a extremo mientras un agente rinde por debajo de lo esperado sin que nadie lo note es frágil. Lo más probable es que falle de forma más visible la próxima vez que cambien un poco las condiciones.
Observabilidad, registros e investigación de incidentes
Los sistemas multiagente necesitan registros lo bastante detallados como para reconstruir qué hizo cada agente, en qué orden y con qué entradas y salidas, de modo que, cuando algo falle, la investigación pueda identificar qué agente concreto y qué paso concreto introdujo el problema, y no solo constatar que el resultado final era defectuoso. Esta exigencia de observabilidad crece con el número de agentes: depurar un sistema de cinco agentes sin registros por agente es bastante más difícil que depurar un flujo de un solo agente con la misma carencia, simplemente porque hay más lugares donde puede haberse originado el problema.
Compromisos entre coste, latencia, fiabilidad y mantenimiento
Las arquitecturas multiagente suelen costar más de operar que un único flujo de trabajo bien diseñado: más llamadas al modelo, más carga de coordinación y, a menudo, mayor latencia, porque los agentes se pasan el trabajo de forma secuencial en lugar de resolver la tarea de una sola vez. La fiabilidad puede mejorar gracias al aislamiento de fallos (el fallo de un agente no tiene por qué tumbar todo el sistema) o empeorar por la mayor complejidad (más componentes significan más puntos de fallo posibles). El coste de mantenimiento crece con el número de agentes, porque cada uno necesita su propio contrato, sus pruebas y su revalidación periódica. Estos compromisos deben sopesarse de forma explícita frente a la valoración del beneficio de la especialización que hace el Agent Architecture Decision Test: el coste añadido solo merece la pena cuando el beneficio es real y medible.
Ejemplos de casos de uso en marketing
Investigación y briefing
Un agente investigador reúne y valida el material de origen; un agente de briefing lo sintetiza en un briefing estructurado para la revisión humana. Son funciones separables y con necesidades de herramientas realmente distintas (búsqueda y recuperación frente a redacción estructurada).
Producción de contenido
Un agente de planificación estructura una pieza de contenido; un agente de redacción produce el texto; un agente de verificación de datos contrasta las afirmaciones con el Claim Register descrito en Agentic Drafting. Son funciones especializadas distintas, con criterios de evaluación independientes.
Search intelligence
Un agente de investigación de entidades reúne datos estructurados sobre un tema; un agente de análisis identifica patrones o lagunas frente a la competencia. Son funciones que se benefician de la ejecución en paralelo sobre muchos temas a la vez.
Operaciones de campaña
Un agente de planificación gestiona la logística y los plazos; un agente de comprobación de cumplimiento revisa los resultados frente a las restricciones aprobadas antes de que se publiquen. Son funciones separables tanto por el acceso a herramientas como por el perfil de riesgo de lo que cada una debe detectar.
Reporting y análisis
Un agente de recuperación de datos reúne las cifras de rendimiento de los sistemas de referencia; un agente narrativo convierte las cifras validadas en un resumen escrito. Es una división natural entre el tratamiento de datos estructurados y la generación de prosa.
No todos estos casos de uso requieren una arquitectura multiagente en todas las organizaciones. Las mismas tareas pueden resolverse a menudo muy bien con un único flujo de trabajo bien diseñado, sobre todo con un volumen o una complejidad menores. Son ilustraciones de dónde suele aportar valor real la separación de funciones, no una prescripción de que todo equipo de marketing necesite un sistema multiagente para cada una de ellas.
Preparación para el piloto y la producción
Antes de que un sistema multiagente avance hacia el uso en producción, debe pasar por un Pilot Review con casos de prueba diseñados específicamente para poner a prueba los modos de fallo propios de los sistemas multiagente: qué ocurre cuando un agente produce un resultado mal formado del que depende otro, qué ocurre cuando un traspaso falla a medias y si la observabilidad del sistema basta para diagnosticar un fallo a posteriori. Un sistema multiagente que funciona bien en una demostración limpia pero no se ha probado en estas condiciones no está validado de forma significativa para la producción.
Modos de fallo habituales
- Complejidad sin justificación: construir un sistema multiagente para una tarea que un único flujo de trabajo controlado resolvería igual de bien y a menor coste.
- Ámbito del agente sin límites: un agente con un mandato abierto, en lugar de un contrato definido que limite su finalidad y sus herramientas.
- Exceso de contexto compartido: todos los agentes con acceso a todo, con lo que desaparecen las ventajas de aislamiento que debía aportar la separación de funciones.
- Sin condiciones de terminación: un sistema que puede entrar en bucle o pasar un resultado incompleto sin un punto de parada definido.
- Evaluación solo del resultado final: comprobar únicamente el resultado final y pasar por alto los fallos a mitad del proceso, que acaban aflorando de forma imprevisible.
- Observabilidad insuficiente: registros demasiado toscos para identificar qué agente o qué paso causó un problema concreto.
- Suponer que más agentes equivalen a más fiabilidad: tratar la especialización añadida como más segura por naturaleza, sin evidencia de que reduzca realmente la tasa de fallos en la tarea concreta.
Lista de comprobación de la arquitectura
Antes de construir un sistema multiagente de marketing, confirme que: el Agent Architecture Decision Test respalda de verdad un enfoque multiagente frente a un único flujo de trabajo; cada agente tiene un Agent Contract completo; el conocimiento y el estado compartidos proceden de la base de conocimiento gobernada; el acceso a herramientas está acotado con rigor por agente; los traspasos tienen esquemas de salida definidos; las condiciones de terminación son explícitas; las puertas de decisión humanas están bien colocadas; la evaluación se hace tanto en el agente como en el sistema; la observabilidad permite investigar incidentes; y el sistema ha superado un Pilot Review frente a condiciones de fallo propias de los sistemas multiagente.
Preguntas frecuentes
¿Cuándo conviene usar varios agentes de IA en lugar de un único flujo de trabajo?
Solo cuando los factores del Agent Architecture Decision Test (separabilidad de la tarea, beneficio de la especialización, límites de las herramientas, tamaño del contexto, paralelismo, evaluación independiente, aislamiento de fallos y coste de mantenimiento) lo respaldan de verdad. Muchas tareas se resuelven mejor con un único flujo de trabajo controlado y bien diseñado.
¿Qué diferencia hay entre un sistema multiagente y un flujo de trabajo automatizado de varios pasos?
Un sistema multiagente tiene funciones realmente distintas y acotadas, con sus propios contratos, herramientas y evaluación, que se coordinan entre sí. Un flujo de varios pasos que llama a un modelo repetidamente en secuencia, sin esa separación, no es lo mismo, aunque se le parezca a primera vista.
¿Más agentes mejoran la fiabilidad o la calidad?
No de forma automática: los agentes adicionales introducen carga de coordinación y más puntos de fallo posibles. La fiabilidad mejora solo cuando la separación de funciones y el aislamiento de fallos están realmente bien diseñados, no por el simple hecho de que haya más agentes.
¿Qué patrones de arquitectura multiagente puede elegir?
Cadena secuencial, enrutador y especialistas, planificador y ejecutor, investigador, redactor y revisor, especialistas en paralelo con síntesis y bucle de evaluación. Véase la tabla de patrones más arriba.
¿Qué es un Agent Contract?
Una especificación de gobernanza que define la finalidad de un agente acotado, sus entradas permitidas, sus herramientas, su esquema de salida, sus reglas de validación, su comportamiento ante fallos y su responsable humano. Es el mismo instrumento que kōdōkalabs usa para las tareas individuales asistidas por IA en Agentic Drafting, aplicado aquí a cada agente.
¿Cómo se gestionan el conocimiento y el estado compartidos entre agentes?
Nutriéndolos de la base de conocimiento gobernada de la organización y no de un mecanismo ad hoc, y decidiendo de forma deliberada qué se comparte y qué es propio de cada agente, en lugar de dar por defecto visibilidad total a todos.
¿Cómo se evalúa un sistema multiagente?
En los dos niveles: en cada agente, frente a su propio Agent Contract, y en el sistema completo, frente a los criterios de éxito de la tarea de principio a fin. Evaluar solo el resultado final puede dejar pasar los fallos que ocurren a mitad del proceso.
¿Qué observabilidad necesita su sistema multiagente?
Registros lo bastante detallados como para reconstruir qué hizo cada agente, en qué orden y con qué entradas y salidas, y que basten para identificar el origen concreto de un fallo y no solo para saber que ha habido uno.
¿Qué conviene probar antes de que un sistema multiagente pase a producción?
Las condiciones de fallo propias de los sistemas multiagente mediante un Pilot Review: traspasos mal formados, fallos parciales a mitad del proceso y si la observabilidad permite de verdad diagnosticar un problema a posteriori.
¿Es siempre mejor dar más autonomía a los agentes?
No. La autonomía solo debe aumentar a medida que la evidencia demuestre que el sistema, sus controles y su evaluación pueden sostenerla con fiabilidad: el mismo principio basado en la evidencia que rige la madurez de la automatización en general.
Conclusión
La arquitectura multiagente es una herramienta potente para tareas de marketing especializadas y realmente separables, y una complicación costosa para las que no la necesitan. La disciplina que describe esta guía, desde el Agent Architecture Decision Test hasta el Agent Contract compartido, es lo que distingue a un sistema multiagente que se gana su complejidad de uno que simplemente la añade.