Imagina esta propuesta en una reunión de arquitectura. Un banco quiere automatizar la revisión de expedientes de crédito. Alguien dibuja en la pizarra siete agentes: uno que lee documentos, otro que valida datos, otro que evalúa riesgo, un «supervisor», un «crítico», un «redactor» y un «coordinador de coordinadores». Todo suena moderno. Nadie ha preguntado si una sola llamada bien diseñada con tres herramientas haría lo mismo.
Este es un terreno clásico del examen CCAR-P. Las opciones multiagente suelen aparecer como la respuesta «potente», y a menudo son la trampa. Tu trabajo es saber cuándo repartir el trabajo compensa, cómo hacerlo sin que el sistema se vuelva inmanejable y cuándo decir que no. Como en la lección anterior, el criterio es la restricción dominante y los trade-offs. Para la lista oficial de dominios y pesos, usa el Exam Guide.
Antes de repartir: la escalera de complejidad
Un sistema multiagente es el último peldaño, no el primero. La pregunta correcta no es «¿cuántos agentes necesito?», sino «¿cuál es el diseño más simple que cumple el requisito?».
Prompt claro, contexto adecuado y salida estructurada. Muchas tareas de clasificación, extracción o redacción terminan aquí.
Cada peldaño añade flexibilidad, pero resta previsibilidad, facilidad de prueba y control del coste. Si las pasos son conocidos, un flujo fijo gana a un agente que «ya los descubrirá». Si un agente con buenas herramientas rinde bien, un segundo agente no es una mejora automática.
Cuándo SÍ compensa repartir el trabajo
El multiagente se justifica cuando hay un problema concreto que un solo agente no resuelve bien. Las razones legítimas son pocas:
- Contexto que se desborda o se diluye. Si una tarea necesita explorar mucho material (muchos documentos, muchos resultados de búsqueda), un subagente puede hacer ese trabajo en su propia ventana y devolver solo un resumen. El agente principal conserva el contexto limpio.
- Trabajo paralelizable e independiente. Investigar cinco proveedores a la vez, revisar módulos sin dependencias entre sí. Si las subtareas no se necesitan unas a otras, el paralelismo reduce latencia.
- Especialización real. Herramientas, permisos o instrucciones muy distintos por rol. Dar a un solo agente cuarenta herramientas empeora su elección; repartirlas por especialidad puede mejorarla.
- Aislamiento por seguridad. Un agente que lee contenido no confiable (web, correos) no debería tener las mismas herramientas que uno que ejecuta acciones sensibles.
- Verificación independiente. Un segundo agente que revisa con contexto limpio puede detectar errores que el primero, sesgado por su propio razonamiento, no ve.
Fíjate en que ninguna razón es «porque queda más profesional». Cada una responde a una restricción medible.
Coordinación: quién manda y qué se pasan
Una vez decidido el reparto, el diseño de la coordinación decide si funciona. Hay dos patrones habituales.
Orquestador y subagentes
Un agente central delega y consolida
- Control claro: un único punto de decisión
- Los subagentes reciben una tarea acotada y devuelven un resultado
- Más fácil de trazar, de limitar y de depurar
- El orquestador puede ser cuello de botella y su contexto crece con los resultados
Agentes pares que se comunican
Sin jefe, intercambio directo
- Más flexible para tareas abiertas
- Difícil saber quién decidió qué
- Riesgo de bucles, duplicación y deriva
- Depurar y evaluar exige mucho más esfuerzo
Si el escenario pide trazabilidad, control o cumplimiento, el orquestador suele encajar mejor. La libertad entre pares cuesta previsibilidad.
Tres reglas de diseño que el examen premia:
- Delega con contexto explícito. Un subagente no hereda lo que sabe el orquestador. Si la tarea no incluye objetivo, formato esperado y límites, el subagente improvisa. Los fallos de coordinación suelen ser fallos de instrucciones.
- Devuelve resultados compactos y estructurados. Pasar de vuelta toda la conversación del subagente anula la ventaja del aislamiento. Pasa conclusiones, no rastros.
- Define cuándo termina. Sin criterio de parada claro, los agentes siguen buscando, revisando y reintentando. Eso se traduce en coste y latencia.
Memoria y estado compartido
Los agentes no comparten memoria por arte de magia: cada uno tiene su ventana de contexto. Lo que «saben en común» es lo que tú diseñes. Las opciones principales son pasar información en los mensajes de delegación y resultados, o apoyarse en un almacén externo (base de datos, archivos, un servidor MCP) que los agentes consultan y actualizan mediante herramientas.
MSG · Pasar por mensajes
El orquestador incluye en cada delegación lo que el subagente necesita. Simple y explícito, pero hay que seleccionar con cuidado: pasar de más gasta contexto y pasar de menos provoca respuestas sin base.
Pulsa cada casilla. No hay una ganadora universal: depende de qué tenga que sobrevivir y quién lo necesite.
Dos riesgos que el examen suele plantear: escrituras concurrentes (dos agentes actualizan el mismo registro y uno pisa al otro) y estado obsoleto (un agente decide con datos que otro ya cambió). La respuesta de arquitectura es dar a cada dato un dueño claro y evitar que varios agentes escriban el mismo sitio sin control.
Tolerancia a fallos y límites
En un sistema con varias piezas, los errores se multiplican. Si cada paso acierta el 95 % de las veces, una cadena larga acierta bastante menos. El diseño debe asumir que algo fallará.
Prácticas de diseño que debes reconocer:
- Validar en cada frontera. Salidas estructuradas y comprobaciones de tu código antes de pasar un resultado al siguiente agente.
- Reintentos acotados. Reintentar ante errores transitorios sí; reintentar en bucle una tarea que falla por una causa de fondo solo gasta dinero. Pon un máximo.
- Degradación elegante. Si un subagente falla, el sistema debería poder continuar con un resultado parcial indicado como tal, o escalar a una persona, en lugar de inventar o abortar todo.
- Límites duros. Máximo de iteraciones, de llamadas a herramientas y de presupuesto por tarea. Un agente sin tope es un riesgo de coste.
- Persistir el progreso. En tareas largas, guardar el estado permite reanudar tras un fallo sin repetir todo el trabajo.
- Humano en el bucle en acciones irreversibles o de alto impacto: pagos, borrados, envíos externos.
- Trazabilidad. Registrar qué agente hizo qué, con qué entrada y qué salida. Sin trazas, un fallo intermitente es casi imposible de diagnosticar.
Y un límite de seguridad: los permisos se asignan por agente y con el mínimo necesario. Un subagente que solo investiga no necesita poder escribir en sistemas de producción.
Comprobación a mitad de lección
Una aseguradora quiere resumir cada noche pólizas con un formato idéntico: extraer cinco campos, validarlos con reglas conocidas y generar un resumen. El equipo propone un orquestador con cuatro subagentes especializados. Hay presión por reducir coste y por poder auditar cada resultado. ¿Qué diseño es más adecuado?
Anti-patrones: lo que el examen quiere que detectes
Estos son los errores de diseño que más aparecen disfrazados de buenas ideas.
Agentes por moda
Dividir en agentes lo que es un flujo fijo o una sola llamada. Multiplica coste, latencia y fallos sin ganar nada medible. Suele ser la opción trampa más sofisticada.
Delegación sin contexto
Mandar a un subagente una orden vaga y esperar que adivine el objetivo, el formato y los límites. El síntoma son resultados inconsistentes e intermitentes, y el culpable es la delegación, no el modelo.
Confianza ciega entre agentes
Aceptar la salida de un agente como verdad sin validarla, o dejar que el contenido no confiable que lee un agente dirija a otro con permisos. Es un fallo de fiabilidad y de seguridad a la vez.
Hay más. Jerarquías demasiado profundas (un coordinador de coordinadores) añaden saltos donde se pierde información. Reintentos sin tope y bucles de revisión sin criterio de parada convierten un error pequeño en una factura grande. Estado compartido sin dueño produce datos contradictorios. Y no evaluar el sistema como conjunto: cada agente puede funcionar bien aislado y el conjunto fallar en la coordinación.
Cuándo NO usar multiagente
Resumido como criterio de decisión:
- Los pasos son conocidos y estables: usa un flujo fijo.
- La tarea cabe cómoda en un contexto y una buena selección de herramientas: usa un agente único.
- Las subtareas dependen estrechamente unas de otras: el paralelismo no ayuda y la coordinación estorba.
- El requisito principal es coste bajo, latencia baja o auditoría estricta: cada agente extra empuja en contra.
- No tienes forma de evaluar el sistema completo: no sabrás si la complejidad ha mejorado algo.
Piensa también en el síntoma que traes de la lección anterior. Un agente intermitente, lento y caro rara vez se arregla añadiendo más agentes. Antes diagnostica: ¿hay demasiadas herramientas, un contexto inflado, un modelo mal proporcionado al paso, instrucciones ambiguas? Cuando la causa de fondo es una de esas, repartir el trabajo solo reparte el problema. Para valorar el coste real de cada decisión, mira la documentación oficial en platform.claude.com, y si tu escenario toca el mundo SAP, tienes las vías oficiales en /conexiones.
Para el examen
Dominio · Diseño de sistemas agénticos y multiagente
Lo que tienes que dominar
- Escalera de complejidad: llamada única, flujo fijo, agente único, multiagente; sube solo si el peldaño anterior no basta
- Razones legítimas para repartir: contexto, paralelismo independiente, especialización, aislamiento de seguridad, verificación independiente
- Orquestador con subagentes da más control y trazabilidad; agentes pares dan flexibilidad a costa de previsibilidad
- Delegar con objetivo, formato y límites explícitos; devolver resultados compactos y estructurados
- Los agentes no comparten memoria por defecto: el estado compartido se diseña (mensajes, almacén externo, resúmenes, memoria persistente)
- Tolerancia a fallos: validar en cada frontera, reintentos acotados, límites duros, degradación elegante, persistir progreso, humano en acciones irreversibles
- Permisos mínimos por agente y trazabilidad de lo que hace cada uno
Donde se suele fallar
- Elegir multiagente por sonar más potente o por la palabra complejo en el enunciado
- Atribuir al modelo un fallo que es de delegación sin contexto
- Confiar en la salida de un subagente sin validarla
- Dejar reintentos o bucles de revisión sin tope de iteraciones o de coste
- Permitir que varios agentes escriban el mismo estado sin un dueño claro
- Dar a todos los agentes todas las herramientas y permisos
- Resolver un agente lento y caro añadiendo agentes en vez de diagnosticar la causa
Para recordar
0 de 8 dominadosMarca lo que ya sabrías responder en el examen.
Ponte a prueba
Tipo test
6 preguntas sobre esta lección. Responde una a una; verás las soluciones al terminar.