Construí un Sistema Multiagente con Claude Code. Después lo Eliminé

En marzo de 2026 empecé a construir un sistema multiagente con Claude Code. La visión era crear un agente especialista para cada terreno principal de una empresa o agencia.

Un orquestador central delegaba el trabajo entre esos especialistas. Los handoffs buscaban conservar contexto, y construí un dashboard visual para mostrar cómo se conectaban e interactuaban los agentes.

El problema apareció cuando controlar la infraestructura empezó a exigir otra capa de trabajo. Había que evaluar si los agentes eran útiles, eficientes y si ejecutaban cada proceso de la forma esperada.

Unos tres meses después eliminé esa estructura. La redirección conservó el contexto relevante y pasó a trabajo directo, skills y herramientas activadas por necesidad.

La lección no es que toda arquitectura multiagente sea inútil. Es que solo merece existir cuando reduce una fricción recurrente y medible.

Cuando coordinar el sistema cuesta más que el trabajo que evita, simplificar no es un fracaso. Es una decisión de arquitectura.

Lo construí y después lo eliminé

La primera versión tomó forma en marzo como una capa de coordinación. Un orquestador recibía cada pedido, elegía un área, delegaba la tarea y consolidaba el resultado.

Mi intención era representar los grandes terrenos de una empresa o agencia con especialistas que recibieran solo el contexto, las herramientas y las responsabilidades de su dominio.

La configuración tenía roles, reglas de comunicación, handoffs y límites para evitar ciclos. También construí un dashboard para observar las conexiones y la interacción entre agentes.

Pero tener una configuración completa no demuestra un uso sostenido. Con el tiempo quedó claro que el orquestador no resolvía una fricción que apareciera con la frecuencia necesaria.

Cuando la comparé con el trabajo real, eliminé esa capa. No retiré los agentes como concepto ni descarté la delegación para siempre. Retiré una estructura concreta que no justificaba su costo de coordinación.

Qué problema intentaba resolver

El problema era válido: distintos trabajos requieren distinto contexto.

Una tarea de desarrollo no necesita las mismas instrucciones que una investigación editorial. Una auditoría no necesita las mismas herramientas que una corrección de copy.

En ese momento, separar especialistas por terreno tenía sentido. Permitía definir fronteras de responsabilidad y diseñar un recorrido explícito para trasladar contexto entre áreas.

El orquestador intentaba resolver cinco necesidades:

• dirigir cada pedido al contexto adecuado;
• separar responsabilidades;
• habilitar herramientas según el rol;
• coordinar tareas con dependencias;
• conservar trazabilidad mediante handoffs y decisiones compartidas.

Los handoffs respondían a esa intención: conservar decisiones y antecedentes cuando una tarea pasaba de un especialista a otro, sin depender de memoria implícita.

El error no estuvo en reconocer esas necesidades. Estuvo en asumir que todas requerían una organización permanente de agentes.

Muchas tareas cabían en una sesión directa con instrucciones claras. Otras podían resolverse con una skill reutilizable. Algunas requerían un MCP concreto. Muy pocas necesitaban una capa adicional de orquestación.

Qué arquitectura construí

Esta es una descripción histórica, no el estado actual del proyecto.

La arquitectura tenía un orquestador central con un contrato delegate-first. Su función era analizar, descomponer, delegar y consolidar. No debía implementar por sí mismo.

Debajo había responsables por dominio y ejecutores especializados. La configuración separaba trabajo de producto, contenido, crecimiento, operaciones y otras funciones de soporte.

También definía tres reglas de coordinación:

1. Sin devolución circular: si un área consultaba a otra, la segunda no debía volver a delegar hacia la primera.
2. Profundidad acotada: las cadenas de delegación debían detenerse antes de convertirse en una jerarquía difícil de seguir.
3. Handoffs explícitos: la información entre áreas se registraba en archivos, junto con las decisiones compartidas.

Los MCPs aportaban acceso a herramientas externas. Las instrucciones de cada rol delimitaban contexto, permisos, entradas y salidas esperadas.

El dashboard intentaba hacer visible esa arquitectura: mostraba conexiones e interacciones para ayudarme a entender cómo circulaba el trabajo. Su existencia no demuestra que el sistema fuera eficiente.

Sobre el papel, la arquitectura era coherente. El problema apareció al compararla con el trabajo que realmente ocurría.

Lo que confundí: construir un sistema no demuestra que sea útil

Construir la infraestructura me demostró que podía organizar agentes, roles, herramientas y handoffs. No demostró que esa organización resolviera un problema recurrente.

Tener un sistema configurado y documentado tampoco prueba que se use de forma sostenida o que mejore el trabajo.

Mucho menos demuestra aumentos de productividad, volumen editorial, resultados de SEO o impacto comercial. Esas afirmaciones requieren mediciones propias, una línea base y un período comparable.

Mi error fue tratar la existencia del sistema como una señal suficiente de valor. La pregunta correcta era otra: ¿qué fricción concreta reducía y cuánto costaba coordinarlo?

Por qué no justificó su complejidad

El sistema agregaba una organización permanente para una demanda que no era permanente.

Cada tarea podía requerir selección de rol, preparación de un brief, transferencia de contexto, espera, consolidación y revisión. Ese costo existe aunque la delegación no mejore el resultado.

Además, cada rol necesitaba mantenimiento. Había que actualizar instrucciones, herramientas, permisos, rutas y reglas compartidas cuando cambiaba el proyecto.

En mi experiencia, controlar la infraestructura resultó tan exigente como construirla. Evaluar utilidad, eficiencia y ejecución correcta requería una capa propia de seguimiento y control.

Esa capa debía observar handoffs, resultados y errores. La supervisión empezaba a convertirse en otro producto, con sus propias reglas y mantenimiento.

Mientras tanto, el orquestador hacía sobre todo delegación. La coordinación y su control terminaron siendo innecesariamente complejos frente al trabajo que buscaban ordenar.

El sistema optimizaba una escala hipotética. Todavía no existía la fricción repetida que justificara esa escala.

Esa es una señal clásica de sobrediseño: la arquitectura responde a un futuro posible en lugar de resolver el presente observable.

Qué eliminé y qué sobrevivió

Eliminé el orquestador permanente, las configuraciones de roles asociadas y la infraestructura de handoffs creada para sostener esa jerarquía.

La redirección consistió en conservar el contexto relevante sin mantener una organización permanente alrededor de cada tarea.

No eliminé todo lo aprendido. Sobrevivieron las piezas que reducían fricción por sí mismas:

• instrucciones claras y breves;
• contexto acotado al trabajo actual;
• skills para procedimientos repetibles;
• MCPs elegidos por necesidad;
• guardrails para acciones sensibles;
• trabajo directo como opción por defecto;
• revisión, juicio y aprobación humana.

No fue un abandono de los agentes. Fue una simplificación: usar delegación cuando aporta aislamiento o paralelismo, y recurrir a trabajo directo, skills o herramientas bajo demanda para el resto.

La simplificación conservó capacidades y eliminó estructura. Ese es el objetivo de una buena reducción arquitectónica.

El cambio de enfoque: menos jerarquía permanente, más skills

Hoy trabajo con un principio más simple: un agente principal, o un orquestador liviano, carga una skill enfocada cuando la necesita en lugar de sostener un especialista permanente por dominio.

Una skill empaqueta instrucciones, pasos, límites y criterios de verificación para un proceso repetible. Se carga solo cuando ese proceso es relevante.

Una red permanente tiene costos recurrentes: instrucciones de rol, transferencias de contexto, handoffs, supervisión y observabilidad.

En mi experiencia con este proyecto, el enfoque bajo demanda reduce coordinación, contexto repetido y consumo de tokens. También vuelve el sistema más fácil de entender y mantener.

Una skill no reemplaza a todos los agentes. Evita representar cada especialización como un agente permanente cuando basta con cargar un proceso enfocado bajo demanda.

Los sistemas multiagente siguen teniendo sentido cuando el trabajo exige:

• paralelismo real;
• aislamiento de contexto;
• revisión independiente o adversarial;
• límites distintos de permisos o herramientas;
• tareas de larga duración o flujos realmente separados.

En este proyecto, no agrego agentes solo para que la arquitectura parezca más avanzada.

Mi apuesta de diseño es que, si los agentes base siguen ampliando sus capacidades, algunas jerarquías estáticas podrían volverse menos necesarias.

Es una hipótesis que guía un punto de partida más simple, no una predicción sobre el futuro. Si una necesidad concreta justifica una arquitectura multiagente, esa opción sigue abierta.

Cómo decidir entre trabajo directo, skill, MCP, subagente y orquestador

Con ese principio, la decisión debe comenzar por la fricción, no por la herramienta.

Mecanismo	Cuándo usarlo	Costo que debe justificar
Trabajo directo	La tarea cabe en el contexto actual y tiene un responsable claro	Cambio de foco dentro de la misma sesión
Skill	Existe un procedimiento repetible que conviene cargar bajo demanda	Mantenimiento de instrucciones reutilizables
MCP	La tarea necesita consultar o modificar un sistema externo	Permisos, superficie de riesgo y mantenimiento de la integración
Subagente	Una subtarea necesita aislamiento, especialización o paralelismo real	Transferencia de contexto, coordinación y revisión
Orquestador	Hay múltiples flujos recurrentes, dependencias estables y decisiones de asignación repetidas	Operación, observabilidad, recuperación y costo permanente de coordinación

Una herramienta más sofisticada no es una etapa obligatoria de madurez. Es una respuesta posible a un problema específico.

Si el trabajo directo resuelve bien el caso, agregar un agente no mejora la arquitectura. Solo agrega otra pieza que puede fallar.

Cómo simplificar un sistema sobrediseñado

1. Inventariar el uso real

Revisar qué componentes se invocan, para qué tareas y con qué frecuencia. Separar lo configurado de lo utilizado.

2. Identificar la fricción recurrente

Buscar repeticiones observables: transferencias manuales, contexto que se reconstruye, errores previsibles o integraciones que se consultan de forma constante.

3. Comparar ahorro y costo de coordinación

Medir no solo el tiempo de ejecución. Incluir preparación, mantenimiento, permisos, revisión, recuperación de errores y carga cognitiva.

4. Colapsar capas sin demanda propia

Si un rol solo reenvía instrucciones, conviene eliminarlo. Si un handoff no aporta trazabilidad útil, conviene reemplazarlo por contexto directo.

5. Conservar procedimientos como skills

Una skill puede preservar una forma de trabajo sin mantener una organización completa de agentes.

6. Activar integraciones por necesidad

Un MCP debe existir porque una tarea necesita esa conexión. No porque ampliar el catálogo parezca una señal de sofisticación.

7. Reintroducir complejidad con una condición de éxito

Antes de crear otra capa, definir qué fricción reducirá y cómo se medirá. También establecer cuándo retirarla si esa mejora no aparece.

Lecciones que permanecen

La configuración no equivale a uso. Un repositorio puede demostrar que algo fue construido, pero no que produjo valor de forma sostenida.

La especialización puede vivir en el contexto. No toda diferencia de dominio necesita un agente permanente. A veces basta una instrucción localizada o una skill.

Las integraciones deben responder a una tarea. Un MCP es útil cuando elimina una transferencia manual concreta. Su cantidad no es una métrica de madurez.

La coordinación también es trabajo. Delegar exige preparar contexto, definir límites, observar la ejecución y revisar el resultado.

El juicio humano no se delega. Una persona debe decidir objetivos, aceptar riesgos, validar evidencia y aprobar acciones sensibles o publicaciones.

Eliminar también es diseñar. Retirar una capa que no paga su costo mejora la relación entre capacidad y complejidad.

Preguntas frecuentes

¿Esta retrospectiva demuestra que los sistemas multiagente no sirven?

No. Demuestra que una arquitectura concreta no justificó su costo en este proyecto. Otros contextos pueden tener suficiente recurrencia, paralelismo, riesgo o escala para necesitar coordinación explícita.

¿Cuándo merece existir un orquestador?

Cuando asigna trabajo recurrente entre flujos estables, reduce una fricción medible y cuenta con observabilidad, límites y recuperación. Si solo reenvía pedidos ocasionales, probablemente sobra.

¿Conviene comenzar por un sistema multiagente?

En general, conviene comenzar por el proceso manual más simple que permita observar la fricción. Después se agrega una skill, una integración o un subagente solo donde la evidencia lo justifica.

¿Qué debería medirse antes de agregar otra capa?

Frecuencia del problema, tiempo total de coordinación, errores evitados, calidad verificable, costo de mantenimiento y capacidad de recuperación. Sin una línea base, la complejidad no puede defenderse.

Hablemos de tu proceso

Si un proceso acumula agentes, integraciones o automatizaciones y ya no está claro qué fricción resuelve, hablemos de tu proceso.

La conversación puede terminar en una arquitectura más robusta o en una solución más simple. Ambas son decisiones válidas cuando se apoyan en evidencia.