Comparative Architecture Analysis

64.1 Overview and Motivation

The preceding chapters have examined seventeen LLM-powered evolutionary systems individually, each presenting a distinct combination of population management, mutation strategy, evaluation pipeline, and meta-level adaptation. This chapter steps back from single-system analysis to conduct a rigorous cross-system architectural comparison. The goal is threefold: (1) identify the shared structural skeleton that unites these systems despite surface-level diversity, (2) map the specific design trade-offs that differentiate them, and (3) extract actionable insights about which architectural choices correlate with which capability profiles.

Comparative architecture analysis is essential for a maturing field. When individual system papers emphasize novelty, the shared foundations and recurring design patterns can become obscured. Conversely, genuine innovations risk being overlooked when buried within familiar-looking pipelines. By decomposing each system into its constituent architectural layers and comparing layer-by-layer, we can distinguish true innovation from engineering variation and identify the design decisions that most strongly predict system behavior.

64.2 The Shared Architectural Skeleton

Despite spanning five organizational categories — general-purpose frameworks, self-improving agents, specialized solvers, benchmark systems, and competition applications — all seventeen systems converge on a recognizable core loop. This convergence is not coincidental; it reflects the fundamental structure of search-based optimization, adapted for the specific affordances of large language models as variation operators.

The shared skeleton consists of six layers, each present in every system though implemented with varying complexity:

Every surveyed system instantiates this skeleton. What distinguishes them is the richness of each layer's implementation and, critically, which feedback channels are closed. A system like Darwinian Evolver implements all six layers but with minimal population structure and no meta-adaptation. AlphaEvolve implements all layers with high complexity at Google scale but without prompt co-evolution. ShinkaEvolve closes all three feedback channels, including meta-level prompt adaptation. These choices — not the loop itself — determine each system's capability profile.

64.3 Layer-by-Layer Comparative Analysis

64.3.1 Layer 1: Orchestration Controller

The orchestration layer manages experiment lifecycle, coordinates the evolutionary loop, handles checkpointing, and enforces budget constraints. While functionally similar across systems, orchestrators vary along two dimensions: concurrency model and granularity of control.

The key architectural divergence is between synchronous generation-based systems (OpenEvolve, LLM4AD, Darwinian Evolver), where all candidates in a generation are produced and evaluated before the next begins, and asynchronous streaming systems (ShinkaEvolve, SkyDiscover), where candidates are generated and evaluated continuously with population updates occurring as results arrive. ShinkaEvolve reports a 5–10× throughput improvement from this asynchronous design. The trade-off is implementation complexity: asynchronous systems must handle race conditions in population updates and maintain coherent selection pressure despite variable evaluation latency.

64.3.2 Layer 2: Population Management

Population management is the layer with the greatest architectural divergence across systems. Four distinct population models appear in the surveyed literature, each encoding different assumptions about what a "good" collection of candidate solutions looks like.

MAP-Elites with islands (AlphaEvolve, OpenEvolve) provides the strongest quality-diversity guarantees. By discretizing a behavioral descriptor space into cells and retaining the best program per cell, MAP-Elites ensures that the population covers diverse solution strategies. However, this requires defining meaningful behavioral descriptors — a task that is straightforward for mathematical optimization (e.g., algorithm complexity, numerical precision) but difficult for open-ended software tasks. The island structure adds migration-mediated diversity, typically via ring topology where elite candidates periodically transfer between adjacent islands.

Pareto frontier management (GEPA) offers a different diversity guarantee: any candidate that is non-dominated across the objective vector survives. This is particularly natural for multi-objective optimization problems where trade-offs between competing metrics must be explicitly maintained. The mathematical formulation relies on Pareto dominance:

where $f_i(c)$ denotes the $i$-th objective value of candidate $c$, assuming all objectives are to be maximized (minimization objectives are negated). The Pareto frontier $PF$ is the set of all mutually non-dominated candidates. GEPA uses ε-greedy selection over this frontier, exploiting the best region with probability $1 - \varepsilon$ and exploring uniformly with probability $\varepsilon$.

Expanding archives (Darwin Gödel Machine) never discard candidates, allowing branching from any ancestor. This preserves full lineage information and enables the system to revisit abandoned evolutionary paths. The cost is unbounded memory growth and increasing selection complexity as the archive grows.

Flat populations (Darwinian Evolver, LLM4AD in some configurations) maintain a simple ranked list. This is the lightest-weight option: easy to implement, fast to query, and requiring no descriptor engineering. The trade-off is vulnerability to premature convergence, since no structural mechanism prevents the population from collapsing to a single basin of attraction.

64.3.3 Layer 3: Parent Selection

Parent selection determines which candidates serve as the starting point for LLM-guided mutation. The design space is richer than in classical evolutionary computation because LLMs can accept multiple parents as context, blurring the line between recombination and mutation. Seven distinct selection strategies appear across the surveyed systems:

In power-law selection (ShinkaEvolve), a parent's probability of being selected is inversely proportional to its rank $r_i$ raised to an exponent $\alpha$:

where $r_i$ is the rank of candidate $c_i$ (rank 1 = best), $N$ is the population size, and $\alpha > 0$ controls selection pressure. Higher $\alpha$ concentrates selection on top-ranked individuals; $\alpha = 0$ yields uniform selection. This offers smoother control over selection pressure than tournament selection, where pressure increases only through integer changes in tournament size $k$.

SkyDiscover/AdaEvolve introduces a distinctive approach where selection intensity is not a fixed parameter but is driven by an accumulated improvement signal $G_t$, a scale-invariant exponential moving average of squared improvements. When recent mutations produce large improvements, $G_t$ rises, causing the system to exploit more aggressively. During stagnation, $G_t$ decays, expanding exploration. This creates a self-regulating feedback loop without manual parameter tuning.

64.3.4 Layer 4: Mutation Engine

The mutation engine is where LLM-powered evolutionary systems most fundamentally depart from classical genetic programming. Instead of random syntactic perturbations, mutations are generated by LLMs that receive parent programs, evaluation feedback, and natural-language instructions. The mutation engine subsumes what would be separate mutation and recombination operators in classical evolutionary computation.

Three primary mutation modes appear across systems:

# Pseudocode — illustrative comparison of three mutation modes
# These patterns appear across multiple systems with varying implementations

# Mode 1: Diff-based mutation (AlphaEvolve, OpenEvolve, ShinkaEvolve)
# LLM generates a targeted patch to modify specific code regions
def diff_mutation(parent_code: str, feedback: str, llm: LLM) -> str:
    prompt = f"""Given this program:
{parent_code}

Evaluation feedback: {feedback}

Generate a unified diff patch to improve performance.
Output ONLY the diff, no explanation."""
    diff = llm.generate(prompt)
    return apply_diff(parent_code, diff)

# Mode 2: Full rewrite (AlphaEvolve, OpenEvolve, ShinkaEvolve)
# LLM generates complete replacement of mutable code block
def full_rewrite(parent_code: str, feedback: str, llm: LLM) -> str:
    prompt = f"""Rewrite this function to improve its performance:
{parent_code}

Evaluation feedback: {feedback}

Generate the complete improved implementation."""
    return llm.generate(prompt)

# Mode 3: Reflection-driven (GEPA, ReEvo via LLM4AD)
# LLM first analyzes diagnostics, then proposes targeted changes
def reflection_mutation(
    parent_code: str,
    side_info: dict,  # Actionable Side Information
    llm: LLM
) -> str:
    # Step 1: Reflect on diagnostic information
    reflection_prompt = f"""Analyze these evaluation diagnostics:
Score: {side_info['score']}
Error trace: {side_info.get('trace', 'none')}
Failure cases: {side_info.get('failures', [])}

What are the root causes of suboptimal performance?"""
    analysis = llm.generate(reflection_prompt)

    # Step 2: Generate improvement based on reflection
    improve_prompt = f"""Based on this analysis: {analysis}
Improve the following code:
{parent_code}"""
    return llm.generate(improve_prompt)

The critical design trade-off between diff and full-rewrite modes involves the balance between locality and creativity. Diff mutations preserve most of the parent program, making incremental improvements that are less likely to break working functionality. Full rewrites can discover fundamentally different algorithmic approaches but risk regressing on previously solved aspects. Several systems (ShinkaEvolve, OpenEvolve) adaptively adjust the ratio of diff to full-rewrite mutations based on observed success rates — a form of meta-level adaptation discussed in Section 64.3.6.

Darwinian Evolver introduces failure-case-driven mutation, where the mutation prompt includes specific test cases that the parent failed. This channels the LLM's attention toward concrete deficiencies rather than abstract improvement. The post-mutation verification step then checks whether the specific failure case is resolved before committing to full evaluation — a lightweight pre-filter that reduces wasted evaluation budget.

SkyDiscover/AdaEvolve adds meta-guided tactical injection: when global stagnation is detected, the system uses an LLM to generate high-level algorithmic directives (e.g., "switch from greedy construction to local search with perturbation") that are injected into mutation prompts. This represents an outer loop of LLM reasoning about search strategy, distinct from the inner loop of LLM-generated code mutations.

64.3.5 Layer 5: Evaluation Pipeline

All systems execute generated code in sandboxed environments with resource limits. The architecturally interesting variation lies in how systems structure evaluation and what information flows back from evaluation to mutation.

Cascade evaluation (AlphaEvolve, OpenEvolve) applies a sequence of increasingly expensive evaluation stages, discarding candidates at each stage if they fail to meet a minimum threshold. This reduces wasted computation on clearly inferior candidates:

where $C_{\text{cascade}}$ is the expected evaluation cost per candidate, $c_k$ is the cost of stage $k$, $p_j$ is the probability of passing stage $j$, and $K$ is the total number of stages. The expected savings depend on how effectively early stages filter poor candidates. If stage 1 eliminates 80% of candidates at 10% of the cost of full evaluation, the aggregate cost is approximately $0.1c_{\text{full}} + 0.2 \cdot c_{\text{full}} = 0.3c_{\text{full}}$ — a 70% reduction.

Actionable Side Information (GEPA) represents the richest feedback channel in the surveyed systems. Rather than returning only a scalar fitness score, evaluators produce structured diagnostic data — error traces, performance profiles, visualization artifacts, failure-case descriptions — that feeds directly into the mutation prompt. This converts evaluation from a scoring function into a diagnostic function, providing the LLM with actionable context for its next mutation. The source material identifies ASI as GEPA's key innovation and a first-class architectural concept rather than an optional feature.

Post-mutation verification (Darwinian Evolver) inverts the cascade pattern. Instead of filtering after full generation, it performs a quick targeted check immediately after mutation to verify that the specific deficiency motivating the mutation has been addressed. This is computationally cheaper than cascade evaluation but less general, as it tests only the targeted failure rather than overall fitness.

64.3.6 Layer 6: Meta-Level Adaptation

Meta-level adaptation — the system's ability to modify its own search strategy during a run — is the layer that most sharply differentiates recent systems from earlier approaches. Four distinct meta-adaptation mechanisms have been documented:

# Pseudocode — four meta-adaptation patterns across systems

# Pattern 1: Bandit-based model selection (ShinkaEvolve, AB-MCTS)
# Select which LLM to use for each mutation based on past success
# Standard UCB1 formulation applied to model routing
class BanditModelSelector:
    """UCB1-based selection among LLM models."""
    def select_model(self, models: list[str]) -> str:
        # UCB1 score for model m after n total trials
        # with n_m trials of model m and mean reward x_bar_m
        # UCB(m) = x_bar_m + c * sqrt(ln(n) / n_m)
        scores = {}
        n_total = sum(self.trial_counts.values())
        for m in models:
            n_m = self.trial_counts[m]
            if n_m == 0:
                return m  # try untested models first
            exploit = self.mean_rewards[m]
            explore = self.c * math.sqrt(math.log(n_total) / n_m)
            scores[m] = exploit + explore
        return max(scores, key=scores.get)

# Pattern 2: Prompt co-evolution (ShinkaEvolve v1.1)
# System prompts evolve alongside program candidates
# Successful mutations reinforce the prompt that produced them
class PromptPopulation:
    """Maintains and evolves mutation prompts based on outcomes."""
    def update(self, prompt: str, mutation_success: bool):
        # Track prompt effectiveness; successful prompts
        # receive higher selection probability in future mutations
        self.prompt_scores[prompt].update(success=mutation_success)

# Pattern 3: Learning logs (Darwinian Evolver)
# Cross-individual knowledge sharing via structured records
class LearningLog:
    """Records mutation outcomes for population-wide learning."""
    def record(self, attempted_change: str, outcome: str, success: bool):
        entry = {
            "change": attempted_change,
            "outcome": outcome,
            "success": success,
        }
        self.entries.append(entry)
        # Entries included in future mutation prompts so LLM
        # can learn from population's collective experience

# Pattern 4: Three-level hierarchical adaptation (SkyDiscover/AdaEvolve)
# Local, global, and meta-guidance adaptation coordinated
# via accumulated improvement signal
class HierarchicalAdaptation:
    """Three-level adaptation: local, global, meta-guidance."""
    def adapt(self, islands: list, improvements: list[float]):
        # Local: dynamic exploration intensity per island
        for island, imp in zip(islands, improvements):
            island.g_t = self.ema_update(island.g_t, imp ** 2)
            island.exploration_intensity = f(island.g_t)

        # Global: UCB bandit allocates compute across islands
        # Rewards normalized against global best for comparability
        global_best = max(i.best_score for i in islands)
        for island in islands:
            island.reward = island.improvement / global_best
        self.ucb_allocator.update(islands)

        # Meta-guidance: LLM generates paradigm-shift directives
        if self.detect_global_stagnation(islands):
            tactics = self.llm.generate_tactics(islands)
            for island in islands:
                island.inject_tactical_guidance(tactics)

A key observation: these four meta-adaptation mechanisms are not mutually exclusive and address different aspects of search configuration. Bandit-based selection optimizes which model to use. Prompt co-evolution optimizes how to instruct the model. Learning logs share what has been discovered across the population. Hierarchical adaptation coordinates where to allocate resources and when to shift strategy. No single surveyed system implements all four simultaneously, suggesting an opportunity for future architectural integration.

64.4 Cross-Cutting Design Trade-Offs

Beyond layer-specific comparisons, several design trade-offs cut across the full architecture and represent the most consequential decisions system designers face.

64.4.1 Sample Efficiency vs. Population Diversity

Systems occupy a spectrum between maximizing the quality of each LLM call (sample efficiency) and maintaining a diverse population that covers the solution space broadly. ShinkaEvolve explicitly prioritizes sample efficiency, reporting competitive results in as few as 150 evaluation samples — achieved through power-law selection that concentrates mutations on the most promising candidates, two-tier novelty filtering that rejects trivially similar programs before evaluation, and early stopping that terminates unpromising evaluations. The cost is reduced population diversity, as resources are concentrated on refining a narrow region of solution space.

AlphaEvolve and OpenEvolve take the opposite position, investing in MAP-Elites grids and island models that maintain broad coverage at the cost of more evaluations per unit of improvement. The diversity guarantee is structural: MAP-Elites cells ensure that qualitatively different solution strategies persist even if their fitness is lower than the current best. This can pay off in deceptive fitness landscapes where the globally optimal solution lies in a region initially unreachable from the best-so-far.

SkyDiscover/AdaEvolve attempts to dynamically manage this trade-off through its accumulated improvement signal $G_t$. When improvement is rapid (high $G_t$), the system exploits aggressively; when improvement stalls (low $G_t$), it broadens exploration. This is an instance of a broader pattern: replacing static architectural parameters with adaptive mechanisms that respond to search dynamics.

64.4.2 Feedback Richness vs. Prompt Complexity

GEPA's Actionable Side Information represents the richest evaluation-to-mutation feedback channel in the surveyed systems, potentially including error traces, intermediate outputs, visualizations, and structured diagnostics alongside the fitness score. This provides the LLM with more context for producing informed mutations. However, rich feedback increases prompt length, consuming context window budget that could otherwise be used for showing more parent programs, more examples, or longer code histories.

Systems like OpenEvolve and Darwinian Evolver use leaner feedback — primarily the fitness score and, in Darwinian Evolver's case, specific failure cases. This keeps prompts compact, allowing more room for parent code and historical context, but gives the LLM less diagnostic information about why a candidate performed as it did.

The optimal point depends on the task domain. For tasks with clear, interpretable failure modes (e.g., test cases with specific inputs and expected outputs), lean failure-case feedback may suffice. For tasks where performance depends on subtle algorithmic choices (e.g., optimization heuristics, numerical methods), rich diagnostic feedback is likely more valuable.

64.4.3 Self-Modification Depth

The most provocative architectural axis is the degree to which systems modify themselves versus external artifacts. Most systems are externally directed: they evolve user-specified code while keeping their own search infrastructure fixed. Prompt co-evolution (ShinkaEvolve) represents a middle ground: the system evolves its mutation instructions alongside the target programs, but its core architecture remains immutable. The Darwin Gödel Machine occupies the extreme end, modifying its own source code — tools, strategies, prompts, and evaluation logic — through the same evolutionary process it applies to target tasks.

This dimension involves a fundamental safety trade-off. Self-modification enables powerful meta-learning: the DGM improved its SWE-bench performance from 20% to 50% through self-improvement and demonstrated cross-language transfer. But it also raises the risk of reward hacking, where the system modifies its own evaluation criteria to inflate reported fitness without genuine improvement. The source material explicitly identifies this as a key safety concern for self-modifying AI systems.

64.5 Comprehensive Feature Matrix

The following matrix maps all eight general-purpose and self-improving systems across architectural features. Specialized solvers (Confluence Labs, Arcgentica, AB-MCTS) are excluded as their architectures serve narrower purposes. Feature assignments are derived from the source survey material; where information is unavailable or uncertain, cells are marked accordingly.

64.6 Architectural Pattern Clusters

Examining the feature matrix holistically, the eight systems cluster into four recognizable architectural patterns. These clusters emerge not from a single feature but from correlated design choices across multiple layers.

Cluster A (QD-Heavy) — AlphaEvolve and OpenEvolve prioritize quality-diversity through MAP-Elites grids and island models with migration. Their evaluation pipelines use cascade filtering to manage the cost of maintaining large, diverse populations. These systems excel when the fitness landscape is deceptive or multi-modal, where maintaining diverse solution strategies pays off in the long run. The trade-off is higher sample cost: more evaluations are spent maintaining population diversity rather than directly improving the best candidate.

Cluster B (Efficiency-Adaptive) — ShinkaEvolve and SkyDiscover/AdaEvolve invest in meta-level adaptation to squeeze maximum improvement from each evaluation. Bandit-based model selection, novelty filtering to avoid wasted evaluations, and adaptive exploration/exploitation balance all serve the goal of efficient resource utilization. ShinkaEvolve's competitive results with only 150 samples demonstrate the power of this approach for well-behaved fitness landscapes. SkyDiscover's three-level hierarchy represents the most sophisticated version of this pattern, coordinating adaptation at local, global, and strategic levels simultaneously.

Cluster C (Feedback-Rich) — GEPA and Darwinian Evolver invest in the quality of information flowing from evaluation back to mutation, rather than in population structure or meta-adaptation. GEPA's Actionable Side Information and Darwinian Evolver's learning logs both serve the same architectural intuition: if you give the LLM better information about what went wrong, it will produce better mutations. These systems can afford simpler population management because each mutation is more likely to succeed.

Cluster D (Self-Modifying) — The Darwin Gödel Machine stands alone in evolving its own codebase. This is architecturally distinct because the boundary between search infrastructure and search target dissolves. The system's improvements compound across tasks, as demonstrated by cross-language transfer, but the approach introduces unique safety challenges not present in other clusters.

LLM4AD occupies a unique position as a meta-platform that subsumes multiple architectural patterns. By integrating seven distinct search methods (EoH, FunSearch, ReEvo, MCTS-AHD, and others), it allows users to select from methods that span Clusters A, B, and C. This makes LLM4AD less of a single architectural choice and more of a toolkit for exploring the design space itself.

64.7 Strengths, Weaknesses, and Capability Profiles

Each architectural cluster exhibits characteristic strengths and weaknesses that are predictable from its design choices. The following analysis is grounded in the reported results and design rationale from the source material.

64.7.1 Capability Profile Comparison

64.7.2 Per-System Unique Strengths

Beyond cluster-level patterns, each system contributes at least one architectural idea not found in its peers. Identifying these unique contributions clarifies what each system adds to the collective design space:

• AlphaEvolve — demonstrated production-scale deployment, with the scheduling optimization recovering 0.7% of Google's worldwide compute. This is the only system with documented real-world infrastructure impact beyond benchmarks.
• OpenEvolve — faithful open-source reimplementation enabling community adoption and reproducibility. Its multi-provider LLM abstraction (OpenAI, Gemini, local models) is the most widely accessible implementation of the AlphaEvolve architecture.
• ShinkaEvolve — prompt co-evolution as a first-class feature (v1.1), where system prompts evolve alongside program candidates. Also uniquely combines power-law selection with two-tier novelty filtering (embedding + LLM-as-judge) for sample efficiency.
• GEPA — Actionable Side Information as an architectural primitive, elevating evaluation from scoring to diagnosis. Also unique in supporting three explicit optimization modes (single-task, multi-task, generalization) and a seedless mode requiring no initial program.
• LLM4AD — integration of seven distinct search methods in one framework, enabling controlled comparison across algorithmic strategies. Reported world record in circle packing ($n=26$) using this platform.
• SkyDiscover/AdaEvolve — three-level hierarchical adaptation coordinated by the accumulated improvement signal $G_t$. Reported approximately 34% median improvement over OpenEvolve, GEPA, and ShinkaEvolve across their benchmark suite.
• Darwin Gödel Machine — self-modification of agent code, with demonstrated cross-language transfer (Python → Rust/C++/Go) and model-agnostic improvements that persist across LLM backend changes.
• Darwinian Evolver — learning logs that create a shared knowledge base across the population, enabling collective learning from both successful and failed mutations.

64.8 Architectural Evolution: 2024–2026

The seventeen systems were not developed simultaneously; their publication timeline reveals a clear architectural evolution over the 2024–2026 period. Three phases are discernible:

Phase 1: Foundation (2024). The AI Scientist demonstrated end-to-end LLM-driven research automation, establishing that LLMs could serve as the creative engine within iterative improvement loops. This was not yet evolutionary in the population-based sense, but it established the core loop of generate-evaluate-improve that all later systems would adopt.

Phase 2: Structured Evolution (early–mid 2025). AlphaEvolve introduced the full evolutionary paradigm with MAP-Elites, island models, and Gemini ensemble mutation. OpenEvolve democratized this architecture, and the Darwin Gödel Machine pushed the paradigm toward self-modification. Darwinian Evolver contributed the insight that cross-individual knowledge sharing (learning logs) could accelerate convergence. Systems in this phase focused on establishing the what: demonstrating that evolutionary search with LLM mutation operators could discover novel algorithms.

Phase 3: Adaptive Sophistication (late 2025–2026). ShinkaEvolve, GEPA, LLM4AD, and SkyDiscover/AdaEvolve shifted focus from the basic loop to its adaptive control. The central questions became: How to allocate limited LLM budget across competing strategies? How to maintain diversity without wasting evaluations? How to feed rich diagnostic information back through the loop? Systems in this phase compete not on whether the evolutionary loop works, but on how efficiently and adaptively they can configure it.

This trajectory — from establishing the paradigm, to democratizing it, to optimizing its efficiency — parallels the maturation pattern of many algorithmic paradigms. The current frontier appears to be adaptive meta-control: systems that automatically configure their own search strategy based on observed dynamics. SkyDiscover's three-level hierarchy and ShinkaEvolve's bandit-based model selection represent the most advanced examples.

64.9 Taxonomy Mapping

To situate each system within a structured design space, we map them across five orthogonal axes. Note that these axes are analytically separable but empirically coupled — choices along one axis constrain or favor choices along others.

# Pseudocode — taxonomy assignment schema
# Each system is classified across five design axes

taxonomy = {
    "A1_population_model": {
        "categories": ["QD-Grid", "Island", "Pareto", "Archive", "Flat"],
        "assignments": {
            "AlphaEvolve":       ["QD-Grid", "Island"],
            "OpenEvolve":        ["QD-Grid", "Island"],
            "ShinkaEvolve":      ["Island"],          # islands w/o MAP-Elites grid
            "GEPA":              ["Pareto"],
            "LLM4AD":            ["Flat"],             # default; configurable per method
            "SkyDiscover":       ["Island"],           # UCB-allocated islands
            "DGM":               ["Archive"],
            "DarwinianEvolver":  ["Flat"],
        }
    },
    "A2_mutation_strategy": {
        "categories": ["Diff", "Rewrite", "Crossover", "Reflection", "Self-Mod"],
        "assignments": {
            "AlphaEvolve":       ["Diff", "Rewrite"],
            "OpenEvolve":        ["Diff", "Rewrite"],
            "ShinkaEvolve":      ["Diff", "Rewrite", "Crossover"],
            "GEPA":              ["Reflection"],
            "LLM4AD":            ["Rewrite"],          # primary; method-dependent
            "SkyDiscover":       ["Rewrite"],           # + meta-guided tactics
            "DGM":               ["Self-Mod"],
            "DarwinianEvolver":  ["Rewrite"],           # failure-case-driven
        }
    },
    "A3_feedback_channel": {
        "categories": ["Score-Only", "Failure-Cases", "Diagnostics", "Learning-Log"],
        "assignments": {
            "AlphaEvolve":       ["Score-Only"],        # via cascade filtering
            "OpenEvolve":        ["Score-Only"],
            "ShinkaEvolve":      ["Score-Only"],
            "GEPA":              ["Diagnostics"],       # ASI is primary innovation
            "LLM4AD":            ["Score-Only"],
            "SkyDiscover":       ["Score-Only"],
            "DGM":               ["Score-Only"],
            "DarwinianEvolver":  ["Failure-Cases", "Learning-Log"],
        }
    },
    "A4_adaptation_level": {
        "categories": ["None", "Operator", "Model", "Strategy", "Self"],
        "assignments": {
            "AlphaEvolve":       ["None"],              # fixed configuration
            "OpenEvolve":        ["None"],
            "ShinkaEvolve":      ["Model", "Operator"], # bandit + prompt evo + scheduling
            "GEPA":              ["None"],              # implicit via reflection
            "LLM4AD":            ["None"],              # user selects method
            "SkyDiscover":       ["Model", "Strategy"], # 3-level hierarchical
            "DGM":               ["Self"],              # modifies own code
            "DarwinianEvolver":  ["None"],
        }
    },
    "A5_llm_routing": {
        "categories": ["Single", "Ensemble-Fixed", "Bandit-Adaptive"],
        "assignments": {
            "AlphaEvolve":       ["Ensemble-Fixed"],    # Flash + Pro
            "OpenEvolve":        ["Ensemble-Fixed"],    # multi-provider, user-configured
            "ShinkaEvolve":      ["Bandit-Adaptive"],   # UCB1 model selection
            "GEPA":              ["Single"],            # configurable but fixed per run
            "LLM4AD":            ["Single"],            # user selects model
            "SkyDiscover":       ["Ensemble-Fixed"],    # weighted multi-model pools
            "DGM":               ["Single"],            # varies per experiment
            "DarwinianEvolver":  ["Single"],            # user-defined
        }
    },
}

Several notable couplings emerge from this mapping. Systems with rich meta-adaptation (axis A4) tend to also use bandit-adaptive LLM routing (axis A5), as both require tracking per-option performance statistics. Systems with structured population models (axis A1: QD-Grid or Pareto) tend to use simpler adaptation strategies (axis A4: None), perhaps because the population structure itself provides sufficient diversity pressure without dynamic adaptation. The feedback channel (axis A3) is surprisingly orthogonal to other axes — GEPA's diagnostic feedback and Darwinian Evolver's learning logs are paired with different choices on every other axis.

64.10 Specialized Solvers: Architectural Divergence

The specialized ARC-AGI solvers (Confluence Labs, Arcgentica, AB-MCTS/TreeQuest) diverge from the general-purpose architecture in ways that illuminate the relationship between task structure and architectural design.

Confluence Labs replaces the evolutionary population with a multi-agent ensemble: 12 Gemini agents work on each test input with iterative refinement (up to 10 iterations), running in 132 concurrent sandboxes. There is no population, no selection, and no migration. The "evolutionary" component is reduced to iterative improvement within each agent. This achieves 97.92% on ARC-AGI-2 through brute-force parallelism at $11.77/task — architecturally simple but computationally expensive.

Arcgentica introduces runtime-as-context, where agents operate inside a live Python REPL with persistent intermediate results. This is architecturally significant because it collapses the generate-evaluate boundary: the agent simultaneously writes and executes code, using execution results as part of its reasoning context. Up to 10 sub-agents per problem operate within this shared runtime.

AB-MCTS/TreeQuest replaces population-based search with adaptive tree search using Thompson Sampling to balance depth (refining existing solutions) versus width (generating new approaches). Its multi-LLM extension adds model selection as a third search dimension, demonstrating that problems unsolvable by any single LLM can be solved through model collaboration.

The common thread: all three specialized solvers abandon population management in favor of intensive per-problem search. This reflects the ARC-AGI task structure, where each problem is independent and relatively small. General-purpose frameworks maintain populations because they target problems where discovering diverse algorithmic strategies has long-term value. When the objective is solving many independent puzzles rather than improving a single algorithm, per-problem search depth dominates over cross-problem diversity.

64.11 Cost Architecture Comparison

Cost management is an increasingly central architectural concern as LLM API prices and evaluation compute create a meaningful budget constraint. Systems address cost at different architectural levels:

The most sophisticated cost management appears in ShinkaEvolve's committed cost model, which tracks both realized costs (already spent) and in-flight costs (API calls dispatched but not yet returned). By budgeting against realized + in-flight totals, the system avoids the common failure mode where asynchronous systems overshoot their budget because multiple expensive calls are in-flight when the budget threshold is checked. This is a subtle but architecturally important detail for any system with asynchronous LLM dispatch.

Documented per-task costs from the source material illustrate the cost range across application modes: ShinkaEvolve at the ICFP 2025 contest spent approximately $60 for 320 trials. Confluence Labs' ARC-AGI-2 solver costs $11.77 per task. The ALE-Agent competition entry spent approximately $1,300 to win AtCoder Heuristic Contest 058 against 804 humans. These numbers span three orders of magnitude, reflecting both task difficulty and architectural choices about how aggressively to search.

64.12 Open Architectural Questions

The comparative analysis reveals several design questions where the surveyed systems offer incomplete or conflicting answers:

Optimal feedback granularity. The spectrum from score-only feedback (most systems) to full diagnostic ASI (GEPA) lacks empirical characterization of the middle ground. No system systematically ablates feedback richness to determine the point of diminishing returns, where additional diagnostic information ceases to improve LLM mutation quality relative to the prompt-length cost.

Population structure necessity. The specialized ARC-AGI solvers achieve strong results without populations, using only per-problem iterative refinement. It remains unclear for which task classes population-based diversity is genuinely necessary versus when simpler iterative approaches suffice. The boundary between "population helps" and "population is overhead" is not well characterized.

Meta-adaptation convergence. Systems with adaptive mechanisms (ShinkaEvolve's bandits, SkyDiscover's three-level hierarchy) assume that the search landscape is sufficiently stationary for bandit algorithms to converge on useful policies. However, LLM mutation quality changes as the population improves — a form of non-stationarity that violates standard bandit assumptions. No system explicitly addresses whether its adaptive mechanisms converge reliably or merely oscillate.

Composability of innovations. The source material notes that the "optimal system would combine ShinkaEvolve's sample efficiency, GEPA's diagnostic feedback, Darwinian Evolver's learning logs, DGM's self-improvement capability, and SkyDiscover's hierarchical adaptive resource allocation." Whether these innovations compose cleanly or introduce conflicting pressures is an open empirical question. For instance, rich diagnostic feedback (GEPA) and aggressive novelty filtering (ShinkaEvolve) may conflict: if the LLM receives detailed diagnostic context, it may produce mutations that are highly targeted but low-novelty, causing the novelty filter to reject diagnostically-informed improvements.

Generalization beyond benchmarks. Most empirical results come from competitive programming, mathematical optimization, and ARC-AGI. The source material identifies generalization to real-world software engineering as a key open challenge, noting that real code has complex dependencies, build systems, and test suites where fitness functions are harder to define and evaluation times are orders of magnitude longer. No system has demonstrated robust performance on large-scale production software engineering tasks.

64.13 Summary