DiscoSeaLAB

Agentic systems / Working paper

Recursive
Competitive
Improvement.

Alternating agents, accumulating context,
and focused expert activation.

Framework & retrospective case study · Not peer reviewed · Controlled comparisons proposed, not yet performed.

The working hypothesisThe next agent inherits a better starting point.
  1. 01Inspect

    Read the artifact and evidence

  2. 02Select

    Choose a valuable next task

  3. 03Improve

    Make a bounded contribution

  4. 04Verify

    Check gains and regressions

  5. 05Hand off

    Preserve work and useful context

Figure 1. Proposed RCI cycle. Another agent repeats the process on the accepted state. A rejected change can still contribute a reproducible finding. This is a workflow diagram, not an observed growth curve.

01 / Abstract

Progress through successive perspectives.

We propose Recursive Competitive Improvement (RCI), a workflow in which AI agents take successive turns on a persistent project. Each agent inspects the inherited work, identifies a promising next contribution, implements it, verifies the result, and leaves an inspectable handoff. The motivating hypothesis is that alternating large language models can produce a leapfrog effect: each contribution changes the problems, evidence, and opportunities available to the next contributor. Useful context accumulates alongside the artifact, while agents may select tasks that fit their capabilities and the project’s current needs.

We call the resulting concentration of relevant behavior focused expert activation. This is a proposed behavioral effect, not a measurement of neural activations. A retrospective case study follows seven Cinder Dominion runtime versions, from an economy environment to gameplay, crafting, presentation, optimization, repairs, and local persistence. Saved reports document both additions and regressions. They illustrate the workflow but cannot isolate the effects of model diversity, competition, or task self-selection. We specify a protocol, alternative explanations, and controlled comparisons needed to test the central claims.

Keywords multi-agent systems · iterative refinement · shared artifacts · task selection · context accumulation · AI-assisted software

02 / Motivation & definitions

The artifact becomes the meeting point.

A long-running project has many possible next steps. Once the environment works, interaction may matter more than scenery. Once interaction works, usability or persistence may become the limiting factor. The author’s motivating observation is that agents asked to review and improve a predecessor’s work often choose different contributions, and those contributions can make later improvements easier to discover and implement.

Recursive means that accepted outputs and evidence become inputs to later turns. Competitive means that a candidate contribution must justify its value against the inherited state and alternative uses of the budget. Improvement means a verified gain under declared project criteria, including explicit tradeoffs. These terms do not imply weight updates, a model’s desire to win, or improvement in every metric on every turn.

The proposed leapfrog effect is a sequence of complementary advances. Agent A makes a useful capability possible; agent B recognizes a newly accessible opportunity, repairs a weakness, or extends that capability; agent C works from the resulting state. Model alternation is one possible source of complementary perspectives. Fresh sessions, different prompts, tools, and ordinary additional effort are competing explanations that an evaluation must separate.

RCI is a proposed synthesis of known ingredients. Its emphasis is the persistent artifact, autonomous choice of the next bounded task, and retention of verified context across turns. We do not claim priority for multi-agent collaboration, iterative refinement, or external memory. The value of this combination is a research question.

03 / Proposed protocol

A turn earns its place through evidence.

Let St be the current project state and Ct its curated context. An agent selects a task under a declared budget, produces a candidate state, and submits evidence Et. A review rule decides whether the candidate replaces the baseline. The context update retains useful findings from accepted and rejected attempts.

St+1 = Review(St, Candidatet, Et)Ct+1 = Curate(Ct, Taskt, Et, decision)

These equations describe bookkeeping, not a convergence theorem. Review returns the candidate or retained baseline. Curation can replace stale summaries while preserving provenance. A minimal turn has five obligations:

  1. Inspect the actual source. Read the artifact, constraints, validation, and unresolved defects. Identify the version being extended and preserve earlier work.
  2. Select and explain. State the next task, expected user benefit, motivating evidence, and a plausible alternative. Record expected effort and uncertainty before implementation.
  3. Implement within scope. Keep the change attributable and reversible. Preserve working capabilities and credit inherited work.
  4. Verify against the baseline. Run relevant checks and shared regression tests. Report failures, resource costs, and changes to evaluation conditions. Use independent review where available.
  5. Leave a useful handoff. Record what changed, why, how it was checked, what failed, what remains uncertain, and where the successor can inspect the evidence.

Task choice estimates expected project value relative to cost and regression risk. An agent’s confidence is not evidence of comparative advantage. A human or controller sets the objective and acceptance criteria; the agent chooses within those constraints. “Make it better” alone is insufficient when visual quality, speed, reliability, and scope can conflict.

The protocol stops at a fixed budget, a satisfied objective, or repeated proposals with no verified gain. Rejected turns and their costs remain in the record. Keeping the baseline prevents a failed candidate from becoming the default, although incomplete tests can still admit regressions. Explicit competitive framing should be separately tested against a neutral instruction to improve the project.

04 / Proposed mechanisms

Context can become more useful, not just longer.

The important by-product may be a growing collection of constraints and discoveries: which implementation is current, which apparent defect was reproduced, which repair failed, and which measurements are comparable. An executable test, stable asset identifier, or explicit failure can be more valuable to a successor than a confident retrospective summary.

We define decision-useful context as retained information that improves a later decision or outcome under a fixed information budget. Volume and novelty alone do not establish value. A prospective test would give successors the same artifact with different handoffs, then measure repeated failed approaches, time to a valid contribution, and held-out quality. The stronger claim that this process creates the “most valuable” context remains untested.

Focused expert activation names the hypothesis that the inherited state narrows an agent’s attention toward relevant knowledge, tools, and skills. A performance report might elicit profiling and instancing work; an inventory limitation might elicit persistence design. The operational observation is targeted behavior and verified output. It does not demonstrate activation of particular neurons, mixture-of-experts routing, hidden specialist modules, or durable learning.

Two effects are separable: context makes a task clearer, and an agent selects a task it can execute well. To establish the second, selected tasks must outperform assigned alternatives after accounting for difficulty and opportunity. Agents may instead choose easy-to-demonstrate work, avoid hard defects, or overestimate competence. Recording alternatives and comparing matched tasks helps expose that selection bias.

05 / Retrospective observation

One project. Seven recorded turns.

Cinder Dominion is an evolving Unreal environment and gameplay prototype. We selected the contiguous runtime-v6 through runtime-v12 sequence from its append-only history because it contains concrete handoffs, feature additions, and reported regressions. The sequence spans 25–26 October 2026. Version IDs identify releases, not isolated model calls. Earlier world, art, and runtime work also contributed to these versions.

Runtime V6 / Economy environment

Create stable resource targets, stations and a machine-readable handoff.

31 targets and 68 standing anchors recorded; gameplay remained to be implemented.

Exact model ID not recorded; contributor label shown.

Select a turn to inspect the recorded task and outcome. These are successive versions of one project, not a model ranking or a controlled trial.

The contributor labels are Codex, Claude, Cursor, and Kimi. These labels do not all identify a model: Cursor is an application label, and several exact model IDs were not recorded. The history identifies Claude’s v7 and v10 model as claude-fable-5; that attribution is reproduced from the record, not independently verified here. The case supports a sequence of agent-assisted contributions, not a controlled experiment with four verified distinct LLMs.

V6 supplied resource targets, stations, and a machine-readable manifest. V7 implemented gathering, crafting, and trading. V8 added deliberate recipe selection, batch crafting, working anvils, and a screen-space HUD. V9 concentrated on route and habitat presentation. V10 rebuilt costly dressing with instanced geometry and extended another route. V11 restored the crafting HUD and replaced planar foliage. V12 added local inventory/currency persistence and original worksite models.

This is consistent with complementary task selection, but human direction remained important. The v12 record explicitly describes a request for environment and 3D-model improvements. The history is not a transcript of every proposal or a randomized allocation of tasks. It cannot establish that an agent chose the best possible next task, or that another agent would have failed at the same work.

Table 1. Recounted results in saved test reports.
ReleasePassed / recordedScope
runtime-v717 / 17Version-specific scripted gameplay checks
runtime-v852 / 52Version-specific scripted gameplay checks
runtime-v917 / 17Version-specific scripted gameplay checks
runtime-v1017 / 17Version-specific scripted gameplay checks
runtime-v1168 / 68Version-specific scripted gameplay checks
runtime-v1280 / 80Version-specific scripted gameplay checks
runtime-v12-restart10 / 10Separate persistence/restart checks

Counts were recalculated from saved reports for this paper; the tests themselves were not rerun. They cover different assertions, so 80 checks versus 17 is not a measured quality gain. Many checks exercised gameplay functions directly rather than physical keyboard input. Later suites expanded coverage and could expose defects an earlier passing suite did not test.

A counterexample to automatic improvement

The v8-to-v9 report recorded mean frame time increasing from 17.892 to 19.993 ms, with average FPS falling from 55.89 to 50.02. V9 added presentation detail while consuming more rendering time. In a separate v9-to-v10 comparison, mean frame time fell from 19.708 to 17.440 ms, and average FPS rose from 50.74 to 57.34. Each report used two alternating pairs at a matched idle viewpoint on an RTX 3060 at 1600 × 900.

These are within-report observations, not a continuous benchmark trajectory. Background GPU use was uncontrolled. The later v11 review also reported a missing crafting HUD in v10 and material fallback warnings in its baseline logs. V10’s numbers therefore cannot establish a rendering-equivalent speedup or improvement in every dimension. The sequence demonstrates why a successor must inspect both claimed gains and preserved functionality. The public snapshot includes run values, source identifiers, hashes, attribution limits, and test names.

06 / Prospective evaluation

What would make the hypothesis convincing?

The following is a proposed design; no results from these comparisons are reported here. Begin with multiple held-out project snapshots spanning implementation, debugging, documentation, and design. Define utility and mandatory constraints before agents see the evaluation tasks. Select participating models and the strongest single-model baseline using separate development data.

Use a factorial comparison of same-model versus mixed-model turns, assigned versus self-selected tasks, and minimal versus structured handoffs. Give all conditions the same artifact and tools. Include fresh-session restarts in the same-model condition so resets are not mistaken for diversity. A continuous single-agent baseline and parallel critique/aggregation baseline provide further comparisons. Counterbalance model order and sample repeated runs per project.

Fix a primary total budget and report actual tokens, tool calls, compute expenditure, elapsed time, and human interventions. Equal turn counts are not equal effort; tokens also differ across tokenizers. Report quality under both cost and wall-time constraints where feasible. Fix human steering rules, retain failed attempts, and evaluate final artifacts with held-out tests and reviewers blinded to contributor identities. Agents must not edit the held-out evaluation.

Table 2. Proposed hypotheses and disconfirming observations.
HypothesisMeasurementEvidence against it
H1 · Alternation adds valueFinal utility under equal budget versus strongest single-model turnsNo reliable gain after controlling for model strength, order, and fresh sessions
H2 · Handoffs compoundSuccessor quality and repeated-error rate at matched context lengthStructured context performs no better than minimal or shuffled context
H3 · Self-selection finds better workRealized utility per cost versus tasks of matched difficultyBenefits disappear after accounting for easier choices
H4 · Expertise becomes focusedTask-specific success and relevant tool use under targeted versus generic contextNo specialization beyond generic extra instructions
H5 · Competition helpsNeutral versus outperform-the-baseline framing, same protocolNo gain, or more regressions and inflated claims

Outcomes should include accepted capability gains, independently reproduced fixes, regression rate, artifact quality, and cost to reach a fixed target. Predefine score weights or report separate outcomes where tradeoffs cannot be defensibly collapsed. Estimate uncertainty across projects and repeated runs; individual test assertions are not independent project samples. Choose sample size through a pilot and power analysis, and preregister primary comparisons before the main evaluation.

Context ablations should separately remove rationale, negative findings, test evidence, or unresolved issues while holding the artifact constant. A task-selection audit should compare predicted gain, recorded before work, with realized benefit. These studies would distinguish better coordination from stronger models, more computation, and selective reporting.

08 / Limitations & conclusion

A promising process needs a fair test.

The case has one project, retrospective selection, changing objectives, incomplete model attribution, unequal and unrecorded budgets, substantial human guidance, and self-authored validation reports. We have not measured marginal context value, calibrated task choice, independent output preferences, or causal benefits of alternating LLMs. This publication checks saved evidence consistency, not the reproducibility of the game experiments.

Failure modes include inherited false claims, loss of design intent, repeated rewrites, incompatible contributions, and selection of impressive but low-value tasks. Context can compound errors as well as knowledge. Competitive prompts can reward novelty or apparent victories over useful maintenance. Provenance, bounded changes, stable evaluation, and permission to retain the baseline are central to the proposed method.

RCI makes the author’s observation testable: successive agents may improve a shared project by creating better artifacts, discovering useful constraints, and choosing contributions suited to the current state. Cinder Dominion illustrates complementary progress and corrective review, including tradeoffs. Whether heterogeneous models beat equally resourced alternatives—and whether focused expert activation explains any advantage—remains an empirical question.

09 / References & research record

Sources, attribution, and reuse.

  1. Madaan, A., et al. (2023). Self-Refine: Iterative Refinement with Self-Feedback. arXiv.
  2. Shinn, N., et al. (2023). Reflexion: Language Agents with Verbal Reinforcement Learning. arXiv.
  3. Du, Y., et al. (2023). Improving Factuality and Reasoning in Language Models through Multiagent Debate. arXiv.
  4. Wu, Q., et al. (2023). AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation. arXiv.
  5. Wang, J., et al. (2024). Mixture-of-Agents Enhances Large Language Model Capabilities. arXiv.
  6. Huang, J., et al. (2023; revised 2024). Large Language Models Cannot Self-Correct Reasoning Yet. arXiv.
  7. Li, W., Lin, Y., Xia, M., & Jin, C. (2025). Rethinking Mixture-of-Agents: Is Mixing Different Large Language Models Beneficial?. arXiv.

Authorship. redazul originated the RCI framing and observations and directed publication. An AI assistant assisted with literature lookup, drafting, evidence extraction, and the website. Earlier project contributors retain credit for their recorded work. This is a self-published working paper, not a peer-reviewed or independently replicated study.

Evidence availability. The snapshot is an allowlisted export of selected local records with recalculated counts and source hashes. It excludes private sessions, credentials, and account data. Complete game assets and the original execution environment are not included; the snapshot permits inspection of reported results, not full reproduction. The export script is retained with the website code.

Suggested citation: redazul (2026). Recursive Competitive Improvement: Alternating Agents, Accumulating Context, and Focused Expert Activation. DiscoSea Lab working paper, v1.0. discosea.com/research/recursive-competitive-improvement