Two Axes for Reading LLM Agent Design: What the Agent Does and How It Runs

This post looks at the arXiv paper "A Two-Dimensional Framework for AI Agent Design Patterns: Cognitive Function and Execution Topology." The paper addresses a simple but important problem in LLM agent discussions: many frameworks describe agents from only one angle, even though real systems differ both in what kind of reasoning role they perform and in how execution is organized. [S1] [S1]

Paper overview: what it is about

The paper is an arXiv work on LLM agent design frameworks. Its starting point is that existing descriptions of agent architectures often come from two separate traditions: industry-oriented guides that emphasize execution structure, and cognitive-science-style surveys that emphasize mental or functional roles. According to the abstract, the authors argue that neither view alone is enough to clearly distinguish architecturally different systems. [S1]

Sources: [S1]

Core idea: cognitive function and execution topology

The central proposal is to read agent systems along two axes. The first is cognitive function: what the agent is doing at a conceptual level, such as planning, delegating, critiquing, or deciding. The second is execution topology: how information and control move through the system, for example through orchestrated workers or other flow structures. The paper's key claim is that these axes should be treated separately because the same execution pattern can support different functional roles, and the same functional goal can be implemented through different execution structures. In plain terms, asking only "what is the agent trying to do?" or only "how are the components wired together?" gives an incomplete picture. [S1]

Sources: [S1]

How this differs from existing approaches

The paper's main difference is not a new benchmark or a single agent recipe, but a different lens for classification. The abstract explicitly contrasts topology-focused industry guides with function-focused cognitive surveys, and says that one axis alone cannot disambiguate distinct systems. It even gives a concrete example: the same Orchestrator-Workers topology can implement very different patterns such as Plan-and-Execute, Hierarchical Delegation, or adversarial-style setups. [S1]

This matters when reading recent agent papers. For example, SPIN is framed around planning and execution for industrial tasks, with a wrapper that combines validated DAG planning and prefix-based execution control. That is a strong example of execution structure being central to system behavior. [S6] By contrast, the tool-use paper on model-adaptive tool necessity focuses on a decision problem: when an LLM should answer directly and when it should invoke a tool. That is closer to a cognitive-function question about judgment under uncertainty. [S4] The LOOP Skill Engine, meanwhile, highlights one-shot recording and deterministic replay for repetitive tasks, which again foregrounds a particular execution setup rather than only a high-level reasoning role. [S11]

My interpretation is that the two-axis framework helps place these papers on a shared map. Instead of treating all of them as just "agent systems," it becomes easier to ask whether a paper mainly changes the agent's functional role, its execution topology, or both. [S1][S4][S6][S11]

Sources: [S1], [S6], [S11], [S4]

Practical relevance: where this framing helps

This framework is useful in practical design discussions because real agent systems are rarely defined by one dimension alone. In industrial planning settings, SPIN shows why execution topology matters: if planning outputs are structurally invalid or unnecessarily long, downstream execution becomes brittle and costly. A two-axis view helps separate the planning function from the control structure used to validate and execute plans. [S6]

For repetitive automation, the LOOP Skill Engine points to another design situation: the task may not require open-ended reasoning every time, but it does require a reliable execution pattern. In that context, distinguishing the function of the agent from the topology of deterministic replay can clarify why the system behaves differently from a more free-form LLM loop. [S11]

For tool use, the model-adaptive tool necessity paper shows that deciding whether a tool is needed is not a trivial yes-or-no property of the task. The abstract argues that tool necessity depends on the model's own capabilities and on nuanced real-world cases. That makes tool invocation a design problem about cognitive judgment, not just about attaching tools to an execution pipeline. [S4]

Taken together, these examples suggest that the proposed framework can help practitioners compare systems more carefully: one paper may innovate in planning structure, another in replay-based execution, and another in the decision logic around tool use. [S4][S6][S11]

Sources: [S6], [S11], [S4]

Limitations and open questions

The paper's abstract makes a clear conceptual argument, but from the summary alone there are still open questions about how far the framework can go in practice. One question is whether all real systems can be cleanly separated into cognitive function and execution topology, since many agent designs tightly couple the two. [S1]

A second question is granularity. The tool-necessity paper suggests that even a seemingly narrow function like "decide whether to use a tool" depends on model-specific capability gaps and nuanced task conditions. That implies the cognitive-function axis may itself need careful subcategories if it is to be useful beyond high-level labels. [S4]

A third question is how the framework handles systems where execution constraints strongly shape the function. SPIN shows that validation and execution control can materially affect what plans are even acceptable. In such cases, topology is not just an implementation detail; it partly defines the agent's effective behavior. [S6]

So the framework looks helpful as a reading and comparison tool, but the abstract alone does not yet tell us how consistently different researchers would classify complex hybrid systems. That is a limitation of what can be concluded from the available source summary. [S1]

Sources: [S1], [S4], [S6]

One-paragraph takeaway

This arXiv paper proposes a simple but useful shift in how to read LLM agent research: do not describe an agent only by its reasoning role or only by its execution flow. Instead, separate cognitive function from execution topology. The paper's argument is that many current frameworks emphasize just one of these axes, which makes different systems look more similar than they really are. Read alongside work on structured planning, deterministic replay, and adaptive tool use, the proposal works as a practical map for comparing agent designs with more precision. [S1][S4][S6][S11]

Sources: [S1]

---

One-line takeaway: The paper argues that LLM agents should be understood along two separate axes—cognitive function and execution topology—because one axis alone cannot clearly distinguish many real systems. [S1] [S1]

Short summary: This arXiv paper argues that LLM agent frameworks are easier to compare when we separate what an agent does from how it executes. That two-axis view also helps connect recent work on planning structure, tool-use decisions, and repetitive task automation. [S1][S4][S6][S11]

Sources and references: - [S1] cs.AI updates on arXiv.org - A Two-Dimensional Framework for AI Agent Design Patterns: Cognitive Function and Execution Topology - URL: https://arxiv.org/abs/2605.13850 - [S4] cs.AI updates on arXiv.org - Model-Adaptive Tool Necessity Reveals the Knowing-Doing Gap in LLM Tool Use - URL: https://arxiv.org/abs/2605.14038 - [S6] cs.AI updates on arXiv.org - SPIN: Structural LLM Planning via Iterative Navigation for Industrial Tasks - URL: https://arxiv.org/abs/2605.14051 - [S11] cs.AI updates on arXiv.org - Good to Go: The LOOP Skill Engine That Hits 99% Success and Slashes Token Usage by 99% via One-Shot Recording and Deterministic Replay - URL: https://arxiv.org/abs/2605.14237

Internal link ideas: - A beginner's guide to LLM agent architectures and orchestration patterns - How tool-use decisions change LLM agent reliability - What planning-execution separation means in industrial AI agents

LLM agents #agent architecture #cognitive function #execution topology #arXiv #paper brief

---

Note AI-assisted content
This post was drafted with AI (gpt-5.4) using source-grounded inputs.
Please review the citations and original links below.