MC-EvoBench: Auditing Experience-Driven Self-Improvement in Minecraft Agents

Abstract

A central challenge in embodied recursive self-improvement is enabling agents to convert interaction history into capabilities that persist beyond one world and transfer to later tasks. A saved memory or successful final action does not by itself establish that a reusable capability was acquired; evaluation must separate capability change from carried-over resources, unequal source exposure, and early execution failures. We construct MC-EvoBench as a controlled Minecraft benchmark with a fixed catalog of 19 registered evolution chains, including 12 primary evaluation chains and seven calibration or probe chains, together with three graph-aligned paired probe families for transfer. The benchmark represents each task as a task-state graph, defines stage-level environment verifiers, assigns matched source and target roles, resets the target world, and permits only a declared agent artifact to cross the source–target boundary. For each probe, no-prior, related, unrelated, and shuffled source conditions are evaluated under matched environment-step budgets and five seeds; we report TSR, WGP, and VMP and retain provenance records. The benchmark reveals a consistent direct-capability gap between controller and planner-backed variants, while related experience yields no stable transfer: it does not improve either tool probe, its small wood-species gain hinges on one seed, and all intervals include zero. Stage audits further show that early wood-collection and crafting bottlenecks often leave later capabilities unobserved. MC-EvoBench thus offers a controlled testbed for durable, transferable embodied capabilities. Code and data are available at https://github.com/xzw-ustc/mc-bench-open-source.

12

1 Introduction

One of the central ambitions of autonomous intelligence is recursive self-improvement (RSI) (Chen et al., 2026): an agent should use experience from its own actions to become more capable over time. The goal is larger than learning one policy or storing one successful trajectory. An RSI system should turn experience into a capability, retain it, and apply it when the task, world, or required action changes. This loop is central to long-horizon autonomy: as tasks become harder, the agent must build on what it has already learned.

This view differs from evaluation settings in which training is separated from testing and improvement is summarized by a single score (Ren et al., 2026). For RSI, the important question is whether a gain remains useful after the original interaction has ended. A capability should survive a change in local conditions, help with a related goal, and combine with actions that were not part of the source task. RSI is therefore a systems problem: learning, memory, planning, and physical interaction must work together, while the resulting gain remains visible and attributable.

Embodied agents make this problem concrete and difficult. Their behavior depends on both internal state and physical state. A later success may reflect a tool left in the inventory, a changed world, a favorable location, or more source interaction rather than a reusable capability. A useful benchmark must therefore show that improvement survives a reset and appears in observable behavior.

We study this question through later behavior. A memory, skill file, or model update shows that an agent changed internally. It does not show that the agent gained a useful capability (Li et al., 2025b; Park et al., 2025; Li et al., 2026). The evidence must link internal change to later action. It must also distinguish capability from favorable execution. To test that claim, we compare target behavior after a world reset and check both task outcomes and stage-level records.

Existing benchmarks address parts of this problem. MCU (Zheng et al., 2023) evaluates diverse and combined Minecraft tasks with automatic verification. LifelongAgentBench (Zheng et al., 2025), EvoAgentBench (Gao et al., 2026), and PAST-Bench (Xue et al., 2026) study learning across tasks, transfer, and persistent state in other settings. Embodied evaluation also needs to separate world resources from agent state, match source budgets, and record where a task chain fails (Ni et al., 2025; Cheng et al., 2026; Luo et al., 2025). Otherwise, a score difference may reflect an easier world, more source interaction, or an early failure that hides later behavior.

Minecraft makes these controls practical. Collecting resources, crafting tools, and using them create visible task dependencies. A task-state graph represents these relations, and environment evidence verifies each stage. Resetting the world and inventory removes physical carryover, while stage records show progress before a chain stops (Guo et al., 2025; Huang et al., 2025).

We introduce MC-EvoBench to evaluate embodied RSI in Minecraft. Figure 1 shows its mechanism: measure progress, transfer only a declared agent artifact, and use matched controls to assess experience gains. Table 1 compares this design with representative Minecraft benchmarks (Guss et al., 2019; Fan et al., 2022; Hill et al., 2023; Wang et al., 2025). MC-EvoBench provides a task catalog, verifiers, and three short probe families for wood-species crafting, wooden-tool transfer, and stone-tool transfer. The framework can study capability formation, transfer, retention, and composition. This paper focuses on forward transfer between graph-related tasks.

Our main contributions are as follows:

1. Embodied RSI as attributable capability change. We formalize an agent as a policy, a persistent state, and an update rule, and separate this persistent state from the world state. A gain counts as experience-driven only when it appears after the target world is reset, only a declared artifact crosses the source–target boundary, and matched unrelated and shuffled sources rule out alternative explanations.
2. MC-EvoBench, an executable audit of experience-driven improvement. It instantiates this definition in Minecraft with a task-state graph of 80 tasks, 111 states, and 369 typed edges organized into 19 chains; stage-level verifiers with three complementary metrics, Task Success Rate (TSR), Weighted Graph Progress (WGP), and Verified Milestone Progress (VMP); and a four-condition paired protocol with matched environment-step budgets and provenance records.
3. Controlled evidence on embodied transfer. Controller-based agents clearly outperform planner-backed variants in direct capability. Under matched controls, the reference method shows no stable transfer gain, even though its related sources earn more verified progress and, on the longer probes, more computation, and early wood-collection and crafting bottlenecks leave later capabilities unobserved. Future RSI methods must therefore first clear these execution bottlenecks, and their gains should be claimed only after a controlled audit.

Section 2 reviews related benchmarks and agents. Section 3 defines the framework and benchmark. Section 4 reports the reference results. Appendices A–G give the task, environment, protocol, and reproduction details.

2 Related Work

Minecraft and embodied-agent benchmarks.

Minecraft combines visual control, persistent resources, and tasks with many prerequisites. MineDojo provides a large open-world task collection and a knowledge base that supports broad embodied-agent research (Fan et al., 2022). BEDD extends MineRL (Guss et al., 2019) with demonstrations and evaluation for tasks whose success can be difficult to describe with a single exact goal. MinePlanner focuses on long-horizon planning in large Minecraft worlds, while OpenHA studies open-source hierarchical agents and their execution in the same environment (Hill et al., 2023; Wang et al., 2025). Voyager uses a curriculum, a skill library, and environment feedback for continued exploration and skill reuse, including in a new world (Wang et al., 2023). MCU evaluates a broad set of tasks, their combinations, and automatic assessment (Zheng et al., 2023). Together, these benchmarks cover open-world interaction, planning, task diversity, and automatic verification. They do not, however, isolate whether a controlled source interaction causes a later improvement after the target world is reset.

Lifelong learning and self-evolving agents.

Several recent benchmarks study improvement across tasks and the use of stored experience. LifelongAgentBench tests skill gain, retention, and transfer across databases, operating systems, and knowledge graphs (Zheng et al., 2025). EvoAgentBench uses agent traces to identify abilities and groups tasks by shared procedures, making transfer between related tasks explicit (Gao et al., 2026). PAST-Bench compares runs with and without persistent state and tracks how experience is saved and reused in personal-agent settings (Xue et al., 2026). These studies establish useful ideas for measuring persistence and transfer, but their tasks do not expose the same physical-state confounds as embodied environments. In Minecraft, an apparent gain can instead come from a carried tool, a modified world, or a different starting location. MC-EvoBench addresses this boundary by resetting inventory and world changes while allowing only a declared agent artifact to transfer. Its task-state graph makes prerequisites and progress visible.

Memory-mediated improvement and benchmark position.

Memory systems provide a practical mechanism for experience-driven improvement. Reflexion (Shinn et al., 2023) stores language feedback from failed attempts and uses it to guide later decisions. Agent Workflow Memory extracts reusable procedures from interaction traces for later tasks (Wang et al., 2026). Skill libraries and model updates offer related ways to preserve information beyond a single episode. These methods show how an agent can store and retrieve experience, but reuse alone does not establish that a capability transferred. MC-EvoBench treats experience-driven improvement as an attribution problem. It separates source and target episodes, resets the physical state, and transfers only a declared artifact. Matched source conditions, verifier predicates, and stage records distinguish capability transfer from carried-over resources and partial execution.

3 MC-EvoBench Framework and Benchmark Design

MC-EvoBench tests whether experience changes later behavior. To support that claim, it resets the target world, checks outcomes against environment evidence, and compares matched source conditions. Figure 2 shows how these parts work together. Panel (a) follows the agent from source interaction to target evaluation. Panel (b) shows the tasks, states, relations, chains, and environment profiles that define each test.

3.1 Evaluation Target and State Boundary

We ask whether controlled source interaction improves performance on a later target task in a reset world. A stored memory or model update cannot answer this question by itself. We represent an agent as A=(\pi,z,U): \pi selects actions from observations and goals, z is the state the method can retain, and U updates that state from experience. Source experience E_{S} produces z_{S}=U(z_{0},E_{S}). The evaluator records and freezes z_{S} before the target run. No source resources, positions, world edits, route information, or success markers enter the target.

World state includes inventory, tools, resources, position, terrain, and world changes. Persistent agent state may include memories, prompts, replay data, checkpoints, or model updates. Every target run starts with the same registered world and inventory settings. Thus, source tools and world changes cannot explain a target score difference. A stored artifact provides evidence of a gain only when the target verifier also records a change in behavior.

3.2 Task-State Graph

MC-EvoBench represents task dependencies and observable resource flow with

G=(\mathcal{T},\mathcal{S},\mathcal{E}),

Here, \mathcal{T} contains tasks, \mathcal{S} contains observable states, and \mathcal{E} contains typed relations. States include items, tools, locations, structures, and task completion. The graph describes what tasks require, produce, or consume without prescribing an action sequence. These three relation types form the strict execution graph. The remaining types, enables and abstracts_to, describe possible capability links and task categories; neither proves transfer. Appendix B.2 defines each edge type and gives their counts.

Tasks form stage chains C=(\tau_{1},\ldots,\tau_{K}). Each stage has a goal that the verifier checks against run evidence. The chain shows prerequisites and where execution stops; the agent remains free to choose its actions. Stage records reveal partial progress even when the final goal is not reached. Catalog and probe chains use the same task definitions and verifier rules. Reset settings, retained state, and step budgets are fixed before evaluation.

3.3 Paired Protocol and Metrics

Each comparison has a source phase and a target phase. The source agent interacts with registered tasks and forms z_{S}. The evaluator then resets the target world and inventory, freezes z_{S}, and runs the target task with the same verifier. Four target conditions serve different purposes. No-prior provides a baseline; related experience tests for a change; unrelated experience tests whether that change depends on task relevance; and shuffled related experience tests whether task order matters. We record source steps, termination, artifact identity, and target outcomes. Source episodes restart after early termination until the declared budget is used.

The verifier records the evidence for each stage, changes in resources, pass status, and why the run stopped. Let v_{i} indicate whether stage i passes. For each strict execution edge e, w_{e} is its weight and q_{e} indicates verified progress. Let m_{j} indicate whether eligible milestone j is reached. The three direct metrics are

\displaystyle\mathrm{TSR} \\ \displaystyle=\frac{\sum_{i=1}^{K}v_{i}}{K}, \\ \displaystyle\mathrm{WGP} \\ \displaystyle=\frac{\sum_{e\in E_{\mathrm{exec}}}w_{e}q_{e}}{\sum_{e\in E_{\mathrm{exec}}}w_{e}}, \\ \displaystyle\mathrm{VMP} \\ \displaystyle=\frac{\sum_{j=1}^{J}m_{j}}{J}.

TSR is the fraction of planned stages that pass; unreached stages remain in its denominator. WGP is the weighted fraction of strict graph edges supported by verified progress. VMP tracks eligible item or tool milestones observed before a chain ends. It captures partial progress, not full completion. We report all three metrics for each target condition and compare paired runs. Appendices C and D.6 give the verifier and reporting rules.

3.4 Benchmark Instantiation

MC-EvoBench implements this framework in Minecraft with a fixed task catalog, verifiers, probe profiles, and observation interface. A change to any of these components defines a new benchmark version. The same evaluation can therefore test different ways of storing experience, such as textual memories, skill libraries, prompts, or model updates, under a shared task and evidence specification.

3.4.1 Frozen Catalog and Probe Families

The catalog contains 80 tasks, 111 state nodes, 369 graph edges, 19 registered chains, 12 general profiles, and 3 paired-transfer profiles. Its 19 chains include 12 primary evaluation chains and 7 calibration or probe chains. Tasks span building, survival, exploration, and combat. Long chains test execution across many prerequisites. Short probes test local transfer that an early failure in a long chain could hide. The probes use catalog tasks and the same verifier rules. Appendices F and A.3 list the tasks, chains, and profiles.

The three probe families and their budgets are listed in Table D.3 of Appendix D.3. In each family, related and target chains share a dependency pattern but end with a different object or tool. This lets us test transfer while keeping the required preparation steps. Each stage has a 450-step cap. After early termination, a new episode starts until the family budget is used.

3.4.2 Environment and Observation Interface

Paired-transfer runs use public world seed 31, an empty target inventory, and one of three fixed environment profiles (Appendix A.3); direct-capability runs use the seeds and per-stage profiles in Table F.3. Profiles set time, weather, spawn, clearance, and public resources. They do not provide target items, routes, private coordinates, or verifier state. The agent must observe and collect resources through interaction. Each target condition starts with a world and inventory reset; only the declared agent artifact can transfer. The agent sees normal observations, while the graph, verifier rules, diagnostics, and hidden coordinates remain unavailable. Appendices A.2 and C.1 detail these access rules and verifier checks.

4 Experimental Results

We report two complementary views of the benchmark. The direct capability matrix measures immediate performance across the registered catalog without a source–target transfer claim. The paired probes then test whether a declared source artifact changes behavior on a later target after the world is reset. Keeping these views separate distinguishes basic execution ability from experience-driven improvement.

4.1 Evaluation Setup

The paired evaluation uses three probe families: wood-species crafting, wooden-tool transfer, and stone-tool transfer. Each family uses five paired agent seeds and four target conditions: no prior, related experience, unrelated experience, and shuffled related experience. Every target starts from the same world and inventory state for its family. Only the declared agent artifact may cross the source–target boundary. We report TSR, WGP, and VMP as defined in Section 3.3. Source exposure is matched within each family; planner calls and token usage are recorded separately because equal environment exposure does not imply equal computation.

4.2 Direct Capability Matrix

The direct matrix covers 12 primary evaluation chains (five core-progression, four catalog-transfer, and three diversity) and nine direct configurations, each evaluated with three seeds. Each cell in Table 2 averages TSR / WGP / VMP over the chains in a partition; the final columns weight the partitions by their sizes (5/4/3), and Appendix Table F.3 gives per-chain scores. These runs measure direct capability rather than transfer; ExpeL (Zhao et al., 2024) has one separately marked report per chain and is excluded from these aggregates.

Controller-based execution clearly outperforms planner-backed execution. STEVE-1 (Lifshitz et al., 2023) and the controller-only JARVIS-1 (Wang et al., 2024) and Optimus-1 (Li et al., 2024) variants reach average TSR/WGP/VMP of 8.4/6.4/25.5, 7.5/5.5/25.0, and 8.1/6.1/25.4, with the largest margins on the core and catalog-transfer partitions, where progress requires several dependent actions. The no-op baseline and the GPT-planned JARVIS-1 remain at the execution floor, confirming that the benchmark separates active task solving from background behavior. No planner dominates all three metrics: DeepSeek gives the highest average TSR for both JARVIS-1 (2.8) and Optimus-1 (4.9), whereas the highest VMP comes from DeepSeek for JARVIS-1 (6.0) but from GLM for Optimus-1 (12.5). The official VPT (Baker et al., 2022) foundation weights improve over the STEVE-1 checkpoint (average VMP 10.4 versus 3.2) but remain below the controller variants.

4.3 Paired Transfer Results

Table 3 reports mean target scores in the order no-prior / related / unrelated / shuffled. The study contains 105 source and target role reports in total, with 60 target reports contributing to the four-condition comparison.

For wood-species crafting, related experience gives scores close to no prior. The shuffled control scores at least as high on TSR and WGP. For wooden-tool and stone-tool transfer, related experience scores below no prior on all three metrics. On the stone-tool probe, related TSR, WGP, and VMP are 0.050, 0.021, and 0.200, compared with 0.150, 0.082, and 0.533 for no prior.

4.4 Paired Contrasts and Uncertainty

For each direct metric, let M_{0}, M_{R}, M_{U}, and M_{S} denote the no-prior, related, unrelated, and shuffled target scores. We report the related-source change \Delta R=M_{R}-M_{0}. For completeness, Table 4 also reports the adjusted contrast

\mathrm{GATG}=M_{R}-\frac{1}{2}(M_{U}+M_{S}).

GATG is used here only as a descriptive paired contrast; TSR, WGP, and VMP remain the benchmark’s direct metrics. Intervals are two-sided 95% Student-t intervals over the five paired seeds.

Table 4 separates the direct related-source change from the control-adjusted contrast. Relative to no prior, related experience improves only WGP on the wood-species probe (\Delta R=+0.040); TSR and VMP are unchanged. The two tool-transfer probes show negative changes on all three metrics, with the largest decrease in VMP for stone-tool transfer (\Delta R=-0.333). After adjusting for the unrelated and shuffled controls, the wood-species probe retains a small positive GATG on TSR, WGP, and VMP (+0.050, +0.060, and +0.050). The wooden-tool probe is mixed: GATG is near zero for TSR and slightly positive for WGP, but negative for VMP. All reported confidence intervals include zero, and the intervals are wide because they are estimated from five matched seeds.

4.5 Source Cost and Run Records

Matching environment steps does not equalize episodes or planner calls. Table 5 reports the observed source cost: step budgets are fixed within each family (900, 2,250, and 3,600), while episode counts, LLM calls, and termination states depend on how each run proceeds.

The related condition is the only one with nonzero source TSR (0.100, 0.080, and 0.150) and accounts for 34 of the 41 passed records, whereas shuffled runs end only by timeout. It also uses more planner calls on the two longer probes, reaching 24.80\pm 4.60 calls for stone-tool transfer versus 16.40 and 16.00 for the unrelated and shuffled controls.

4.6 Failure Stages, Seed Variation, and Scope

In the failure-stage audit of the 57 direct-matrix reports per configuration (Figure 3a), attrition concentrates in the first crafting steps: of the 42 reports that include wood collection, the three controller variants bring 20–23 to plank crafting, at most 14 to sticks, and at most 2 to the crafting table, while the Optimus-3 (Li et al., 2025a) action path never passes the initial wood stage. A low final score can therefore reflect an early execution bottleneck rather than the failure of a later capability, which remains unobserved. Per-seed effects (Figure 3b–c) vary most for wood species, where the small positive mean GATG (+0.050) is driven by a single seed (+1.0) and falls to -0.19 without it; the tool probes vary less and have GATG means near zero. All three intervals cross zero, consistent with Table 4.

Taken together, the direct matrix measures immediate capability rather than transfer, and the paired probes should be read against its low execution floor. Under the current public instances, seeds, budgets, and reference method, related experience does not produce a stable positive transfer effect; this does not rule out gains under a different agent, artifact, task distribution, or source budget. Appendices C.3, D.6, and E.4 give the stage records, paired-reporting rules, and configuration fields needed to reproduce these comparisons.

5 Conclusion

We introduced MC-EvoBench, a controlled Minecraft benchmark for auditing whether experience yields durable and transferable embodied capabilities. Its task-state graph, stage-level verifiers, and paired reset-target protocol with matched control sources separate capability change from carried-over resources, unequal exposure, and early execution failures. In the reference study, controller-based agents clearly outperform planner-backed variants, yet the reference method gains no stable target benefit from related experience: the only positive contrast, on wood species, is driven by a single seed, and all intervals include zero even though related sources earn more verified progress and, on the longer probes, more computation. Most runs also end before crafting sticks, leaving later capabilities unobserved. These conclusions are limited to the tested agents, probes, seeds, and budgets; retention, composition, stronger agents, and more seeds are natural next steps.

AI use statement

We used generative AI tools for English translation, language editing, shortening text, and LaTeX formatting. We did not use AI to generate data, run experiments, or draw the final conclusions. The authors checked all citations, equations, experimental settings, and results. They reviewed all AI-assisted text and take full responsibility for the paper.

Ethics statement

This work evaluates agents in a virtual Minecraft environment. It does not involve human participants, personal data, or physical-world experiments. We use environment states and agent interaction traces to measure task execution and experience transfer. Any released code, task definitions, assets, and logs will follow their applicable licenses and include documentation for reproduction. The results apply to the tested methods, tasks, environments, and budgets. They do not establish that these agents are safe or capable in real-world settings.

Reproducibility statement

Section 3 defines the task-state graph, source–target protocol, and metrics. Section 4 reports the reference results. Appendices A–C give the environment profiles, task and chain definitions, verifier rules, stage records, and metric calculations. Appendix D describes resets, source budgets, target roles, seeds, artifact transfer, and paired reporting. Appendix G gives the memory formats, prompts, example configuration, evaluation procedure, and reproduction commands. Run records include the fixed task and verifier settings, seeds, source exposure, artifact identities, and stage evidence needed to check the reported scores.

References

1. Baker et al. (2022) B. Baker, I. Akkaya, P. Zhokov, J. Huizinga, J. Tang, A. Ecoffet, B. Houghton, R. Sampedro, and J. Clune Video pretraining (vpt): learning to act by watching unlabeled online videos. Advances in Neural Information Processing Systems 35, pp. 24639–24654.
2. Chen et al. (2026) M. Chen, L. Wang, and B. Qu Recursive self-improvement in ai: from bounded self-refinement to autonomous research loops. arXiv preprint arXiv:2607.07663.
3. Cheng et al. (2026) Z. Cheng, R. Li, J. Hu, Y. Tu, S. Dai, S. Hu, Y. Shi, L. Shi, and M. Sun Embodiedeval: evaluate multimodal llms as embodied agents. In Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, pp. 11420–11432.
4. Fan et al. (2022) L. Fan, G. Wang, Y. Jiang, A. Mandlekar, Y. Yang, H. Zhu, A. Tang, D. Huang, Y. Zhu, and A. Anandkumar Minedojo: building open-ended embodied agents with internet-scale knowledge. Advances in Neural Information Processing Systems 35, pp. 18343–18362.
5. Gao et al. (2026) X. Gao, C. Hu, H. Chen, P. Yao, Z. Wang, Y. Bai, Z. Wu, Y. Han, X. Cong, J. Gui, et al. EvoAgentBench: benchmarking agent self-evolution via ability transfer. arXiv preprint arXiv:2607.05202.
6. Guo et al. (2025) J. Guo, Y. Ye, T. He, H. Wu, Y. Jiang, T. Pearce, and J. Bian Mineworld: a real-time and open-source interactive world model on minecraft. arXiv preprint arXiv:2504.08388.
7. Guss et al. (2019) W. H. Guss, B. Houghton, N. Topin, P. Wang, C. Codel, M. Veloso, and R. Salakhutdinov Minerl: a large-scale dataset of minecraft demonstrations. arXiv preprint arXiv:1907.13440.
8. Hill et al. (2023) W. Hill, I. Liu, A. D. M. Koch, D. Harvey, N. Kumar, G. Konidaris, and S. James Mineplanner: a benchmark for long-horizon planning in large minecraft worlds. arXiv preprint arXiv:2312.12891.
9. Huang et al. (2025) J. Huang, X. Hu, B. Han, S. Shi, Z. Tian, T. He, and L. Jiang Memory forcing: spatio-temporal memory for consistent scene generation on minecraft. arXiv preprint arXiv:2510.03198.
10. Li et al. (2026) C. Li, J. Liu, S. Zhang, H. Jian, H. Ni, L. Lee, S. Bae, G. Wang, Y. Yang, and C. Zhang Experience transfer for multimodal llm agents in minecraft game. arXiv preprint arXiv:2604.05533.
11. Li et al. (2025a) Z. Li, Y. Xie, R. Shao, G. Chen, W. Guan, D. Jiang, Y. Wang, and L. Nie Optimus-3: dual-router aligned mixture-of-experts agent with dual-granularity reasoning-aware policy optimization. arXiv preprint arXiv:2506.10357.
12. Li et al. (2024) Z. Li, Y. Xie, R. Shao, G. Chen, D. Jiang, and L. Nie Optimus-1: hybrid multimodal memory empowered agents excel in long-horizon tasks. Advances in neural information processing systems 37, pp. 49881–49913.
13. Li et al. (2025b) Z. Li, Y. Xie, R. Shao, G. Chen, D. Jiang, and L. Nie Optimus-2: multimodal minecraft agent with goal-observation-action conditioned policy. In 2025 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), pp. 9039–9049.
14. Lifshitz et al. (2023) S. Lifshitz, K. Paster, H. Chan, J. Ba, and S. McIlraith Steve-1: a generative model for text-to-behavior in minecraft. Advances in Neural Information Processing Systems 36, pp. 69900–69929.
15. Luo et al. (2025) Y. Luo, C. Fan, M. Dong, J. Shi, X. Mi, M. Zhao, B. Zhang, C. Chi, J. Liu, G. Dai, et al. Robobench: a comprehensive evaluation benchmark for multimodal large language models as embodied brain. arXiv preprint arXiv:2510.17801.
16. Ni et al. (2025) F. Ni, M. Zhang, P. Li, Y. Yuan, L. Zhang, Y. Liu, P. Han, L. Kou, S. Ma, J. Qiao, et al. Embodied arena: a comprehensive, unified, and evolving evaluation platform for embodied ai. arXiv preprint arXiv:2509.15273.
17. Park et al. (2025) J. Park, J. Cho, and S. Ahn MrSteve: instruction-following agents in minecraft with what-where-when memory. In International Conference on Learning Representations, Vol. 2025, pp. 16922–16960.
18. Ren et al. (2026) Z. Ren, Y. Chen, D. Guo, G. Rong, T. Li, R. Xiong, Q. Lan, W. Wang, L. Nanbo, Y. Yang, et al. Self-improvements in modern agentic systems: a survey. arXiv preprint arXiv:2607.13104.
19. Shinn et al. (2023) N. Shinn, F. Cassano, A. Gopinath, K. Narasimhan, and S. Yao Reflexion: language agents with verbal reinforcement learning. Advances in neural information processing systems 36, pp. 8634–8652.
20. Wang et al. (2023) G. Wang, Y. Xie, Y. Jiang, A. Mandlekar, C. Xiao, Y. Zhu, L. Fan, and A. Anandkumar Voyager: an open-ended embodied agent with large language models. arXiv preprint arXiv:2305.16291.
21. Wang et al. (2026) Z. Wang, C. Xu, B. Liu, Y. Wang, S. Han, Z. Yao, H. Yao, and Y. He Agent world model: infinity synthetic environments for agentic reinforcement learning. arXiv preprint arXiv:2602.10090.
22. Wang et al. (2024) Z. Wang, S. Cai, A. Liu, Y. Jin, J. Hou, B. Zhang, H. Lin, Z. He, Z. Zheng, Y. Yang, et al. Jarvis-1: open-world multi-task agents with memory-augmented multimodal language models. IEEE Transactions on Pattern Analysis and Machine Intelligence 47 (3), pp. 1894–1907.
23. Wang et al. (2025) Z. Wang, M. Li, K. He, X. Wang, Z. Mu, A. Liu, and Y. Liang Openha: a series of open-source hierarchical agentic models in minecraft. arXiv preprint arXiv:2509.13347.
24. Xue et al. (2026) S. Xue, Z. Ding, Y. Shen, Y. Wang, Z. Yin, Y. Wu, Y. Chen, M. Wang, and L. Yang Past-bench: benchmarking the foundations of recursive self-improvement in personal agents. arXiv preprint arXiv:2608.04003.
25. Zhao et al. (2024) A. Zhao, D. Huang, Q. Xu, M. Lin, Y. Liu, and G. Huang Expel: llm agents are experiential learners. In Proceedings of the AAAI Conference on Artificial Intelligence, Vol. 38, pp. 19632–19642.
26. Zheng et al. (2025) J. Zheng, X. Cai, Q. Li, D. Zhang, Z. Li, Y. Zhang, L. Song, and Q. Ma Lifelongagentbench: evaluating llm agents as lifelong learners. arXiv preprint arXiv:2505.11942.
27. Zheng et al. (2023) X. Zheng, H. Lin, K. He, Z. Wang, Z. Zheng, and Y. Liang MCU: an evaluation framework for open-ended game agents. arXiv preprint arXiv:2310.08367.

Appendix A Minecraft Environment Settings

MC-EvoBench evaluates whether interaction experience can improve subsequent embodied execution. Its experimental unit joins a source experience, a persistent agent artifact, and a separately initialized target evaluation. This appendix specifies the environment, task construction, verification, experimental protocol, agent interfaces, task suite, and reproducibility materials.

A.1 Game world and interaction interface

The primary environment is Minecraft 1.16.5 through MineRL, with a custom survival specification named MCBenchHumanSurvival-v0. It extends the HumanSurvival environment with observations for inventory, local resources, world conditions, and task events. The agent interacts with the game through an adapter, while a separate evaluator converts the environment response into a normalized observation snapshot. This separation supports a common task definition across agents with different planning and control architectures.

The native control interface consists of movement, camera rotation, attack, use, and inventory operations. Camera commands change pitch and yaw; the meaning of attack and use depends on whether the agent is interacting with the world or an inventory interface. These environment actions produce the observations used for task verification. Text-conditioned controllers translate a task instruction into this action interface. A programmatic agent may use a different bridge, in which case its action granularity is reported with the method settings in Appendix E.

Table A1. Interaction and observation interfaces. The evaluator consumes the evidence needed by a task; an agent consumes the modalities exposed by its declared adapter.

Figure A1. The task specification connects initialization, agent execution, and evaluation. World configuration fixes the problem instance. Agent inputs follow the selected interface, while success is evaluated from environment evidence. Persistent experience crosses source and target runs through the artifact boundary defined in Appendix D.

A.2 Observation access and normalized evidence

The catalog distinguishes native_perception and structured_state observation sources. Each source records a path, its primary or diagnostic role, its interpretation, and an access declaration. Inventory, equipment, and basic survival measurements are examples of declared agent-visible sources. Local block counts, mission flags, kill counters, and world-light diagnostics are classified as structured evidence. RGB-based and structured-state methods therefore remain distinguishable even when they share the same task verifier.

At runtime, the snapshot groups observations into inventory, equipment, player statistics, counters, flags, raw observations, and environment metadata. Equipment names are normalized across MineRL representations, and raw entity-kill observations can populate the corresponding normalized counter. The evaluator preserves the raw channel alongside the normalized value, which makes it possible to trace a predicate back to its observation source. The actual model inputs are determined by the adapter; Appendix E describes the built-in interfaces.

The local block grid spans offsets from (-3,-2,-3) to (3,2,3) around the player, giving a 7\times 5\times 7 observation volume. The ray channel supplies a block identity and distance. Grid counts support local structure checks; ray observations support direct resource visibility. Profile-provided resource markers describe the configured scene and serve as diagnostics. The coal-discovery predicate uses coal observed in the ray channel or local block grid.

A.3 Environment profiles and controlled resources

An environment profile specifies a world seed, time of day, weather, initial inventory, and optional placement metadata. The benchmark includes 12 general environment profiles, all with empty initial inventories. Four forest profiles provide progression, daytime, nighttime, and dusk settings. Controlled-resource profiles place scarce materials near the spawn so that a finite evaluation budget can probe tool preparation, mining, collection, and downstream use. Ore is a world object that the agent must interact with.

Table A2. General environment profile registry. Codes are used in Appendix F. Seeds are profile defaults; an experiment can override them explicitly. All entries initialize an empty inventory.

Resource placement is specified relative to the configured or actual spawn, as recorded in the profile. The multi-resource gallery contains coal, iron, gold, redstone, lapis, diamond, and emerald. These local arrangements standardize access to task materials; they measure execution under controlled resource availability. The source files retain block placement, facing direction, resource identity, and allowed-task metadata.

The paired-transfer configurations use three additional profiles: a mixed wood-species grove, an oak grove, and a stone gallery. They use world seed 31, daylight, clear weather, disabled spawning, and an empty initial inventory. Their nearby resources support paired source and target tasks with comparable access conditions. Related and unrelated source content, interaction budgets, and target substitutions are specified together in Appendix D.

A.4 State continuity within a task chain

The chain specification selects either a task-level or chain-level profile policy. Under the task-level policy, the runner selects each task’s profile; with the default per-stage reset setting, a profile change causes an environment reset. Under the chain-level policy, one selected profile governs the chain. Consecutive stages that remain in the same environment can reuse world resources and inventory, making state continuity an explicit part of chain evaluation.

This within-chain continuity is separate from the source-to-target boundary. A target transfer evaluation starts from its prescribed environment state and receives only the permitted persistent artifact. A tool retained between two stages changes their execution conditions; a tool reconstructed after a target reset provides evidence about execution under the retained agent state. The protocol records these two situations separately.

Appendix B Task Construction and Composition

B.1 Task specification and benchmark coverage

A task is a compact executable contract: an identifier, an instruction, a domain, a step budget, an environment profile, a success specification, and observation-source declarations. Instructions describe ordinary Minecraft objectives such as collecting a resource or crafting a tool. The success specification supplies the measurable endpoint. Keeping these fields together allows the same task to be placed in a short probe, a longer chain, or an independent evaluation without redefining its meaning.

The task catalog contains 80 tasks across building, survival, exploration, and combat. The domain counts are 40, 26, 7, and 7, respectively. The accompanying graph contains 111 state nodes and 369 edges. Its composition rules connect resource acquisition, crafting, tool use, environmental conditions, and high-level events. Appendix F provides the complete task and chain definitions; the machine-readable tables retain the original instructions and predicates.

Table B1. Catalog partitions and their execution denominators. A task identifier can occur more than once in a chain or across chains. Stage occurrences are therefore counted separately from distinct task membership.

The first three partitions define the primary evaluation suite. The calibration partition reuses task definitions for engineering checks and is reported separately. This organization supplies both a stable comparison set and a small set of diagnostic entry points. The task-membership split describes the catalog taxonomy; shared prerequisites can still recur in the executable chains.

B.2 Task–state graph

Let \mathcal{T} denote task nodes and \mathcal{S} state nodes. A state represents an item, tool, location, environmental condition, player condition, structure, entity event, or abstract group. Directed typed edges specify how a task relates to these states. The resulting graph is

\displaystyle G \\ \displaystyle=(\mathcal{T},\mathcal{S},\mathcal{E}), \\ \displaystyle\mathcal{E} \\ \displaystyle=\mathcal{E}_{\mathrm{req}}\cup\mathcal{E}_{\mathrm{prod}}\cup\mathcal{E}_{\mathrm{cons}}\cup\mathcal{E}_{\mathrm{enable}}\cup\mathcal{E}_{\mathrm{abs}}.

Table B2. Edge types in the released catalog. Counts describe graph definitions, before expansion into repeated stage occurrences.

The relations in Eq. B.1 are listed in Table B.2. The first three define the execution paths used in weighted graph progress. Soft enabling and abstraction edges organize capability relationships without contributing to this execution score. This makes the graph useful at two levels: concrete dependencies support composition, while abstract groups organize transfer questions across items or recipes.

Figure B1. A catalog fragment links log collection to plank production. Task nodes and state nodes have distinct shapes; edge labels retain their direction and quantity. The graph describes a declared dependency structure. Runtime observations and task predicates determine which execution stages actually pass.

B.3 Ordered chain compilation

A chain stores an ordered task sequence, initial symbolic states, an environment profile, and a profile policy. The compiler traverses the sequence and extracts five paths for every occurrence: hard prerequisites, produced resources, consumed resources, soft enabling relations, and abstraction relations. Repeated task identifiers become distinct compiled stages, so their positions and local context remain available to the evaluator.

The default compiler checks prerequisite presence in the evolving symbolic state set. An optional strict-quantity mode also checks declared resource counts before consuming and producing them. Let q_{j}(s) be the symbolic availability of state s before stage j. In the strict mode, a stage requires sufficient declared counts, after which its resource bookkeeping follows

q_{j+1}(s)=q_{j}(s)-c_{j}(s)+p_{j}(s),

where c_{j} and p_{j} are the stage’s consumption and production counts. Initial symbolic states seed this calculation; they do not grant physical inventory. The simulator independently realizes movement, mining, crafting, and resource use.

This separation is useful when constructing a benchmark: a chain can be checked for intended ordering before a game is launched, and its execution can then be evaluated from observations. Equation B.2 describes symbolic bookkeeping only. The compilerś output also gives each stage a fixed metric context, with graph weights fixed by the planned chain before execution.

B.4 Composition patterns

Resource progression chains connect acquisition to increasingly demanding use. For example, the ore progression chain moves through wood preparation, basic tools, stone tools, ore collection, smelting, and higher-tier mining. Cross-domain chains join heterogeneous endpoints: locating coal, obtaining fuel, creating illumination, building shelter, and remaining alive, or preparing a weapon before a combat event. Transfer chains substitute wood species, tool recipes, or item roles while retaining comparable dependency patterns.

The task suite also includes short probes. These isolate resource collection or limited crafting sequences, helping distinguish an early execution bottleneck from a long-horizon planning requirement. A short probe and a long chain answer different questions, even when they contain the same task identifier. Their sequence, start state, budget, and profile policy accompany their scores.

A completed possession task establishes its predicate at that stage. If the same item remains in inventory, a later occurrence with the same predicate may pass immediately. The ordered stage record makes this behavior explicit: initial-state passes have zero action steps, while newly acquired items appear in the observed state transition. Composition is consequently described through stage outcomes and state continuity, with experience transfer assessed by the reset protocol in Appendix D.

B.5 Extending the catalog

A new task can be added by defining its instruction and measurable endpoint, identifying the required observation channels, selecting an environment profile, and attaching its graph relations. A new chain then specifies an ordered list of existing or new task identifiers. Compilation checks the declared dependency order, and an execution check verifies that the configured environment exposes the evidence required by its predicates.

The reusable components are the task contract, graph relations, profile registry, and runner interface. A method’s planner, retrieval rule, or memory format remains outside the task definition. This allows a future agent to implement a different experience representation while being evaluated against the same target objectives and evidence rules.

Appendix C Success Verification and Execution Metrics

C.1 Predicate-based task evaluation

MC-EvoBench evaluates success from environment observations. A task contains a conjunction of predicates, with optional disjunctive subexpressions. Inventory thresholds check resource or item possession; equipment predicates accept an item in a specified slot; counters capture events such as an entity defeat; snapshot comparisons read a named observation field. These primitives cover both simple item goals and objectives that combine player state with local environmental conditions.

Table C1. Supported predicate families and their measurement roles.

A snapshot-path comparison fails when its required path is absent. Inventory and counter thresholds use zero for a missing count. The diagnostic record stores the predicate and its observed value, making the distinction between a satisfied condition and unavailable supporting evidence inspectable. Item possession is measured directly from environment observations.

The evaluator checks the initial snapshot before requesting an action. If all predicates already hold, the stage passes with zero steps. Otherwise, it checks after each environment transition until success, a mission failure, environment termination, or budget exhaustion. A stage limit is the smaller of its catalog budget and any configured cap. The normal chain runner stops at the first non-passing stage, preserving the distinction between the observed prefix and unattempted suffix.

C.2 Mission events

Four mission-event definitions extend the basic predicates with observation-derived conditions. Their triggers combine local perception, lighting, elapsed time, and entity events. Event evaluation can attach a normalized flag or counter to the snapshot, after which the ordinary task verifier reads the corresponding evidence. This approach keeps event semantics shared between the runner and the task specification.

Table C2. Mission-event rules. Thresholds are taken from the catalog. The shelter rule is a local structure-and-light criterion; the night rule measures a defined survival interval.

For survive_first_night, the runner also derives night_survived from player survival and elapsed time reaching the effective stage limit. This additional path uses the total-time difference when available; its world-time fallback also requires a night endpoint. Thus the effective interval follows a configured stage cap, while Table C.2 specifies the catalog event rule. Survival, shelter, and combat events include a player-death failure condition. Event records preserve the evidence that caused a terminal decision, so later analysis can connect a stage outcome to the underlying world measurement.

C.3 Stage records and evidence organization

Each stage record identifies the task occurrence, terminal status, action-step count, and failed predicates. Its diagnostics include start and final snapshots, declared observation sources, actual predicate values, mission evidence, and the compiled graph paths. The chain report retains the planned stage count and planned graph weight even when execution stops early.

Table C3. Terminal statuses and their interpretation in chain aggregation.

This record supports analysis at several resolutions. A chain score summarizes completed requirements; stage records locate its execution breakpoint; start and final states describe resource changes; and optional action traces support a finer behavioral account. These resolutions share the same task identity and sequence position.

C.4 Task success rate and weighted graph progress

For chain c, let L_{c} be its number of planned stage occurrences and y_{cj} indicate whether occurrence j passes. Task success rate is

\mathrm{TSR}=\frac{1}{L_{c}}\sum_{j=1}^{L_{c}}y_{cj}.

In Eq. C.1, unattempted stages remain in the planned denominator. At split level, the aggregate pools passed occurrences and planned occurrences across the included chains. This weights every planned occurrence equally, while completed-chain counts offer a complementary measure of end-to-end execution.

For chain c, let E_{\mathrm{exec},c} be its strict execution edges, formed by the requires, produces, and consumes relations. Let w_{e} be the edge weight and q_{e} indicate whether the corresponding verified stage contributes. Edge weights default to one when unspecified. Weighted graph progress is

\mathrm{WGP}=\frac{\sum_{e\in E_{\mathrm{exec},c}}w_{e}q_{e}}{\sum_{e\in E_{\mathrm{exec},c}}w_{e}}.

In Eq. C.2, an edge is credited when its corresponding verified stage contributes. Shared resources can appear in several stage paths, and each occurrence contributes its local edge weight. Split WGP pools completed and planned edge weights across chains. A chain with no planned execution-edge weight falls back to TSR. Together, TSR and WGP summarize stage completion and its execution structure using fixed planned denominators.

C.5 Milestone and efficiency diagnostics

Verified milestone progress (VMP) describes observed acquisition of graph-linked items or tools. For each reported stage, the metric extracts item/tool states from its execution paths and assigns each state the largest included edge-count threshold. A state is eligible if the first recorded snapshot is below its threshold; it is credited if a later recorded stage-start or stage-final snapshot reaches the threshold. The score is

\mathrm{VMP}=\frac{\text{eligible states reaching their thresholds}}{\text{eligible states}},

Equation C.3 returns zero when the eligible set is empty. The associated eligible count is part of its interpretation. Because this set follows the reported prefix, VMP is used as a local acquisition diagnostic alongside the fixed-denominator TSR and WGP endpoints. A task passes when its success predicates hold.

Efficiency summaries include environment steps, stage budgets, steps per passed stage, and observed deaths. Resource-use diagnostics identify consumed items whose inventory decreases during a non-passing stage. This provides a traceable signal of material expenditure associated with unsuccessful execution. Recovery events require an explicit adapter record and can then be aligned with stage transitions.

C.6 Verification examples

The task craft_planks requires at least four oak planks. The objective is therefore satisfied by the corresponding inventory count. For craft_stone_sword, the catalog accepts a stone sword either in inventory or in the main hand, matching the game’s distinction between carrying and equipping a tool. The coal-discovery task uses observed coal in a ray or grid channel; the subsequent coal-collection task checks the collected item.

These examples illustrate why the task contract separates an instruction, its observation sources, and its terminal predicate. The instruction gives the agent a goal, the observation contract defines the evidence channels, and the predicate fixes the endpoint. The same decomposition supports independently checking an item goal, a temporal objective, or a cross-domain chain through explicit predicates.

Appendix D Evaluation protocol

D.1 Experience, artifact, and target evaluation

MC-EvoBench separates capability measurement from the experience that may change an agent. A paired evaluation first measures a target with the base agent, then measures the same target with an artifact produced through a specified source curriculum. The artifact may contain updated parameters, memory, a skill library, or another declared persistent representation. Its identity and provenance define the agent state being evaluated. This interface accommodates different adaptation mechanisms while keeping the target task and its verifier fixed.

At the source-to-target boundary, the target world and inventory are reset. Only the frozen method-produced artifact crosses this boundary. Consequently, tools, blocks, completed constructions, and resource inventories accumulated during source interaction do not supply target progress. In the supplied memory configuration, source interaction uses read_write memory and target evaluation uses read_only memory. Each target role constructs a fresh agent and environment; persistent source experience is loaded from its declared artifact.

Within a compiled chain, stages execute in order and preserve the environment state permitted by the chain profile. The runner stops at the first non-passing stage. The transfer probes use one chain-level profile throughout an episode. Source episodes can restart to complete their interaction budget, as described in Appendix D.3. These distinct boundaries preserve sequential task dependencies within an episode and isolate learned experience across evaluations.

Figure D1. Each source condition produces its own artifact from the same base agent. Target evaluations share task, world, budget, and seed settings. At the boundary, the world, inventory, and transient agent state are reset while the declared persistent artifact is retained.

D.2 Paired target roles and controls

Each probe and replicate defines three source roles and four target roles. All four target roles use the same target task sequence, verifier, environment profile, world seed, stage limits, and agent seed. They differ in the artifact supplied to the agent.

Table D1. Target roles and the question addressed by each source condition.

The unrelated and shuffled source conditions receive the same family-level environment-step budget as the related condition. The shuffled source uses the identical task multiset, including repeated tasks. Its probe explicitly allows compilation with unmet prerequisites, making the reversed sequence executable without adding inventory or changing success predicates. Normal runtime stopping rules still apply, so the resulting experience can include repeated unsuccessful episodes.

The target input contract provides the natural-language instruction and agent observation, together with the declared artifact. It reserves graph-relation manifests, verifier predicates, verifier diagnostics, and hidden resource coordinates for evaluation. The built-in method inputs are detailed in Appendix E. Public resource placement defines the controlled task instance. It does not supply target inventory items, forced success evidence, private route hints, or scripted actions.

D.3 Frozen transfer probes and source exposure

The protocol provides three shorter graph-chain families assembled from catalog tasks. Shorter targets make transfer at intermediate capabilities observable even when a long progression chain stops at an early prerequisite. The plan freezes task sequences, resource profiles, source–target relations, and budgets before adaptive paired evaluation.

Table D2. Transfer probe families. Source exposure is matched within each row; the target sequence is held fixed across artifact conditions.

The wooden-tool pair shares the log, plank, stick, and crafting-table preparation sequence. The stone-tool pair additionally shares wooden-pickaxe preparation and two cobblestone-mining stages. Unrelated source sequences contain the same number of stages and use collection tasks outside the selected production chain. The resource profiles provide local world resources while retaining the need to acquire and transform them through agent interaction.

The probe configuration imposes a 450-step ceiling on each stage, retaining a lower catalog limit if one exists. The fixed-exposure source runner is enabled by experiment.source_interaction_budget_steps. Source exposure is measured as actual environment interactions. If a source episode ends before its family budget is consumed, the agent receives normal terminal feedback, the source environment resets, and interaction resumes with the persistent method artifact. The last episode is truncated at the remaining budget. Thus early completion or failure changes the number of episodes without reducing the prescribed source exposure. The source report records every episode and the total interaction count; a final paired comparison requires all three source conditions to consume the common budget.

D.4 Replicates and reproducibility

The headline paired protocol uses five final agent seeds, 5100–5104. Separate calibration checks may use at least three direct seeds, but they are not part of the 105 role configurations or the headline results. The replicate axis is agent randomness on a fixed controlled world: the public world seed is 31. Fixing the world preserves the declared spawn placement and local resource layout across conditions. The resulting paired estimates characterize variation across agent seeds on these controlled instances.

Run labels such as seed0 identify records; numerical world_seed and agent_seed fields determine randomization. The runner applies the world seed to the environment and seeds Python, NumPy, and PyTorch before constructing the policy. Reports retain both seeds and their provenance. Every role in a paired replicate uses the same numerical seeds, and the same replicate list is used across conditions.

Before rollout, the launcher checks the declared resource profile through an environment reset. Artifact manifests record identities and paths, with SHA-256 fingerprints available for files and directory bundles. Together, the frozen plan, explicit seeds, artifact identity, and runtime configuration specify a reproducible comparison.

D.5 Transfer contrasts

TSR, WGP, and VMP follow the definitions in Appendix C. Let M_{0},M_{R},M_{U},M_{S} denote a target score with no prior, related, unrelated, and shuffled artifacts, respectively. Define each source condition’s change from the no-prior target as

\Delta_{c}=M_{c}-M_{0},\qquad c\in\{R,U,S\}.

The paired differences in Eq. D.1 are interpreted across the three direct metrics. A related-source change is compared with both the no-prior baseline and the matched unrelated and shuffled controls; these are contrasts over TSR, WGP, and VMP rather than additional benchmark metrics. Target TSR is the primary channel, while WGP and VMP provide complementary completion and acquisition diagnostics.

D.6 Statistical and diagnostic reporting

Compute contrasts within each matched replicate before summarizing across seeds. Report the four target scores and paired differences for each direct metric, with their means and sample standard deviations. The aggregation helper also computes two-sided 95% Student-t intervals on paired seed contrasts:

\bar{d}\ \pm\ t_{0.975,n-1}\frac{s_{d}}{\sqrt{n}}.

For the interval in Eq. D.2, n is the number of valid pairs and s_{d} is the sample standard deviation of paired differences. A beneficial-transfer interpretation requires a positive related-source change relative to the no-prior baseline and matched controls, supported by paired uncertainty. Metric configurations are also characterized as floor-limited, ceiling-limited, or interior. The accompanying progress channels localize capability acquisition across these score regimes.

Report environment steps alongside source episode counts, outcomes, memory updates, planner calls, and token usage. Equal environment exposure can produce different amounts of planning and updating because episodes terminate at different points. These diagnostics characterize the resources used to create each artifact and support computation-aware comparisons. Per-seed target scores and source exposure remain available alongside aggregate statistics, allowing transfer and efficiency to be assessed together.

D.7 Per-seed transfer records

Table D.7 lists the per-seed target TSR values behind Figure 3b–c and Table 4, computed within each matched replicate as described in Appendix D.6.

Table D3. Per-seed target TSR under the four target conditions: no prior (N), related (R), unrelated (U), and shuffled (S). \Delta R=R-N and \mathrm{GATG}=R-\frac{1}{2}(U+S) are computed within each seed; values are rounded to three decimals.

Appendix E Agent implementations

E.1 Observation and action interfaces

MC-EvoBench connects policies to a common chain runner through a policy factory, a reset operation, and an action function. At each interaction, the adapter supplies the task instruction and current observation and receives a MineRL action mapping. The default prompt template is the instruction itself. Optional callbacks provide stage status and the number of executed steps, allowing methods with persistent memory to update after source experience. Table E.1 specifies the implemented method variants and their effective inputs; these interfaces define the observation, action, and persistent-state conditions used in each comparison. The table documents supported adapters; the headline reference study reported in the main paper uses only the JARVIS-1 online extension, while the other entries do not contribute to the paired-transfer results.

Table E1. Implemented agent interfaces. “Persistent state” identifies information retained by the bridge for later decisions.

The STEVE-1 and JARVIS controller bridges encode text with MineCLIP and a learned prior, cache embeddings by prompt, and reset the conditional controller with guidance scale 6.0. VPT loads its network specification and policy-head settings from the model file; its sampling temperature is inherited from that file. Optimus-3 creates a task representation when the instruction changes, then combines it with successive frames.

E.2 Persistent experience and adaptation

The JARVIS online extension stores stage-level textual records containing the instruction, proposed plan, dispatched controller prompts, status, interaction count and visible-state summary. Retrieval uses token-set Jaccard similarity between the current instruction and each stored instruction, adds 0.15 for a successful record, and breaks score ties in favour of newer records. Up to four positive-scoring records condition planning. Memory retains the latest 256 records and is written atomically. The planner returns one to six short controller prompts; reflection produces a practical sentence capped at 500 characters. The reflection input distinguishes a proposed plan from prompts actually dispatched and labels the state summary as the last pre-action observation.

ExpeL uses the same episode-retrieval score and supplements episodes with retrieved textual insights and a weighted rule list. Insight retrieval uses lexical overlap; rule retrieval adds a weight contribution capped at 0.10. With the configured insight limit of eight, the planner may receive up to eight insights and eight rules. Reflection proposes ADD, EDIT, REMOVE and AGREE operations. New rules start with weight two; agreement and editing increment weight, while removal decrements it. The persistent artifact records these updates alongside episode actions. Both memory methods support read-write source interaction and read-only target evaluation; read-only stage callbacks suppress reflection and memory writes.

E.3 Planning and execution cadence

The JARVIS extension plans when a new stage instruction becomes active. It dispatches successive subgoals for fixed 120-step intervals and retains the final subgoal for any remaining stage steps. Stage completion invalidates the active instruction so repeated task text can trigger a new plan. Optimus-1’s visual planner uses the same interval rule and a JSON subgoal format. Its input is a JPEG thumbnail bounded by 384 \times 384 pixels at quality 85. The parser filters subgoals containing “open,” “place,” or “access” followed by a space, rewrites punch/collect/gather to chop, and retains up to six subgoals. ExpeL instead requests a low-level action mapping and can hold that action across a configured number of environment steps. The 19-chain configuration sets this hold to 32, while the factory default is one. Its prompt also supplies explicit line-of-sight guidance for approaching and mining visible resources.

The Voyager skill bridge follows a separate execution protocol. The runner loads released JavaScript skills and control primitives, resets through the Mineflayer bridge with empty inventory and equipment, and invokes a fixed skill sequence. A configured starting position is applied during setup. The runner checks the returned inventory for its designated target item. Its step count denotes a bridge request, and the implementation invokes no LLM; this execution unit is recorded separately from MineRL interaction steps.

E.4 Configured parameters and replication

Table E.4 reports configuration values and the defaults used where configurations omit a field. Planner model identifiers are recorded literally because the standard and relay matrices select different providers. Planner calls leave temperature unspecified. Token limits bound generated output, and timeout or retry settings describe request handling rather than additional environment interaction.

Table E2. Configuration values and implementation defaults. J = JARVIS online extension; O = Optimus-1 planner bridge; E = ExpeL adaptation.

The standard and relay configurations instantiate the same benchmark roles through different planner interfaces. A reproducible method specification records the selected matrix, policy checkpoint, observation channels, action cadence, planner identity, and memory mode. Replicate seeds and source budgets follow Appendix D. These fields allow the effect of the experience mechanism to be interpreted alongside its controller and computational settings.

Appendix F Complete Benchmark Suite

F.1 Task inventory

Tables F.1–7 enumerate the 80 task definitions once. The code T01–T80 is a compact cross-reference used only in this appendix; the adjacent identifier is the executable catalog key. “Steps” is the catalog stage budget, before an experiment applies a smaller cap. Profile codes refer to Table A.3. Success conditions specify the required observed endpoint; event abbreviations refer to the exact rules in Appendix C.

The supplementary CSV preserves each original natural-language instruction and the full JSON success specification. This keeps the printed table compact while providing an exact machine-readable mapping between the manuscript, task identifiers, and evaluator predicates. In a chain, each occurrence retains its task’s definition and receives the profile selected by the chain policy.

Table F1. Core Progression: 33 task definitions.

Table F2. Transfer and Schema Generalization: 31 task definitions.

Table F3. Supplementary Diversity and Exploration: 16 task definitions.

F.2 Ordered chain registry

A sequence below gives every task occurrence, including repetitions. Task codes expand through Tables F.1–7. Each chain begins with the symbolic state environment:spawned_world; no physical resource is created by that symbolic entry. The night_combat_probe chain additionally declares symbolic initial states structure:lit_shelter and tool:stone_sword; these declarations do not inject physical resources. “Task” selects the stage’s task profile, whereas “chain” retains the listed chain profile. The runtime state-continuity rule is defined in Appendix A.4.

Table F4. Core Progression: exact chain sequences.

Table F5. Transfer and Schema Generalization: exact chain sequences.

Table F6. Supplementary Diversity and Exploration: exact chain sequences.

Table F7. Calibration and Probe: exact chain sequences.

F.3 Detailed direct capability results

The direct capability matrix in Table 2 reports partition-level averages. Table F.3 expands those values to the 12 primary chains and the nine direct configurations. Each chain occupies three rows that report TSR, WGP, and VMP. The seven calibration and probe chains are retained in the complete chain registry but are not included in this expansion. Table F.3 fixes the protocol under which these direct results were collected.

Table F8. Per-chain direct capability results for the 12 primary evaluation chains underlying Table 2. Each chain occupies three rows reporting TSR, WGP, and VMP in percent. The two planner-backed columns report GPT-5.6-sol runs. The nine scored direct configurations exclude the separately marked ExpeL runs. A superscript 2 marks a two-seed report.