Una matriz 7×6 para clasificar agentes LLM sin ambigüedad

El mismo patrón Orchestrator-Workers puede implementar tres arquitecturas radicalmente distintas: Plan-and-Execute, Hierarchical Delegation o Adversarial Verification. Cada una falla de manera diferente. Cada una exige decisiones de diseño opuestas. Y sin embargo, los marcos de referencia actuales no permiten distinguirlas con precisión. Ese es el problema concreto que aborda arXiv:2605.13850, publicado el pasado 16 de mayo.

Los autores señalan una fractura de fondo en cómo la industria y la academia describen los agentes basados en LLMs: las guías de Anthropic, Google o LangChain se centran en la topología de ejecución —cómo fluyen los datos entre nodos—, mientras que los trabajos de ciencias cognitivas atienden a la función cognitiva —qué hace el agente—. Ninguno de los dos ejes, tomado solo, basta para caracterizar un sistema de forma unívoca. La propuesta es combinarlos en una clasificación bidimensional.

Qué propone el marco

El framework cruza dos dimensiones independientes:

• Eje de función cognitiva — siete categorías: Context Engineering, Memory, Reasoning, Action, Reflection, Collaboration y Governance.
• Eje de topología de ejecución — seis arquetipos estructurales: Chain, Route, Parallel, Orchestrate, Loop y Hierarchy.

El producto es una matriz 7×6 que los autores analizan sistemáticamente para identificar 27 patrones nombrados, de los cuales 13 llevan nombres originales introducidos en este trabajo. La clave metodológica es demostrar la ortogonalidad de los dos ejes: una misma topología puede albergar funciones cognitivas distintas, y una misma función cognitiva puede implementarse sobre topologías diferentes. Sin esa ortogonalidad, la matriz sería redundante; con ella, resulta informativa.

El paper define con detalle ocho patrones representativos y valida la cobertura descriptiva del marco sobre cuatro dominios reales: préstamos financieros, atención sanitaria, generación de código y otro sector que no se especifica en el resumen. La intención es demostrar que el esquema no es solo teórico, sino que mapea sistemas que ya existen en producción.

Por qué importa para quienes construyen agentes

La utilidad práctica no es menor. Cuando un equipo de ingeniería decide entre un bucle de reflexión y una verificación adversarial, está tomando una decisión de arquitectura con consecuencias directas en los modos de fallo, la latencia y el coste de depuración. Si el vocabulario disponible no permite distinguir esas opciones con claridad, las discusiones de diseño se vuelven imprecisas y las revisiones de código, difíciles de razonar.

En el ecosistema Claude, esto es especialmente relevante. Claude Code ya soporta subagentes, hooks y skills que permiten construir topologías complejas —cadenas de subagentes orquestados, bucles de reflexión con PostToolUse hooks, pipelines paralelos vía MCP servers—. Tener un marco de referencia que nombre con precisión esas configuraciones facilita tanto la documentación interna como la comunicación entre equipos que trabajan en integraciones a medida.

El trabajo también tiene implicaciones para quienes evalúan agentes. Los modos de fallo difieren según el patrón: un agente en topología Loop con función Reflection puede entrar en ciclos degenerativos; uno en topología Parallel con función Action puede generar efectos secundarios concurrentes difíciles de revertir. Clasificar correctamente un sistema es el primer paso para anticipar sus puntos débiles.

Limitaciones que conviene tener en cuenta

El paper es un preprint sin revisión por pares en el momento de su publicación. La taxonomía propuesta es descriptiva, no prescriptiva: el marco clasifica, pero no dictamina qué patrón es mejor para cada caso de uso. Además, 13 de los 27 patrones llevan nombres acuñados por los propios autores, lo que significa que parte del vocabulario aún no tiene adopción en la comunidad. Eso puede cambiar si el trabajo gana tracción, pero de momento es terminología nueva que habrá que aprender si se quiere usar el marco con interlocutores externos.

Con todo, es uno de los intentos más sistemáticos que hemos visto de resolver la ambigüedad terminológica que rodea al diseño de agentes LLM. Si los patrones nombrados aquí se consolidan como referencia compartida, el coste de onboarding en proyectos de agentes complejos podría reducirse de forma apreciable. Eso no es poco.