Inside the Scaffold: A Source-Code Taxonomy of Coding Agent Architectures

1. Problem Statement

While Large Language Model (LLM)-based coding agents (e.g., Aider, SWE-agent, OpenHands) have demonstrated significant capabilities in bug localization, patch generation, and testing, the scaffolding code surrounding the LLM remains poorly understood.

• The Gap: Existing research classifies agents based on abstract capabilities (e.g., "tool-using," "planning," "reflective"). These high-level taxonomies fail to distinguish between architecturally distinct systems that share the same capabilities but differ fundamentally in control flow, state management, and resource handling.
• The Consequence: Without a source-code-level understanding, researchers cannot attribute behavioral differences to specific architectural choices (confounding scaffold design with model capability), and practitioners lack a systematic map of the design space to build better agents.
• The Need: There is a critical need for an architecture-aware taxonomy grounded in implementation details rather than conceptual descriptions to enable controlled experiments and better evaluation metrics.

2. Methodology

The study employs a qualitative, source-code-level architectural analysis of 13 open-source coding agent scaffolds.

• Corpus Selection: 13 agents were selected based on SWE-bench evaluation, GitHub adoption (stars), and citation in recent surveys. The selection includes both interactive CLI tools (e.g., Aider, Cline) and automated SWE-bench agents (e.g., SWE-agent, OpenHands).
  • Exclusion Criteria: Proprietary agents (e.g., GitHub Copilot), agents without readable source code, and near-duplicates were excluded.
• Data Source: Analysis was performed on pinned commit hashes to ensure reproducibility, covering agents released between June 2023 and March 2025.
• Analytical Framework:
  • Dimensions: The analysis covers 12 dimensions organized into three architectural layers:
    1. Control Architecture: How the agent decides what to do next (loop topology, driver, implementation).
    2. Tool & Environment Interface: How the agent interacts with code and execution (tool sets, edit formats, discovery, context retrieval, isolation).
    3. Resource Management: How the agent handles constraints (state management, context compaction, multi-model routing, persistent memory).
  • Procedure: A structured template was used to extract observations, classify them against dimensions, and provide evidence (file paths and line numbers).
  • Tool Counting: Two methods were used: Registration Count (how the LLM sees tools) and Capability Category Count (functional grouping: read, search, edit, execute).

3. Key Contributions

1. First Source-Code Taxonomy: The first comparative architectural study of coding agents at the implementation level, providing a reusable reference grounded in specific code locations.
2. Spectral vs. Categorical Insight: The empirical finding that scaffold architectures are better characterized as compositions of loop primitives along continuous spectra rather than instances of discrete types.
3. Evidence Base: A detailed dataset of architectural observations pinned to specific commits, enabling independent verification and future controlled experiments.

4. Key Results & Findings

A. Control Architecture (Layer 1)

• Loop Primitives: Agents do not fit into single categories. Instead, they compose five loop primitives: ReAct, generate-test-repair, plan-execute, multi-attempt retry, and tree search.
  • Example: Moatless Tools decouples the inner agent (ActionAgent) from the outer control flow, allowing it to be driven by either a sequential ReAct loop or a full Monte Carlo Tree Search (MCTS) without changing the agent code.
  • Example: Agentless uses a fixed pipeline with no feedback loop, while Moatless Tools uses full MCTS with reward backpropagation.
• Loop Driver: A fundamental distinction exists between User-driven (e.g., Aider, where the user selects files) and LLM-driven (e.g., OpenHands, where the LLM navigates). User-driven agents sidestep the bug localization bottleneck but rely on human input.
• Implementation: Control flows vary from imperative while loops (most common) to recursion (Cline), graph-based state machines (Prometheus), and exception-based signaling (mini-swe-agent).

B. Tool & Environment Interface (Layer 2)

• Tool Sets: Tool counts range from 0 (Aider, where the user drives navigation) to 37 (Moatless Tools). However, capability categories converge: nearly all LLM-driven agents possess tools for reading, searching, editing, and executing code.
• Edit Formats: There is a convergence toward string replacement (exact string matching) as the most reliable format for LLM-generated patches, moving away from line-number or unified-diff formats.
• Context Retrieval: Strategies diverge significantly. Some agents (e.g., SWE-agent) rely on the LLM to issue shell commands (grep, find). Others invest in scaffold-side understanding, using ASTs (AutoCodeRover), Knowledge Graphs (Prometheus with Neo4j), or PageRank-based dependency graphs (Aider).
• Execution Isolation: Approaches range from no sandboxing (relying on user supervision) to Docker containers, shadow git repositories, and in-memory "shadow mode" execution (Moatless Tools) to avoid filesystem costs during tree search.

C. Resource Management (Layer 3)

• State Management: Strategies range from destructive overwriting (Aider) to event sourcing (OpenHands, which preserves immutable event streams) and tree-structured state (for MCTS agents).
• Context Compaction: Agents face the "token snowball" effect. Strategies include:
  • Prevention: Structural bounding (e.g., Prometheus resets messages per graph node).
  • Cure: LLM-based summarization (e.g., Aider, OpenHands).
  • Hybrid: Cline allows the LLM to initiate compaction.
• Multi-Model Routing: While some agents use a single model, many route tasks to different models based on cost or capability (e.g., using a "weak" model for summarization and a "strong" model for reasoning). Codex CLI uniquely uses a separate "Guardian" model to evaluate the safety of tool calls.
• Persistent Memory: A clear divide exists between benchmark agents (stateless, no cross-task learning) and interactive CLI agents (which persist project conventions, rules, and session history).

D. Cross-Cutting Themes

• Sampling vs. Iteration: Agents either generate multiple independent attempts and vote (sampling) or refine a single attempt via feedback loops (iteration).
• Sub-Agent Delegation: Emerging capability where agents spawn sub-agents, implemented via explicit tool calls, role-based scaffolding, or event sourcing.
• IDE Integration: Cline is unique as an IDE extension, accessing native diagnostics and terminal outputs unavailable to CLI agents, though this creates platform lock-in.

5. Significance and Implications

• For Researchers: The taxonomy provides the vocabulary to design controlled experiments. Researchers can now isolate variables (e.g., "compare agents with identical tool sets but different loop strategies") to determine if performance differences stem from the scaffold or the model.
• For Practitioners: The study reveals that composability is key. Designers can layer primitives (e.g., adding a tree search to a ReAct loop) rather than rebuilding entire systems. It highlights that "converging" dimensions (like tool categories) are solved problems, while "diverging" dimensions (like context compaction and state management) are active research frontiers.
• For Evaluation: Current benchmarks (like SWE-bench) confound scaffold design with model capability. This taxonomy enables architecture-aware evaluation metrics that link internal components (e.g., context compaction strategy) to observable outcomes (e.g., token cost, success rate).
• Ecosystem Maturity: The field is rapidly innovating but lacks standardized abstractions. Fork-based reuse is common, and while tool capabilities are converging, tool interfaces remain fragmented.

In conclusion, the paper argues that the "scaffold" is not merely a wrapper but the primary determinant of an agent's behavior, cost, and reliability. Understanding these source-code-level architectures is essential for the next generation of effective coding agents.