A 7×6 Matrix to Classify LLM Agents Without Ambiguity

The same Orchestrator-Workers pattern can implement three radically different architectures: Plan-and-Execute, Hierarchical Delegation, or Adversarial Verification. Each fails in different ways. Each demands opposite design decisions. Yet current frameworks cannot distinguish them with precision. That is the concrete problem addressed by arXiv:2605.13850, published on May 16.

The authors point to a fundamental split in how industry and academia describe LLM-based agents: guidance from Anthropic, Google, and LangChain focuses on execution topology (how data flows between nodes), while cognitive science research attends to cognitive function (what the agent does). Neither axis alone is sufficient to characterize a system uniquely. The proposal is to combine them into a two-dimensional classification.

What the framework proposes

The framework crosses two independent dimensions:

• Cognitive function axis — seven categories: Context Engineering, Memory, Reasoning, Action, Reflection, Collaboration, and Governance.
• Execution topology axis — six structural archetypes: Chain, Route, Parallel, Orchestrate, Loop, and Hierarchy.

The product is a 7×6 matrix that the authors systematically analyze to identify 27 named patterns, of which 13 carry original names introduced in this work. The methodological key is demonstrating the orthogonality of the two axes: the same topology can host different cognitive functions, and the same cognitive function can be implemented over different topologies. Without that orthogonality, the matrix would be redundant; with it, it becomes informative.

The paper defines eight representative patterns in detail and validates the descriptive coverage of the framework across four real-world domains: financial lending, healthcare, code generation, and an unspecified sector. The intent is to demonstrate that the scheme is not merely theoretical, but maps systems already running in production.

Why it matters for those building agents

The practical utility is significant. When an engineering team chooses between a reflection loop and adversarial verification, it is making an architectural decision with direct consequences for failure modes, latency, and debugging cost. If the available vocabulary cannot distinguish those options clearly, design discussions become imprecise and code reviews become hard to reason through.

In the Claude ecosystem, this is especially relevant. Claude Code already supports subagents, hooks, and skills that enable building complex topologies (chains of orchestrated subagents, reflection loops with PostToolUse hooks, parallel pipelines via MCP servers). Having a reference framework that names those configurations precisely facilitates both internal documentation and communication between teams working on custom integrations.

The work also has implications for those evaluating agents. Failure modes differ by pattern: an agent in Loop topology with Reflection function can enter degenerative cycles; one in Parallel topology with Action function can generate concurrent side effects that are hard to undo. Correctly classifying a system is the first step toward anticipating its weak points.

Limitations worth considering

The paper is a preprint without peer review at the time of publication. The proposed taxonomy is descriptive, not prescriptive: the framework classifies, but does not dictate which pattern is best for each use case. Furthermore, 13 of the 27 patterns carry names coined by the authors themselves, meaning part of the vocabulary still lacks community adoption. That could change if the work gains traction, but for now it is new terminology that must be learned if you want to use the framework with external collaborators.

Still, it is one of the most systematic attempts we have seen to resolve the terminological ambiguity surrounding LLM agent design. If the patterns named here become established as a shared reference, the cost of onboarding on complex agent projects could decrease noticeably. That is no small thing.