El año en que multiagente se volvió real
Durante la mayor parte de 2024, la conversación sobre multiagente era pura intuición. La gente publicaba demos de "enjambres de agentes" planeando bodas o gestionando empresas falsas, y casi nada de eso sobrevivía al contacto con producción. La promesa era enorme. La evidencia era escasa.
Eso cambió en abril de 2025, cuando Anthropic publicó la reseña de ingeniería de su sistema de investigación multiagente. La arquitectura era simple en su forma: un agente líder Claude Opus 4 actúa como orquestador, divide una pregunta de investigación en subtareas, lanza subagentes para investigar en paralelo y luego ensambla sus salidas. En la evaluación interna de navegación de Anthropic, esta configuración superó a una base de Opus 4 de un solo agente en un 90.2 por ciento. (Anthropic engineering, "How we built our multi-agent research system")
Ese es el titular. La letra pequeña importa más. La misma reseña señala que los sistemas multiagente usan unas 15 veces más tokens que un chat normal. El consumo de tokens explicó aproximadamente el 80 por ciento de la varianza de rendimiento en su marco de evaluación. No estás obteniendo ese 90.2 por ciento gratis; lo estás comprando.
Así que ahora la pregunta para cualquier fundador, CTO o ingeniero senior que diseñe una funcionalidad de IA ya no es "¿es multiagente un patrón real?". Es "¿es multiagente el patrón correcto para esta tarea y a qué costo?". 2025 y la primera mitad de 2026 produjeron suficientes datos para responder eso con algo más que intuición. Los patrones que ganaron, los patrones que perdieron y los modos de falla que se repiten se parecen mucho al diseño organizacional clásico. Ese es el hilo de este artículo.
La taxonomía de modos de falla: lo que documentaron Cemri et al.
En marzo de 2025, Mert Cemri y colaboradores en Berkeley publicaron "Why Do Multi-Agent LLM Systems Fail?" (arXiv 2503.13657). El paper analizó cinco frameworks multiagente populares en más de 150 trazas conversacionales y produjo algo que el campo necesitaba con urgencia: una taxonomía.
Catorce modos de falla distintos, agrupados en tres familias.
Fallas de especificación y diseño del sistema. Los agentes desobedecen su especificación de rol. Desobedecen la especificación de la tarea. Pierden el historial de la conversación. Se repiten pasos. Las condiciones de terminación nunca se disparan. El sistema "conoce" la tarea, pero el agente individual frente a ti no se comporta como si la conociera.
Desalineación entre agentes. Los agentes reinician el progreso y comienzan de nuevo. Se retienen información unos a otros. Se desvían hacia intercambios fuera de tema. Hacen suposiciones sobre lo que otro agente ha hecho y actúan sobre esas suposiciones sin verificar. Esta es la clásica falla de "pensé que tú lo tenías" de cualquier equipo.
Fallas de verificación y terminación de la tarea. La verificación es incompleta o ausente. El sistema declara éxito cuando la salida está mal. Ningún agente es dueño de la verificación final de aceptación. Los humanos solo detectan el problema corriente abajo, cuando la mala salida ya se ha propagado.
Lee la lista y la forma se vuelve obvia. Estas no son fallas del modelo en el sentido estricto. Son fallas de coordinación. Son las mismas fallas que comete un equipo nuevo de cinco personas en su primer mes, antes de que alguien haya escrito quién es dueño de qué.
Agrupa los 14 modos de otra manera y el paralelo con el diseño organizacional se afina:
- Ambigüedad de roles. Propiedad de tareas difusa. Dos agentes intentan el mismo paso, o ninguno lo hace.
- Ambigüedad de estado. No hay una única fuente de verdad sobre lo que se ha hecho, lo que está pendiente, lo que está bloqueado.
- Vacíos de rendición de cuentas. ¿Quién es responsable de la mala salida? En sistemas peer-to-peer, a menudo nadie.
- Sobrecarga de coordinación. El "problema de las reuniones". Los agentes gastan tokens negociando en lugar de produciendo.
- Deriva de la especificación. La misma instrucción se interpreta de manera diferente entre agentes y entre turnos.
Si alguna vez has reconstruido un equipo que no estaba entregando, has visto las cinco. La solución en equipos humanos es la misma que en sistemas de agentes: elige un modelo operativo, escribe los roles, define los traspasos, instrumenta el trabajo.
Por qué los agentes peer-to-peer no funcionan
El error arquitectónico más común de 2024 y principios de 2025 fue la colaboración peer-to-peer: generar un "equipo" de agentes con diferentes prompts de rol (CEO, investigador, programador, revisor), dejarlos hablar entre ellos en un chat grupal, esperar que la coordinación emerja. Los chats grupales estilo AutoGen, los primeros demos de CrewAI y una ola de proyectos de "startup de IA en una caja" se apoyaron en este patrón.
Falló en producción, de forma consistente. Cada modo de falla en la taxonomía de Cemri se amplifica en una configuración P2P. Sin orquestador, las fronteras de roles se desdibujan porque a cualquier agente se le puede pedir hacer cualquier cosa. El estado se dispersa por el historial de la conversación porque ningún agente es dueño del registro canónico. La rendición de cuentas desaparece porque el sistema en su conjunto produce la salida, y el sistema en su conjunto no tiene nombre en ella.
La sobrecarga de coordinación es el factor letal. En un grupo de cinco agentes peer, cada acción significativa genera cuatro observadores que se sienten obligados a comentar. El costo de tokens se dispara. La relación señal-ruido se desploma. Cemri et al. encontraron que el reinicio conversacional, donde un agente reinicia un hilo terminado porque no puede decir que el hilo ha terminado, fue una de las fallas más comunes y más costosas en su corpus.
Un ejemplo concreto. Un equipo de investigación con el que hablé a finales de 2025 construyó un sistema de agentes P2P para redactar un análisis competitivo. Cinco agentes: analista de mercado, analista de producto, analista financiero, redactor, editor. La primera ejecución tomó 90 minutos y produjo un documento de 14,000 palabras. Aproximadamente 11,000 de esas palabras eran los agentes discutiendo qué debía contener el documento. Las 3,000 restantes eran el documento en sí, y se contradecían entre sí. El equipo lo reconstruyó como una configuración orquestador-trabajador la semana siguiente. Misma tarea, 22 minutos, 4,200 palabras, internamente consistentes. Aproximadamente la mitad del gasto en tokens.
P2P no falló porque los agentes no fueran lo suficientemente inteligentes. Falló porque les pidió que hicieran lo más difícil que puede hacer un grupo: organizarse sin un líder.
Orquestador-trabajador: el patrón que ganó
El sistema de investigación de Anthropic es una configuración orquestador-trabajador de manual. Un agente coordinador es dueño de la tarea de alto nivel. Descompone la tarea en subtareas, entrega cada subtarea a un agente trabajador con un informe específico, recolecta los resultados y decide qué hacer a continuación. Los trabajadores no se hablan entre ellos. Le hablan al orquestador.
Esto se mapea limpiamente al diseño organizacional humano, que es exactamente por qué funciona. Una startup pequeña con un fundador y cuatro contratistas opera de esta manera. El fundador tiene la especificación, el presupuesto, el cronograma y el contexto compartido. Los contratistas ejecutan tareas acotadas contra un informe. La información fluye hacia arriba a través del fundador; las tareas fluyen hacia abajo desde el fundador. No se espera que los contratistas se coordinen entre sí salvo en emparejamientos cuidadosamente acotados.
El patrón tiene cuatro propiedades que importan para la confiabilidad.
Un único dueño del estado compartido. El orquestador tiene el registro canónico. No hay ambigüedad sobre lo que se ha hecho.
Contextos de trabajador acotados. Cada trabajador recibe solo lo que necesita. Esto mantiene manejables las ventanas de contexto y reduce la posibilidad de contaminación entre tareas.
Traspasos definidos. Las salidas de los trabajadores regresan en un formato estructurado que el orquestador puede verificar. Sin negociación de formato libre.
Una única superficie de rendición de cuentas. Cuando la salida está mal, el orquestador es el responsable. Depuras un solo lugar.
La reseña de Anthropic es explícita sobre cuánto de su trabajo de confiabilidad ocurrió dentro del orquestador: el prompt del agente líder es la parte más larga y cuidadosamente ajustada del sistema, porque ahí es donde viven las definiciones de rol, las heurísticas de descomposición y la lógica de terminación. (Anthropic engineering)
La colaboración acotada es una variante útil. A dos trabajadores se les puede permitir conferenciar sobre un traspaso específico, pero solo a través de un canal estructurado y solo sobre un tema definido. Piénsalo como una reunión diaria programada, no como un canal de Slack. El límite es el punto.
| Patrón | Resistencia a fallas | Costo | Complejidad | Dónde encaja |
|---|---|---|---|---|
| Peer-to-peer (chat grupal) | Baja. Cada modo de falla se amplifica. | Alto. Muchos tokens de negociación. | Engañosa. Parece simple, no lo es. | Demos, bocetos de lluvia de ideas. |
| Orquestador-trabajador | Alta. Un dueño, una superficie de depuración. | Moderado a alto. ~10-15x un solo agente. | Moderada. La mayor parte de la lógica vive en el orquestador. | Investigación, descomposición, trabajo paralelizable. |
| Colaboración acotada | Media-alta. El riesgo vive en la juntura. | Moderado. Más barato que P2P completo. | Mayor. Los traspasos diseñados son trabajo. | Emparejamientos de especialistas bajo un orquestador. |
| Agent-flow (DAG) | Alta. La estructura estática anticipa la deriva. | Bajo a moderado. Reutiliza pasos en caché. | Moderada en tiempo de diseño, baja en ejecución. | Pipelines repetitivos, procesamiento por lotes. |
El marco de 5 niveles de autonomía
La otra pieza del andamiaje de 2025 que vale la pena conocer es el marco de autonomía de "Levels of Autonomy for AI Agents" (arXiv 2506.12469, con una reseña complementaria de gobernanza en Knight Columbia). Los autores definen cinco niveles, vagamente análogos a la automatización de conducción SAE pero para agentes de IA.
Nivel 0: Asistente. El modelo sugiere; el humano actúa. Autocompletado, sugerencias de código en línea, redacción de borradores de correo.
Nivel 1: Operador. El humano sigue emitiendo cada acción, pero el agente ensambla llamadas a herramientas y pasos compuestos bajo instrucción directa.
Nivel 2: Revisor. El agente propone un plan y lo ejecuta bajo revisión. El humano aprueba en los puntos de control principales.
Nivel 3: Colaborador. El agente es dueño de tareas completas de forma autónoma dentro de un límite acotado. El humano revisa las salidas, no los pasos.
Nivel 4: Experto. El agente opera de forma independiente en trabajo complejo de múltiples pasos, con el humano interviniendo solo en excepciones marcadas.
Nivel 5: Agente. Autonomía total en un dominio. El agente establece metas, planifica, ejecuta y se autocorrige con supervisión mínima.
El trabajo complementario de Anthropic "Measuring AI agent autonomy in practice" hace una observación relacionada: en despliegues reales, el nivel operativo rara vez es uniforme en todo el sistema. Un sistema de "nivel 3" generalmente contiene subcomponentes de nivel 1 (acciones de alto impacto) y subcomponentes de nivel 4 (trabajo en segundo plano de bajo impacto). Lo que importa es hacer coincidir el nivel con la tarea, no elevar el nivel globalmente.
El nivel que apuntas moldea cada decisión de diseño de rol corriente abajo. En el nivel 2, tus agentes trabajadores necesitan affordances claros de revisión del plan. En el nivel 4, necesitan marcado de excepciones y trazado enriquecido. En el nivel 5, necesitan verificación formal de los criterios de aceptación, porque nada más detecta una respuesta incorrecta. Los constructores que se saltan este paso eligen primero la arquitectura y luego descubren, en producción, que el nivel que implica la arquitectura no es el nivel que la tarea puede tolerar.
Niveles en la práctica: el caso Devin
Devin de Cognition se convirtió en la historia con moraleja más citada de 2025. Lanzado en marzo de 2024 como "el primer ingeniero de software con IA", Devin obtuvo un 13.86 por ciento en SWE-bench Verified, lo que en ese momento era estado del arte. El marketing implicaba autonomía de nivel 4 o nivel 5: entrégale un ticket, recibe un PR funcional de vuelta.
A mediados de 2025, múltiples reseñas independientes situaban la tasa de éxito en el mundo real de Devin en aproximadamente un 15 por ciento, lo que significa una tasa efectiva de falla de alrededor del 85 por ciento en tareas que no eran instancias de benchmark curadas. Una reseña muy citada de Answer.AI repasó 20 intentos reales y reportó que 14 fallaron directamente, con varios produciendo salidas con confianza pero incorrectas que tomaron más tiempo depurar que escribir el código desde cero.
Lo que sucedió es la brecha benchmark-versus-producción, afilada. Las tareas de SWE-bench Verified son limpias: un repo, un problema bien descrito, una señal de prueba clara, una superficie acotada. Los tickets reales de ingeniería son desordenados: especificaciones ambiguas, preocupaciones transversales, suposiciones no documentadas, decisiones que dependen del conocimiento tribal. El mismo agente que se ubicó en el nivel 3 en el benchmark cayó a un inestable nivel 2 en la práctica, a veces peor.
Devin no es una historia sobre un mal agente. Es una historia sobre un desajuste de nivel. La arquitectura apuntaba a la confiabilidad del nivel 5; la capacidad subyacente soportaba el nivel 2 en el mejor de los casos en trabajo no curado. El marketing forzó a los usuarios a operar el sistema en el nivel anunciado, donde falló. Los pivots posteriores de Cognition, casos de uso más acotados, más affordances de humano en el ciclo, un enmarque más honesto, son un intento de alinear el nivel operativo con la capacidad.
La lección es concreta. Elige el nivel de autonomía que tu sistema pueda sostener en tu tarea real más difícil, no en tu benchmark más fácil. Diseña los roles, la supervisión y las rutas de escalación para ese nivel. Si quieres marketing de nivel 5, construye un sistema de nivel 5; si tienes un sistema de nivel 3, comercialízalo como tal.
Cursor 2.0 y el flujo de trabajo respaldado por hardware
Cursor 2.0 salió en febrero de 2026 y resolvió silenciosamente uno de los problemas más persistentes con la programación multiagente: el conflicto de espacio de trabajo. Los agentes en segundo plano de Cursor ahora corren en VMs en la nube, cada uno en su propio git worktree, con el IDE capaz de coordinar hasta ocho en paralelo.
El detalle arquitectónico que importa: cada agente tiene su propio sistema de archivos. Sin árbol de trabajo compartido significa sin conflictos de fusión a mitad de edición, sin "el agente A sobrescribió los cambios del agente B", sin ejecuciones de prueba inestables porque dos agentes estaban tocando los mismos archivos. Cuando un agente termina, su rama puede ser revisada y fusionada como cualquier otro PR. Cuando algo sale mal, descartas el worktree.
Esto es aislamiento respaldado por hardware en el mismo sentido en que las máquinas virtuales dieron aislamiento de procesos en los años 2000. Las cercas de los agentes ya no son "prometemos no pisarnos unos a otros"; son "el sistema operativo literalmente no nos lo permitirá".
Por qué esto importa para la taxonomía de Cemri: el aislamiento por hardware elimina toda una clase de fallas de desalineación entre agentes. El estado permanece dentro del worktree. Los efectos secundarios permanecen dentro de la VM. El orquestador (Cursor mismo, o el usuario) ve solo el diff que cada agente produce. La verificación de aceptación es estructural (¿pasa el PR el CI?) en lugar de conversacional (¿afirma este agente que el trabajo está hecho?).
Los profesionales que corren Cursor 2.0 junto con Claude Code de Anthropic, Codex CLI de OpenAI y otras herramientas de agentes paralelos se han asentado en un patrón: generar de tres a ocho agentes en tareas independientes, monitorear su progreso a través de un panel unificado, fusionar los aciertos, descartar las pérdidas. El modelo de costos se acerca más a "alquilar un contratista junior por una hora y media" que a "hacerle una pregunta a un chatbot". El modelo de salida se acerca más a una revisión de PR en GitHub que a un autocompletado de chat.
Anysphere (Cursor), Bolt, Lovable y v0 dentro de Vercel ahora todos están ejecutando variantes de este ciclo internamente. Las empresas que envían más código impulsado por agentes son las empresas que construyeron primero el aislamiento del espacio de trabajo.
Diseñar roles para compañeros de equipo de IA
Una vez que aceptas que la falla multiagente es un problema de diseño organizacional, las decisiones de diseño que tomas comienzan a parecerse a la gestión clásica. Cada rol de agente necesita cuatro artefactos.
Una responsabilidad acotada. Una oración: qué es lo que este agente posee y qué no. Un agente "investigador" que también escribe prosa son dos agentes con un solo abrigo. Sepáralos.
Un informe de entrada estructurado. No "ve a investigar X". Una plantilla que complete: la pregunta, el contexto previo que el agente debe asumir, el formato de la salida esperada, las restricciones (tiempo, tokens, herramientas), las preferencias de fuente. Este es el equivalente para agentes de un informe de proyecto.
Criterios de aceptación definidos. ¿Cómo se ve "hecho"? A menudo esto es un esquema (la salida debe validar contra este tipo de Zod) o una verificación determinista (el PR debe pasar estos tres archivos de prueba). Donde las verificaciones deterministas no están disponibles, un agente revisor separado corre contra una rúbrica explícita.
Una ruta de escalación. Cuando el agente se atasca, ¿qué hace? Predeterminados razonables: hacerle al orquestador una pregunta aclaratoria estructurada, elevar una excepción marcada a un humano, abortar con un error tipado. El predeterminado equivocado es "seguir adelante e improvisar". Ahí es de donde viene el éxito alucinado.
Aplica los modos de falla de Cemri uno a la vez y estos cuatro artefactos cubren la mayoría de ellos. La ambigüedad de roles muere con la responsabilidad acotada. La ambigüedad de estado muere con el informe estructurado. Los vacíos de rendición de cuentas mueren con los criterios de aceptación. La sobrecarga de coordinación baja porque el agente no necesita negociar; tiene un informe y una rúbrica. La deriva de la especificación baja porque la especificación está capturada en el esquema, no en intuiciones.
La parte no obvia: escribe el rol como escribirías una descripción de trabajo para un contratista, no un prompt para un chatbot. Los contratistas son el modelo mental correcto. Tienen un informe, entregan una salida, no necesitan conocer todo el contexto de tu empresa, y los despides si siguen incumpliendo la especificación.
El manual multiagente del fundador
Aquí está la versión práctica, destilada de la reseña de Anthropic, el paper de Cemri, los postmortems de Devin y los datos del flujo de trabajo de Cursor 2.0.
Comienza en el nivel 2 o 3, no en el nivel 5. La capacidad es frágil bajo cambios de distribución. Incluso si tu benchmark dice nivel 4, tu tarea real más difícil suele ser un nivel más abajo. Apunta al nivel que tu tarea más difícil pueda sostener.
Usa orquestador-trabajador, no peer-to-peer. Un agente es dueño del estado compartido. Los trabajadores reciben informes acotados. Colaboración acotada solo en junturas cuidadosamente diseñadas. Sin chats grupales.
Define un rol de agente a la vez. Resiste el impulso de diseñar un sistema de cinco agentes en una pizarra antes de que nada de eso se envíe. Envía un orquestador y un trabajador. Obsérvalo durante una semana. Agrega el siguiente trabajador cuando hayas visto fallar al primero y lo hayas arreglado.
Escribe el informe como una descripción de trabajo. Responsabilidad, entradas, criterios de aceptación, escalación. Si no puedes describir el rol en cuatro secciones cortas, el rol no está listo para enviarse.
Instrumenta con trazas completas. Cada acción del agente, cada llamada a herramienta, cada salida intermedia. No puedes depurar sistemas multiagente leyendo la salida final. El bug está casi siempre corriente arriba.
Presupuesta para un costo de tokens 15x. El sistema de investigación de Anthropic usó aproximadamente 15 veces los tokens de una base de un solo agente. Planifica en consecuencia. Si tu economía unitaria se rompe a 15x, multiagente es el patrón equivocado para esa funcionalidad.
Mantén a un humano en el ciclo en acciones consecuentes. "Consecuente" generalmente significa: escribe en un sistema orientado al cliente, envía una comunicación externa, gasta dinero, elimina datos, modifica un recurso relevante para la seguridad. La revisión humana cuesta segundos; su ausencia puede costar meses.
Construye el aislamiento del espacio de trabajo antes de la flota de agentes. La lección de Cursor se generaliza. Git worktrees para código, transacciones de base de datos acotadas para datos, VMs dedicadas para trabajo que toca el entorno. El aislamiento es más barato que la coordinación.
Haz un postmortem en cada falla durante los primeros 90 días. Etiqueta cada falla contra la taxonomía de Cemri. Los patrones emergen rápido. La tercera falla de "el agente rehízo trabajo terminado" es la señal de que tus condiciones de terminación necesitan ajustarse.
Nada de esto es exótico. Es el mismo manual que un líder de ingeniería competente usa para incorporar un nuevo equipo de contratistas. La razón por la que multiagente funciona es que es el mismo problema con un ciclo de retroalimentación más ajustado.
Hacia dónde se dirige esto
Los próximos 12 a 18 meses tratan sobre convertir estos patrones en infraestructura. Algunos hilos para observar.
Protocolos agente-a-agente. El protocolo A2A de Google, la convención AGENTS.md que emerge en herramientas de IDE y CLI, y varios borradores de interoperabilidad en grupos de trabajo son un intento de estandarizar cómo los agentes se descubren entre sí, intercambian descripciones de capacidades y se autentican. (La visión general de Anthropic sobre la construcción de agentes apunta en esta dirección.) El punto es hacer que los patrones orquestador-trabajador sean componibles entre proveedores, en lugar de estar atados al SDK de un solo proveedor.
Autorización por tokens de capacidad. Hoy, la mayoría de los agentes heredan las credenciales completas del usuario que los lanzó. Esa es una mala idea para el nivel 3 y superior. Los tokens de capacidad, estrechos, acotados en el tiempo, limitados a llamadas a herramientas y recursos específicos, son la forma en que los agentes obtendrán los permisos que realmente necesitan sin los que no necesitan. Espera que esto llegue a los SDKs de producción en 2026.
Identidades de agente verificadas. Cuando los agentes comiencen a llamar a otros agentes a través de fronteras organizacionales, el lado receptor necesita saber qué está llamando. Las identidades firmadas de agentes, la atestación de entrenamiento y configuración, y los formatos de identidad entre proveedores se están prototipando ahora. El modelo se acerca más a la transparencia de certificados que a OAuth.
Mejor evaluación. SWE-bench, MLE-bench, GAIA y suites similares se han extendido lo suficiente como para que los modelos de frontera las saturen. La próxima generación de evals medirá cosas que los benchmarks históricamente han esquivado: finalización de tareas a largo plazo, cumplimiento sostenido de políticas, recuperación de fallas, costo por éxito. Espera que la "confiabilidad de agentes" se convierta en una propiedad medible de la misma manera que el "tiempo de actividad" lo hizo para los servicios.
Etiquetado estandarizado de fallas. Cemri et al. le dieron al campo una taxonomía. El siguiente paso natural es herramientas que etiqueten trazas contra esa taxonomía automáticamente, de la manera en que Sentry etiqueta excepciones. Los fundadores que configuren esto temprano depurarán sus sistemas de agentes un orden de magnitud más rápido que los que no lo hagan.
El trabajo aún está en pleno vuelo. Ninguno de estos hilos está resuelto. Pero la forma de la próxima fase es visible: menos artesanía de prompts, más ingeniería de sistemas; menos "¿qué puede hacer el modelo?", más "¿qué rol necesito cubrir y cómo se ve hecho?". Los equipos que prosperen serán los que traten a los agentes como compañeros de equipo, con el mismo rigor que aplicarían a cualquier nueva contratación. Roles, informes, criterios de aceptación, rutas de escalación. Los artefactos aburridos de las organizaciones competentes.
Preguntas frecuentes
¿Todo equipo debería construir sistemas multiagente?
No. La mayoría de las funcionalidades de IA en producción aún funcionan mejor como configuraciones de un solo agente con buenas herramientas. Multiagente se gana su lugar cuando la tarea es genuinamente descomponible (subtareas independientes que pueden correr en paralelo), el valor por tarea justifica el costo de tokens 15x, y la confiabilidad ha sido probada primero en la capa de un solo agente. Un sistema fallido de un solo agente no se convierte en un sistema multiagente funcional. Generalmente se convierte en un sistema fallido más caro.
¿Cuál es el patrón multiagente listo para producción más simple?
Orquestador con dos trabajadores, ambos con criterios de aceptación deterministas. El orquestador es dueño del estado compartido. Los trabajadores reciben informes acotados. Las salidas validan contra un esquema antes de que el orquestador las acepte. Esto es suficiente para capturar la mayor parte del beneficio de la descomposición sin la sobrecarga de coordinación de equipos más grandes. Escala el conteo de trabajadores solo después de que esta base sea confiable.
¿Vale la pena el costo de tokens 15x?
Depende del valor de la salida. El sistema de investigación de Anthropic tiene sentido económico porque la alternativa es un investigador humano gastando horas en la misma tarea. Para trabajo de bajo valor y alto volumen (clasificación de intención, resumen simple, extracción rutinaria), un costo de tokens 15x casi nunca vale la pena; usa una configuración de un solo agente o un modelo más pequeño. Para trabajo de alto valor y bajo volumen (investigación profunda, tareas de codificación complejas, análisis multi-fuente), las cuentas a menudo dan.
¿Cómo sé cuándo lanzar un subagente versus usar un prompt más largo?
Lanza un subagente cuando el trabajo tiene un requerimiento de contexto diferente al de la tarea padre. Si la subtarea necesita herramientas diferentes, un system prompt diferente, o contexto que contaminaría la ventana del padre, dale su propio agente. Si la subtarea es "solo haz esta siguiente cosa" y comparte el contexto del padre, un prompt más largo o una llamada a herramienta es más barato y más confiable. La pregunta decisiva suele ser sobre el contexto: ¿querría tener este contexto en la memoria de mi orquestador después de que termine la subtarea?
¿Cuál es la diferencia entre un agente y una herramienta de IA?
Una herramienta es una sola capacidad determinista que el modelo puede llamar (una búsqueda web, una consulta a base de datos, un formateador de código). Un agente es un ciclo: observa, planifica, llama herramientas, evalúa el resultado, y decide qué hacer a continuación, a menudo a través de muchos turnos. Las herramientas son sustantivos; los agentes son verbos. Un agente bien construido usa muchas herramientas. Una "herramienta" que llama a un modelo internamente y corre su propio ciclo es, en la práctica, un agente.
Reflexiones finales
El enmarque más útil que he escuchado para el momento actual vino de un líder de ingeniería que dirigía un despliegue de programación multiagente: "Dejamos de pensar en los agentes como inteligentes y comenzamos a pensar en ellos como juniors con resistencia infinita". Los juniors necesitan roles claros, informes escritos, criterios de aceptación definidos y una ruta de escalación. Cometen errores predecibles. Mejoran con retroalimentación. Fallan cuando nadie es dueño de su trabajo.
Ese es el cambio de diseño organizacional escondido dentro de la conversación multiagente. Los problemas difíciles de 2025-2026 ya no son problemas de capacidad. Los modelos son lo suficientemente buenos. Los problemas difíciles son los mismos que siempre han hecho difícil dirigir equipos de humanos: quién es dueño de qué, quién mantiene el estado, quién verifica el trabajo, quién es responsable cuando sale mal. La taxonomía de Cemri, el marco de autonomía, el patrón orquestador-trabajador, el postmortem de Devin, el modelo de aislamiento de Cursor: todos son respuestas a versiones de la misma pregunta.
Si eres un fundador enviando un producto impulsado por agentes en 2026, los artefactos aburridos son el apalancamiento. Escribe los roles. Escribe los informes. Define hecho. Construye el aislamiento del espacio de trabajo. Instrumenta las trazas. Mantén al humano en el ciclo donde cuenta. Los equipos que hagan esto se verán más lentos por dos meses y más rápidos por dos años. Los equipos que se lo salten pasarán el resto del año etiquetando modos de falla contra una taxonomía que alguien más ya escribió.
Los agentes son compañeros de equipo ahora. Gestionálos como tales.