La mayoría de los sistemas multi-agente nunca salen del demo
El equipo de ingeniería de Factory AI subió al escenario del AI Engineer World's Fair y mostró algo que la audiencia no esperaba: un sistema multi-agente que entrega código en producción. No un demo. No un prototipo de investigación. Un sistema que procesa miles de tareas de código por día, con clientes reales dependiendo del resultado. La charla ha acumulado más de 119,000 visualizaciones porque respondió una pregunta en la que la mayoría de los equipos estaban atascados: ¿cómo pasar de "agentes que impresionan en demos" a "agentes que funcionan el martes a las 3am cuando nadie está mirando"?
Según la guía de product.engineer, una arquitectura multi-agente es un diseño de sistema donde múltiples agentes de IA especializados se coordinan para completar tareas complejas, cada agente siendo responsable de una función distinta dentro de un flujo de trabajo mayor. A diferencia de un único agente monolítico que intenta hacerlo todo, un sistema multi-agente descompone el trabajo entre componentes construidos para un propósito específico que se comunican a través de interfaces definidas. Este es el patrón arquitectónico que separa la IA en producción de los proyectos de feria de ciencias.
Únete a 2.000+ ingenieros que definen, construyen y entregan.
Un correo por semana. Frameworks prácticos para ingenieros de producto. Sin spam.
La respuesta que Factory presentó no fue magia. Fue ingeniería. Específicamente, el tipo de ingeniería que un product engineer hace todos los días: descomponer problemas ambiguos en componentes entregables, construir sistemas que fallan de manera controlada y obsesionarse con el resultado para el usuario en lugar de la novedad técnica. La arquitectura multi-agente que describieron funciona no porque los agentes individuales sean más inteligentes, sino porque el diseño del sistema los restringe hacia la confiabilidad.
He pasado años construyendo sistemas donde la coordinación es la parte difícil. En AWS, vi a equipos luchar con sistemas distribuidos donde los servicios individuales funcionaban bien de forma aislada pero se desmoronaban en los límites de integración. La arquitectura multi-agente tiene exactamente el mismo modo de fallo. Los agentes no son el problema. La coordinación es el problema. Factory lo descubrió, y su solución es instructiva para cualquiera que esté construyendo sistemas de IA en producción hoy.
Por qué los sistemas de un solo agente llegan a un techo
Las arquitecturas de un solo agente dominaron la primera ola de herramientas de IA para código. Darle a un modelo una tarea, dejarlo pensar, dejarlo escribir código. Cursor, GitHub Copilot, las primeras versiones de Devin. Funcionan notablemente bien para tareas acotadas. Escribir una función. Corregir un bug. Generar un test.
Se rompen con tareas compuestas.
La investigación sobre tareas de ingeniería de software de múltiples pasos usando el dataset SWE-bench muestra que las configuraciones multi-agente con roles especializados para planificación, implementación y verificación superan significativamente a los sistemas de un solo agente. La mejora viene solo de la arquitectura, sin ninguna mejora en el modelo.
La razón es fundamental. Un solo agente manejando una tarea compleja debe mantener contexto de planificación, detalles de implementación y criterios de verificación en una sola ventana de contexto simultáneamente. A medida que las tareas crecen en complejidad, estas preocupaciones compiten por atención. La planificación se degrada porque el modelo está distraído por los detalles de implementación. La implementación sufre porque el modelo sigue razonando sobre el plan. La verificación se convierte en algo secundario porque la ventana de contexto está saturada.
La arquitectura multi-agente resuelve esto mediante separación de responsabilidades. El mismo principio que hace que los microservicios funcionen mejor que los monolitos. El mismo principio que hace que los pipelines de Unix sean poderosos. Componentes pequeños y enfocados haciendo una cosa bien, conectados a través de interfaces limpias. No es una idea nueva. Es una idea vieja aplicada a un sustrato nuevo.
El techo para los sistemas de un solo agente está aproximadamente correlacionado con la utilización de la ventana de contexto. Una vez que una tarea requiere más del 60% de la ventana de contexto efectiva de un modelo para el razonamiento completo, el rendimiento del agente único se degrada de forma no lineal. La arquitectura de Factory evita esto distribuyendo la carga cognitiva entre múltiples agentes especializados, cada uno operando cómodamente dentro de su presupuesto de contexto.
La arquitectura en producción de Factory, descompuesta
La arquitectura multi-agente de Factory, tal como fue presentada en AI Engineer, sigue un patrón que llaman "Drafter, Reviewer, Integrator." El framework de product.engineer para sistemas multi-agente mapea esto a tres clases de agentes, cada uno con un rol específico, coordinándose a través de un workspace compartido. Voy a desglosar lo que realmente corre en producción.
El agente Drafter
El Drafter recibe una especificación de tarea y produce cambios de código candidatos. Opera con un contexto enfocado: la descripción de la tarea, el contenido de los archivos relevantes y las convenciones de código. Nada más. Sin historial de revisiones. Sin contexto de deploy. Sin preocupaciones de integración. Esta restricción es deliberada. El trabajo del Drafter es producir soluciones plausibles, no perfectas.
Factory reportó que sus agentes Drafter producen código viable en primera pasada en el 84% de los casos. El 16% restante requiere iteración, pero de forma crítica, esa iteración es manejada por un agente diferente con contexto diferente y objetivos diferentes. El Drafter nunca ve sus propios fallos porque darle contexto de fallos contaminaría su enfoque generativo.
El agente Reviewer
El Reviewer recibe el output del Drafter junto con una ventana de contexto diferente: estándares de código, políticas de seguridad, requisitos de cobertura de tests y patrones históricos del codebase. Su trabajo es pura crítica. Identifica problemas, señala posibles inconvenientes y produce feedback estructurado.
Esta separación es crucial. Cuando un solo agente escribe y revisa código, exhibe sesgo de confirmación. Tiende a aprobar su propio trabajo. Al separar estos roles entre agentes con diferentes system prompts y diferente contexto, Factory elimina este sesgo de forma estructural. El Reviewer nunca ha visto la especificación de la tarea en su forma original. Solo ve el código y los estándares que debe mantener.
El agente Integrator
El Integrator maneja la capa de coordinación: fusionar cambios, resolver conflictos, ejecutar tests y gestionar el pull request final. Opera con el contexto más amplio pero el espacio de acción más estrecho. Puede fusionar, rechazar o solicitar re-drafting, pero no puede escribir código él mismo.
Esta restricción previene un modo de fallo común donde un agente de integración "arregla" problemas escribiendo parches, introduciendo bugs sutiles que ni el Drafter ni el Reviewer habrían producido. El Integrator es un coordinador, no un contribuidor.
Comparación: patrones de agente único vs. multi-agente
| Dimensión | Agente Único | Multi-Agente (Patrón Factory) |
|---|---|---|
| Utilización de contexto | 80-100% de la ventana | 30-50% por agente |
| Sesgo de confirmación | Alto (se auto-revisa) | Eliminado estructuralmente |
| Aislamiento de fallos | Toda la tarea falla | Reintentos por agente individual |
| Debugging | "¿Por qué hizo eso?" | Logs claros por agente |
| Latencia | Razonamiento secuencial | Paralelo donde es posible |
| Testeabilidad | Solo tests de integración | Tests unitarios por agente |
| Escalabilidad | Vertical (modelo más grande) | Horizontal (más agentes) |
El protocolo de coordinación multi-agente que realmente entrega
Los agentes solos no son arquitectura. La coordinación entre ellos es la arquitectura. La presentación de Factory reveló tres patrones de coordinación que distinguen su sistema en producción de la investigación académica multi-agente.
Patrón 1: Handoffs tipados
Toda comunicación agente-a-agente usa un esquema tipado. El Drafter no pasa "algo de código" al Reviewer. Pasa un objeto estructurado con campos para: archivos modificados, justificación de cada cambio, scores de confianza por archivo y suposiciones explícitas sobre el codebase. El Reviewer consume esta estructura, no texto plano.
Esto importa porque la comunicación no tipada entre agentes es la fuente principal de fallos en cascada. Cuando el Agente A pasa un output ambiguo al Agente B, el Agente B debe interpretarlo, y la interpretación introduce error. Los handoffs tipados eliminan la interpretación. Son los contratos de API de los sistemas multi-agente.
Patrón 2: Reintento acotado con escalación
Cuando un Reviewer rechaza el output del Drafter, el sistema no itera indefinidamente. Factory implementa un protocolo de reintento acotado: el Drafter tiene como máximo dos intentos para abordar el feedback. Si ambos intentos fallan, la tarea escala a un ingeniero humano con contexto completo: la tarea original, ambos intentos y las razones específicas del fallo.
Este patrón de reintento acotado es lo que hace al sistema seguro para producción. Los loops de reintento sin límite son la forma más común en que los sistemas multi-agente desperdician cómputo y producen output cada vez más incoherente. Cada reintento degrada la calidad del output porque el modelo está razonando sobre sus propios fallos, lo cual consume contexto que debería estar dedicado a la solución.
Factory reportó que el 91% de las tareas se completan en el primer intento. El 7% requiere un reintento. El 2% restante escala a humanos. Esta distribución es saludable. Significa que el sistema conoce sus límites.
Patrón 3: Workspace compartido, contexto aislado
Todos los agentes operan sobre el mismo codebase (workspace compartido) pero ven diferentes porciones del mismo (contexto aislado). El Drafter ve los archivos relevantes a su tarea. El Reviewer ve esos archivos más la guía de estilo y las expectativas de tests. El Integrator ve el grafo completo de dependencias y el estado de CI.
Esto es análogo a cómo trabajan los equipos humanos de ingeniería. El desarrollador ve el código. El revisor ve el código más los estándares. El ingeniero de release ve el estado del sistema. El mismo artefacto, diferentes perspectivas. La arquitectura multi-agente codifica este patrón organizacional en software.
Qué significa esto para los product engineers
Si eres un product engineer construyendo features impulsadas por IA, los patrones de Factory ofrecen lecciones concretas que puedes aplicar hoy. Esto no es arquitectura abstracta. Son patrones que entregan.
Lección 1: Descomponer por modo cognitivo, no por tipo de tarea. La división Drafter, Reviewer, Integrator no se trata de "planificación, código, testing." Se trata de "generar, criticar, coordinar." Estos son modos cognitivos fundamentalmente diferentes. Cuando diseñas sistemas multi-agente, separa los agentes por cómo piensan, no por lo que hacen. Un product engineer que entiende esto construirá sistemas más confiables que uno que separa agentes por taxonomía de tareas.
Lección 2: Las restricciones habilitan la entrega. Los agentes de Factory están fuertemente restringidos. El Drafter no puede revisar. El Reviewer no puede escribir código. El Integrator no puede escribir parches. Estas restricciones se sienten limitantes, pero son lo que hace al sistema lo suficientemente predecible para correr en producción. Cada restricción que agregas a un agente es una clase de fallo que eliminas. Esto conecta directamente con el principio de hacer tu codebase listo para agentes: cuanto más estructurado sea tu sistema, más confiablemente podrán operar los agentes dentro de él.
Lección 3: La escalación humana es una feature, no un fallo. Esa tasa de escalación del 2% no es un bug. Es una decisión de diseño. El sistema está explícitamente diseñado para reconocer cuando no puede resolver un problema y enrutarlo a un humano con contexto completo. Esto es lo que distingue a los sistemas en producción de los demos. Los demos nunca fallan. Los sistemas en producción fallan de manera controlada.
Lección 4: Monitorear los límites agente-a-agente, no solo los outputs de los agentes. Los bugs en los sistemas multi-agente viven en los límites. El Drafter produce buen código. El Reviewer hace buenas críticas. Pero el handoff entre ellos pierde información porque el esquema tipado no captura algún matiz. Factory instrumenta cada handoff, midiendo completitud del esquema, tiempo de ida y vuelta y pérdida de información. Si estás construyendo sistemas multi-agente, tu capa de observabilidad debe cubrir los espacios entre agentes, no solo los agentes mismos.
Patrones que puedes tomar prestados hoy
No necesitas la escala de Factory para aplicar arquitectura multi-agente. Aquí hay patrones concretos que funcionan para cualquier tamaño de equipo, destilados de su enfoque y validados contra lo que he visto funcionar en AWS y en mis propios proyectos.
El loop Draft-Review para cualquier feature con IA
En lugar de pedirle a un modelo que "escriba y revise" código, divídelo en dos llamadas separadas con diferentes system prompts. La primera llamada genera con un prompt creativo y enfocado en soluciones. La segunda llamada evalúa con un prompt crítico y enfocado en estándares. Diferentes configuraciones de temperature, diferente contexto, diferentes objetivos. Puedes implementar esto en una tarde y mejorará inmediatamente la calidad de tu output de IA.
// Pseudocode for a minimal multi-agent pattern
const draft = await model.generate({
systemPrompt: "You are a code generator. Focus on correctness and clarity.",
context: [taskSpec, relevantFiles],
temperature: 0.7
});
const review = await model.generate({
systemPrompt: "You are a code reviewer. Focus on bugs, security, style violations.",
context: [draft.output, styleGuide, securityPolicy],
temperature: 0.2
});
if (review.approved) {
return draft.output;
} else {
// One bounded retry
const revision = await model.generate({
systemPrompt: "You are a code generator. Address this specific feedback.",
context: [taskSpec, relevantFiles, review.feedback],
temperature: 0.5
});
return revision.output;
}El patrón Coordinator para flujos de trabajo complejos
Cuando tienes flujos de trabajo de múltiples pasos (flujos de onboarding, pipelines de datos, secuencias de deploy), designa un agente como coordinador que no puede ejecutar trabajo por sí mismo. Solo puede despachar a agentes workers y gestionar estado. Este es el patrón Integrator aplicado a cualquier dominio. El coordinador mantiene el estado global. Los workers mantienen contexto local. Ningún agente individual mantiene todo.
Linear usa una variante de este patrón en sus features de gestión de proyectos con IA. El agente de coordinación entiende la estructura del proyecto y la asignación del equipo. Los agentes workers manejan tareas específicas como escribir actualizaciones, hacer triage de bugs o redactar especificaciones. El coordinador nunca escribe contenido por sí mismo. Enruta, prioriza y escala.
El agente de verificación para seguridad en producción
Agrega un agente de verificación final a cualquier pipeline que produzca output visible para el usuario. Este agente recibe el output final más un conjunto de invariantes que deben ser verdaderas. "La respuesta no debe contener PII." "El código debe pasar la verificación de tipos." "El resumen debe referenciar el documento original." El agente de verificación tiene un solo trabajo: confirmar o rechazar. Es económico de ejecutar, rápido de procesar y atrapa la clase de errores que se escabullen después de la generación y la revisión.
Stripe usa este patrón en su pipeline de documentación. Los docs generados pasan por un agente de verificación que verifica la exactitud técnica contra sus especificaciones de API. El agente de verificación atrapa aproximadamente el 12% de los outputs que de otro modo se habrían publicado con errores técnicos sutiles.
La economía de multi-agente vs. agente único
Una objeción común a la arquitectura multi-agente es el costo. "Estás haciendo tres llamadas a la API en lugar de una." Este encuadre malinterpreta la economía.
Factory compartió la economía de producción en su charla. Su sistema multi-agente cuesta aproximadamente 2.3x por tarea comparado con un baseline de agente único. Pero su tasa de éxito es 3.1x mayor. Y su tasa de retrabajo (tareas que necesitan intervención humana después de la completación inicial) es 74% menor. Cuando consideras el costo total de un ingeniero re-haciendo trabajo fallido de IA, el sistema multi-agente es aproximadamente 40% más barato por tarea completada exitosamente.
La ecuación de costos:
- Agente único: $0.12 por tarea, 31% tasa de éxito = $0.39 por tarea exitosa
- Multi-agente: $0.28 por tarea, 96% éxito en primera pasada = $0.29 por tarea exitosa
Estos números son del sistema en producción de Factory circa principios de 2026. Tus números variarán, pero la proporción se mantiene. Gastar más en inferencia para obtener mayor confiabilidad es casi siempre más barato que gastar tiempo humano arreglando output poco confiable.
La investigación sobre economía de agentes respalda hallazgos similares. Las configuraciones multi-agente con 3-5 agentes especializados consistentemente superan a los sistemas de agente único en métricas de costo-por-completación-exitosa, a pesar de los mayores costos brutos de inferencia. El punto de equilibrio es aproximadamente una mejora del 15% en la tasa de éxito. Cualquier cosa por encima de eso, y el multi-agente se paga solo.
Mi experiencia con coordinación de agentes a escala
Habiendo guiado a más de 12,000 ingenieros a través de varios programas y contratado a más de 600 durante mi carrera, he visto un patrón consistente: los equipos que entregan features de IA confiables no son los que tienen los modelos más sofisticados. Son los que tienen la arquitectura más disciplinada. Los patrones multi-agente que Factory describe se mapean directamente a lo que he observado en AWS, donde el pensamiento en sistemas distribuidos es el requisito mínimo.
Los equipos con los que he trabajado que más luchan con la integración de IA son aquellos que tratan al modelo como un oráculo monolítico. "Pedirle que haga todo, esperar lo mejor." Los equipos que tienen éxito tratan las llamadas de IA como llamadas de servicio en un sistema distribuido: acotadas, tipadas, reintentables, observables. Construyen flujos de trabajo de ingeniería colaborativa con IA donde el sistema está diseñado para degradación controlada, no para rendimiento perfecto. Este es el superpoder del product engineer. Piensas en sistemas, no en prompts.
Como product engineer, tu trabajo es entregar resultados, no impresionar a la gente con la complejidad de tu arquitectura de agentes. Los sistemas multi-agente son poderosos precisamente porque hacen que el comportamiento complejo emerja de componentes simples y restringidos. Cada agente es aburrido. El sistema es interesante. Esa es toda la lección.
Modos de fallo comunes y cómo evitarlos
Después de estudiar el enfoque de Factory e implementar variaciones en múltiples proyectos, he identificado los modos de fallo que matan a los sistemas multi-agente en producción.
El loop infinito. Dos agentes se pasan feedback indefinidamente. El Agente A redacta, el Agente B rechaza, el Agente A revisa, el Agente B rechaza otra vez. Solución: límites duros en reintentos. Factory usa dos. He visto equipos tener éxito con tres. Nunca más de cinco. Si cinco intentos no pueden resolverlo, un humano necesita revisar.
La fuga de contexto. El Agente A recibe información destinada solo al Agente B. Esto sucede cuando compartes un solo hilo de conversación entre agentes. Solución: aislamiento estricto de contexto. Cada agente obtiene su propia ventana de contexto, poblada únicamente con la información relevante a su rol.
El conflicto de autoridad. Dos agentes dan instrucciones contradictorias a un tercero. El Reviewer dice "agrega manejo de errores." El agente de rendimiento dice "elimina el try-catch, es muy lento." Solución: jerarquía clara. En el sistema de Factory, el Integrator resuelve los empates. Siempre hay exactamente un agente con autoridad final.
La brecha de observabilidad. Puedes ver lo que cada agente produjo pero no por qué el sistema se comportó como lo hizo. El bug vive en la interacción entre agentes. Solución: registrar cada handoff, cada esquema, cada punto de decisión. Tu observabilidad debe cubrir los espacios entre agentes, no solo los agentes mismos.
La trampa del escalamiento prematuro. Agregas más agentes porque "multi-agente es mejor" sin validar que la descomposición mejora los resultados. Solución: empieza con un agente. Agrega un segundo solo cuando puedas medir un fallo específico que el segundo agente prevendría. Factory empezó con un agente y agregó componentes solo cuando los datos de producción mostraron modos de fallo específicos que la descomposición resolvería.
Hacia dónde se dirige la arquitectura multi-agente
El patrón de arquitectura multi-agente que Factory demostró es la versión uno. Varios desarrollos moldearán cómo esto evoluciona en los próximos 12 a 18 meses.
Modelos especializados más pequeños y baratos. Ejecutar modelos de clase GPT-4 para cada agente es costoso. La tendencia hacia modelos más pequeños pero capaces (Mistral, Phi, variantes de Llama fine-tuneadas para tareas específicas) significa que puedes ejecutar agentes especializados en modelos construidos para un propósito. Tu Drafter podría usar un modelo grande y creativo. Tu Reviewer podría usar un modelo más pequeño fine-tuneado con datos de code review. El Integrator podría usar un modelo de razonamiento optimizado para toma de decisiones.
Protocolos estandarizados para agentes. El Model Context Protocol (MCP) de Anthropic, el Agent Protocol de la AI Engineer Foundation y la especificación de function calling de OpenAI están convergiendo hacia interfaces estándar para la comunicación entre agentes. Dentro de un año, podrás componer agentes de diferentes proveedores con interfaces tipadas e interoperables.
Herramientas de observabilidad para agentes. Empresas como LangSmith, Helicone y Braintrust están construyendo observabilidad específicamente para sistemas multi-agente. Tracing que abarca los límites entre agentes, atribución de costos por agente y benchmarking de rendimiento entre configuraciones. Estas herramientas harán que los sistemas multi-agente sean tan debuggeables como los sistemas distribuidos tradicionales.
El product engineer que entiende la arquitectura multi-agente hoy estará construyendo la próxima generación de productos impulsados por IA mañana. No porque la tecnología sea novedosa, sino porque los patrones están probados. Descomponer. Restringir. Coordinar. Entregar.
Puntos clave
- La arquitectura multi-agente separa agentes especializados por modo cognitivo (generar, criticar, coordinar), no por tipo de tarea
- Los handoffs tipados entre agentes eliminan la ambigüedad que causa fallos en cascada
- El reintento acotado con escalación humana hace que los sistemas sean seguros para producción; los loops sin límite son el modo de fallo principal
- Los sistemas multi-agente cuestan más por tarea pero menos por resultado exitoso; el punto de equilibrio es aproximadamente una mejora del 15% en la tasa de éxito
- Empieza con un agente y agrega descomposición solo cuando los datos de producción revelen modos de fallo específicos que lo justifiquen
- Monitorea los límites entre agentes, no solo los outputs de los agentes; ahí es donde viven los bugs de producción
FAQ
¿Qué es la arquitectura multi-agente en ingeniería de software?
La arquitectura multi-agente es un patrón de diseño de sistemas donde múltiples agentes de IA especializados se coordinan para completar tareas complejas. Cada agente es responsable de una función distinta (como redactar código, revisar código o coordinar la integración) y se comunica con otros agentes a través de interfaces tipadas. Este patrón refleja la arquitectura de microservicios en el software tradicional: componentes pequeños y enfocados conectados a través de APIs limpias.
¿En qué se diferencia la arquitectura multi-agente de un único agente de IA?
Un único agente de IA intenta manejar todos los aspectos de una tarea dentro de una sola ventana de contexto, lo que lleva a sobrecarga cognitiva en tareas complejas. La arquitectura multi-agente distribuye la carga cognitiva entre agentes especializados, cada uno operando dentro de un contexto enfocado. La investigación del NLP Group de Princeton muestra que las configuraciones multi-agente logran tasas de éxito 2.4x mayores en tareas reales de ingeniería de software comparadas con enfoques de agente único.
¿Cuándo debería usar arquitectura multi-agente en lugar de un solo agente?
Usa sistemas de un solo agente para tareas acotadas y bien definidas que caben cómodamente dentro de la ventana de contexto de un modelo (escribir una función, responder una pregunta, generar un test). Cambia a arquitectura multi-agente cuando las tareas requieran múltiples modos cognitivos (generar Y evaluar Y coordinar), cuando las tasas de éxito del agente único caigan por debajo de umbrales aceptables, o cuando necesites garantías estructurales como prevenir el sesgo de confirmación en la revisión de código.
¿Cómo funciona el sistema multi-agente de Factory AI en producción?
Factory AI usa un patrón "Drafter, Reviewer, Integrator." El Drafter genera cambios de código candidatos con enfoque creativo. El Reviewer evalúa esos cambios contra estándares y políticas con enfoque crítico. El Integrator coordina la fusión, testing y deploy sin escribir código por sí mismo. Logran un 96% de éxito en primera pasada con reintentos acotados y escalación humana para los casos restantes.
¿Es la arquitectura multi-agente más costosa que usar un solo agente?
Los sistemas multi-agente cuestan más en inferencia bruta (aproximadamente 2-3x por tarea), pero son más baratos por tarea completada exitosamente porque sus tasas de éxito son dramáticamente mayores. Factory reporta que su sistema multi-agente produce resultados exitosos a $0.29 por tarea versus $0.39 por tarea para su baseline de agente único. El punto de equilibrio es aproximadamente una mejora del 15% en la tasa de éxito, que los sistemas multi-agente bien diseñados consistentemente superan.