Experience-based Knowledge Correction for Robust Planning in Minecraft
Authors: Seungjoon Lee
Suhwan Kim
Minhyeon Oh
Youngsik Yoon
Jungseul Ok
Venue: ICLR 2026 Poster (2026)
Keywords: LLM-guided exploration
hierarchical planning
LLM knowledge correction
Primary area: applications to robotics, autonomy, planning
TL;DR: We propose an LLM-guided exploration algorithm robust to potential errors of LLM-generated high-level plans

Abstract: Large Language Model (LLM)-based planning has advanced embodied agents in long-horizon environments such as Minecraft, where acquiring latent knowledge of goal (or item) dependencies and feasible actions is critical. However, LLMs often begin with flawed priors and fail to correct them through prompting, even with feedback. We present XENON (eXpErience-based kNOwledge correctioN), an agent that algorithmically revises knowledge from experience, enabling robustness to flawed priors and sparse binary feedback. XENON integrates two mechanisms: Adaptive Dependency Graph, which corrects item dependencies using past successes, and Failure-aware Action Memory, which corrects action knowledge using past failures. Together, these components allow XENON to acquire complex dependencies despite limited guidance. Experiments across multiple Minecraft benchmarks show that XENON outperforms prior agents in both knowledge learning and long-horizon planning. Remarkably, with only a 7B open-weight LLM, XENON surpasses agents that rely on much larger proprietary models.

Published as a conference paper at ICLR 2026
EXPERIENCE-BASER KNOWLEDGE CORRECTION FOR ROBUST PLANNING IN MINECRAFT
Seungjoon Lee', Suhwan Kim', Minhyeon Oh', Youngsik , Ok!
"Department of Computer Science and Engineering, POSTECH Graduate School Artificial Intelligence, POSTECH (s [lee1218, suhwankim, minhyeon. ch, ysyoon97, jungseul] @postecc.ccco. ac. .c.k.
ABSTRACT
Large Language Model (LLM))based planning has advanced embodied agents in long-horizon environments such as Minecraft, where acquiring latent knowledge of goal (or item) dependencies and feasible actions is critical. However, L.MMs often begin with flawed priors and fail to correct them through prompting, even with feedback. We present XENON (eXpErience-based KNOwledge correctioN), an agent that algorithmically revises knowledge from experience, enabling robustness to flawed priors and sparse binary feedback. XENON integrates two mechanisms: Adaptive Dependency Graph, which corrects item dependencies using past suc- cesses, and Faiture-aware Action Memory, which corrects action knowledge using past failures. Together, these components allow XENON to acquire complex dependencies despite limited guidance. Experiments across multiple Minecraft benchmarks show that XENON outperforms prior agents in both knowledge learn- ing and long- mor-zooizonn planning. Remarkably, with only a open- spen-weightt LLM, XENON surpasses agents that rely on much larger proprietary models. Project page: https://s me github........ Lo/XENON
INTRODUCTION
Large Language Model (LLM)-based planning has advanced in developing embodied Al agents that tackle long-horizon goals in complex, real-world-like environments (Szot et al. 2021 Fan et al. representative testbed for evaluating planning capability that captures the complexity of such environments (Wang et al. 2023b c Zhu al. [2033] Yuan al. 20023 Feng et al. 2024 Li al. (0024b). Success in these environments often depends on agents acquiring planning knowledge, including the dependencies among goal items and the valid actions needed to obtain them. For instance, obtain an iron nugget an agent should
2022). Among such environments, Minecraft has emerged
first possess an iron ingot C, which can only be obtained by the action smelt.
LLMS often begin with flawed priors about these dependencies and actions. This issue is indeed critical, since a lack of knowledge for a single goal can invalidate all subsequent plans that depend on it (Guss al. 2019 Lin et 202T Mao al., 2022). We find several failure cases stemming from these flawed priors, a problem that is particularly pronounced for the lightweight I.LMs suitable practical embodied agents. First, an L.M often fails predict planning ledge accurately enough to generate successful plan (Figure [p), resulting in complete halt in progress toward more challenging goals. Second, an LLM cannot robustly correct its flawed knowledge, even when prompted to self-correct with failure feedback (Shinn et al. 2023 Chen et al.) 2024), often repeating the same errors (Figures DC and [d). To improve self self-correction, one can employ more advanced techniques that leverage detailed reasons for failure (Zhang al.) 2024; Wang et al. (023a). Nevertheless, LLMs often stubbornly adhere to their erroneous parametric knowledge (i.e. knowledge implicitly stored in model parameters), evidenced by (Stechly al. (2024) and Du et al. (2024).
However,
In response, we propose XENON (eXpFrience-basse based kNOwledge correctioN), an agent that robustly learns planning knowledge from only binary success/failure feedback. To this end, instead of relying on an LLM for correction, XENON algorithmically and directly revises its external knowledge memory using its own experience, which in turn guides its planning. XENON learns this planning
Corresponning author; Jungseul Ok < <jungseul @pwstech.ac.cc....

---

Published as a conference paper at ICLR 2026
(a) True Dependency Graph
(c) LLM self-correction for dependencies (Ground-truth for CP
Correct
dependency
You failed get CP many times.
Ca requires
Mixsdd
You hed those times.
depensincty
Fail!
Radundant
depentency
Piferattemat
Correction prompt
Helluchinted frem
(b)
LLM- LLMd-ceddcted Graph
LLM selfccorection actions (Ground-truth for Oo "craft"
|wiill
You failed to "mine" CP many times.
Iwill
"atatee
again
Wrong
"onine
You had
those times.
Iailted sincel had
and
Fail!
Ground-
trudh
Pricr anterntt
Noxt uttempt
Figure 1: An LLM exhibits flawed planning knowledge and fails at self-correction. (b) The dependency graph predicted by Qwen2.5-VL-77B (Bai et al., 2025) contains multiple errors (e-g.. missed dependencies, hallucinated items) compared to (a) the ground truth. (c, d) The LLM fails to correct its flawed knowledge about dependencies and actions from failure feedbacks, often repeating the same errors. See Appendix for the full prompts and LLM'' self-correction examples.
knowledge through two synergistic components. The first component, Adaptive Dependency Graph (ADG), revises flawed dependency knowledge by leveraging successful experiences to propose plausible new required items. The second component, Failure-aware Action Memory (FAM), builds and corrects its action knowledge by exploring actions upon failures. In the challenging yet practical setting of using only binary feedbacks, FAM enables XENON to disambiguate the cause of a failure, distinguishing between flawed dependency knowledge and invalid actions, which in turn triggers a revision in ADG for the former.
Extensive experiments three Minecraft testbeds show that XENON excels at both knowledge acquisition and planning. XENON outperforms prior agents in learning knowledge, showing unique robustness to LLM hallucinations and modified ground-truth environmental rules. Furthermore, with only 7B LLM, XENON significantly outperforms prior agents that rely on much larger proprietary models like GPT-4 in solving diverse long-horizon horizon goals. These results suggest that robust algorithmic knowledge management can be a promising direction for developing practical embodied agents with lightweight L.MSs (Belcak et al. 2025).
Our contributions are as follows. First, we propose XENON, an LLM-bbsee agent that robustly learns planning knowledge from experience via algorithmic knowledge correction, instead of relying on the LLM self-correct its own knowledge. We realize this idea through two synergistic mechanisms that explicitly store planning knowledge and correct it: Adaptive Dependency Graph (ADG) for correcting dependency knowledge based on successes, and Failure-awar Action Memory (FAM) for correcting action knowledge and disambiguating failure causes. Second, extensive experiments demonstrate that XENON significantly outperforms prior state-of-the-art agents in both knowledge learning and long-horizon goal planning in Minecraft.
2
RELATED WORK
2.1
LLM-BASED PLANNING IN MINECRAFT
Prior work has often address LLMs' flawed planning knowledge in Minecraft using impractical methods. For example, such methods typically involve directly injecting knowledge through LLM fine-tuning (Zhao et al.) 2023 Feng et al., 2024 L.u al. 2025; Qin et al. 2024) or relying on
curated expert data [Wang et al. 2023c Zhu al. 2023 Wang et al. 2023a).
Another line work attempts to learn planning knowledge via interaction, by storing the experience of obtaining goal items in external knowledge memory. However, these approaches are often limited by unrealistic assumptions or lack robust mechanisms to correct the LLM's flawed prior knowledge. For example, ADAM and Optimus-I artificially simplify the challenge of predicting and learning dependencies via shortcuts like pre-supplied items, while also relying on expert data such as learning curriculum (Yu & Lu 2024) Minecraft wiki (Li et al. 2024b). They also lack robust
2

---

Published as a conference paper at ICLR 2026
way to correct wrong action choices in plan: ADAM has none. and Optimus- I relies unreliable LLM self celf-correction. Our most similar work, DECKARD (Nottingham et al. 2023). J uses an LLM to predict item dependencies but does not revise its predictions for items that repeatedly fail, and when a plan fails, it cannot disambiguate whether the failure is due to incorrect dependencies or incorrect actions. In contrast, our work tackles the more practical challenge of learning planning knowledge and correcting flawed priors from only binary success/failure feedback.
2.2 LLM-BASED SELF-CORRECTION
LLM self-correction, ie., having LLM correct its own outputs, is promising approach to overcome the limitations of flawed parametric knowledge. However, for complex tasks like planning. LLMs struggle to identify and correct their own errors without external feedback (Huang al. 2024 Tyen et al., 2024). To improve self-correction, prior works fine-tune LLMs (Yang et al. 2025 or prompt LLMs correct themselves using environmental feedback (Shinn et al.) (023) and -ool-execution results (Gou et al. 2024). While we also use binary success/failure feedbacks, we directly correct the agent's 's knowledge in external memory by leveraging experience, rather than fine-tuning the LLM or prompting it to self-correct.
PRELIMINARIES
We aim to develop agent capable of solving long-horizon goals by learning planning knowledge from experience. As a representative environment which necessitates accurate planning knowledge, consider Minecraft as our testbed. Minecraft is characterized by strict dependencies among game items (Guss et al. 2019 Fan et al., 2022), which can be formally represented as a directed acyclic graph 9 (V*, E where V is the set of all items and each edge (u, q, v) Ex indicates that q quantities of an item are required to obtain an item ea A goal is to obtain an item g E V To obtain g. an agent must possess all of its prerequisites as defined by G in its inventory, and perform the valid high-level action in A = ("mine", "craft", "smelt").
Framework: Hierarchical agent with graph-augmented planning. We employ a hierarchical agent with an LLM planner and low-level controller, adopting a graph-augmenter planning strat- egy (Li et al. 2024b) Nottingham et al.) 2023). In this strategy, agent maintains its knowledge graph G and plans with G to decompose a goal into subgoals in two stages. First, the agent identifies pre- requisite items it does not possess by traversing 9 backward from g to nodes with no incoming edges (i.e., basic items with no known requirements), and aggregates them into a list of (quantity, item) tuples, ((11, ui),..,, (4L,: "L = (1, Second, the planner LLM converts this list into executable language subgoals {aa gt, u) [ where takes each u, as input and outputs a high-level action a to obtain uy Then the controller executes each subgoal, i.e., it takes each language subgoal as input and outputs a sequence of low-level actions in the environment to achieve it. After each subgoal execution, the agent receives only binary success/failure feedback.
To plan correctly, the agent must acquire knowledge of the true dependency graph G*. However, G is latent, making it necessary for the agent to learn this structure from experience. We model this as revising a learned graph, 9 = (V, where D> contains known items and represents the agent's current belief about item dependencies. Following Nottingham et al.) (2023), whenever the agent obtains experienced requirement set Res(("), the set of (item, quantity) pairs consumed during this item acquisition. The agent then updates G by replacing all existing incoming edges to with the newly observed (v). The detailed update procedure is in Appendix
Problem formulation: Dependency and action learning,
item v, it identifies the
We aim to maximize the accuracy of learned graph & against true graph G". We define this accuracy Ntrue (9) as the number of items whose incoming edges are identical in 9 and G", i.e.,
Nerue (g) = Σ I(R(e, R((,
VEV'
'n our actual implementation, each edge also stores the resulting item quantity. but we omit it from the notation for presentation simplicity, since most edges have resulting item quantity and this multiplicity is not essential for learning item dependencies.
3

---

Published as a conference paper at ICLR 2026
where the dependency set, R(v, 9), denotes the set of all incoming edges to the item in the graph g.
METHODS
XENON is an LLM-based agent with two core components: Adaptive Dependency Graph (ADG)
and Failure-aware Action Memory (FAM), as shown Figure 3 ADG manages dependency knowledge, while FAM manages action knowledge. The agent learns this knowledge in loop that starts by selecting an unobtained item as an exploratory goal (dctailed in Appendix G Once an item goal 9 is selected, ADG, our learned dependency graph G, traverses itself to construct ((1,, "1 (i)...... (qL,, ML,,) ) (1,g)). For each u in this list, FAM either reuses a previously successful action for in or, if none exists, the planner L.M selects high-level action o₁ E A given uj and action
histories from FAM. The resulting actions form language subgoals {(ar, qt, ut) ))) The controller then takes each subgoal as input, executes sequence of low-level actions to achieve it, and returns binary success/failure feedback, which is used to update both ADG and FAM. The full procedure is outlined in Algorithm in Appendix D We next detail each component, beginning with ADG.
4.1 ADAPTIVE DEPENDENCY GRAPH (ADG)
Dependency graph initialization. To make the most of the LLM's prior knowledge, albeit incomplete, we ini-
[JS) Goal & item requiramnts
LLM
tialize the learned dependency graph 9 (V.E) us- ing an LLM. We follow the initialization process of DECKARD (Nottingham et al.] 2023), which consists of two steps. First, V is assigned Vo. which is the set of goal items whose dependencies must be learned, and & assigned 6. Second, for each item v in V. the LLM is prompted to predict its requirement set (i.e. incoming edges of v), aggregating them to construct the initial graph.
Adaptive Dependency Graph
fal-X
Call
Fippst successful subgoel
actions are invalld
33.0
subgoal y
Failure awware
Controller
Action Memory
Aitiction history
b Subgoal Fallures
Environment
Figure 3: Overview. XENON up- dates Adaptive Dependency Graph and Failure-aware Action Memory with en- vironmental experiences.
However, those L..--predieeed requirement sets often include items not present the initial set Vo, which a phenomenon overlooked by DECKARD. Since Vo may be an incomplete subset of all possible game items V", we cannot determine whether such items are genuine required items or hallucinated items which do not exist in the environment. To address this, we provisionally accept all LLM requirement set predictions. We iteratively expand the graph by adding any newly mentioned item to > and, in turn, querying the L.M for its own requirement set. This expansion continues until a requirement has been predicted for every item in V?. Since we assume that the true graph G* is DAG, we algorithmically prevent cycles in G: see Appendix E.2 for the cycle-check procedure. The quality of this initial L.eM-predittdd graph is analyzed in detail in Appendix K.1
Dependency graph revision. Correcting the agent's 's flawed dependency knowledge involves two challenges: (1) detecting and handling hallucinated items from the graph initialization, and (2) proposing new requirement set. Simply prompting an LLM for corrections is ineffective, as it often predicts new, flawed requirement set, as shown in Figures 1 and 1 Therefore, we revise ς algorithmically using the agent's 's experiences, without relying on the LLM.
To implement this, we introduce a dependency revision procedure called RevisionByAnee and revision count C(v) for each item e E D. This procedure outputs revised graph by taking item whose dependency needs be revised, its revision count C(v), and the current graph ş as inputs, leveraging the required items of previously obtained items. When a revision for an item is triggered by FAM (Section 4.2). the procedure first discards u's existing requirement set (i.e., R(v, 9) + (). increments the revision count C(v) for v. Based on whether C(r) exceeds a hyperparameter co- Revis i Ana ogy proceeds with one of the following two cases:
Case 1: Handling potentially hallucinated items (C(c) > cg). If an item remains unobtainable after excessive revisions, the procedure flags it as inadmissible to signify that it may be halluci- nated item. This reveals critical problem: if o is indeed hallucinated item, any of its descendants
4

---

Published as a conference paper at ICLR 2026
(a) Dependency Correction for
(b) Action Correction for
ADG
Case
ADG
ADG
FAM
Prompt
Subgoal
Descendant
(eeff)
Fallure
action :mine, craft, smelt"
"craft"
Dewenddent
Iinnetss
Invalid action
"craft"
Follucinated
"smelt"
"Select action mine, craft smelt"
Recursively call Revision@yAnaaogy
Search similar, obtained items
Replace wrong dependency
Determine remove
Try expeneedd action
invalid actions
Figure 4: XENON's algorithmic knowledge correction. (a) Dependency Correction via Revis AerissinByAnne logy.. scendants recursively revised to remove the flawed dependency. Case 2: A flawed requirement set is revised by referencing similar, obtained items. (b) Action Correction via FAM. FAM prunes invalid actions from the LLM's prompt based on failures, guiding it to select an under-explored action.
ogy. Case I: For an inadmissible item (e.g.. a hallucinated item), its de-
in & become permanently unobtainable. To enable XENON to try these descendant items through alternative paths, we recursively call Revi s onByAna ogy for all of v's descendants G, removing their dependency on the inadmissible item (Figure 4 Case 1). Finally, to account for cases where may be genuine item that is simply difficult to obtain, its requirement set R(v, G) is reset to a general set of all resource items (i.e. items previously consumed for crafting other items), each with quantity of hyperparameter a;
Case 2: Plausible revision for less-tried items (C(u) S cg). The item e's requirement set, R(v g), is revised to determine both a plausible set of new items and their quantities. First, for plausible required items,
an idea that similar goals often share similar preconditions (Yoon) et al. 2024). Therefore, we set the new required items referencing the required items of the top-K similar, successfully obtained items (Figure 4h, Case 2). We compute this item similarity as the cosine similarity between the Sentence- BERTT (Reimers & Gurevych] 2019) embeddings names. Second, determine their quantities, the agent should address the trade-off between sufficient amounts to avoid failures and an imperfect controller's difficulty in acquiring them. Therefore, the quantities of those new required items are determined by gradually scaling with the revision count, (u))
item
Here, the herparraeeeer serves as the revision count threshold for flagging item as inadmissible. a; and a₂ control the quantity of each required item for inadmissible items (Case 1), and for less-tried items (Case 2), respectively, maintain robustness when dealing with an imperfect controller. K determines the number of similar, successfully obtained items to reference for (Case 2). Detailed pseudocode of BovisionBAAnaloo is in Appendix E.3
Algorithm
4.2 FAILURE-AWARE ACTION MEMORY (FAM)
FAM is designed to address two challenges of learning only from binary success/failure feedback: (I) discovering valid high-level actions for each item, and (2) disambiguating the cause of persistent failures between invalid actions and flawed dependency knowledge. This section first describes FAM's core mechanism, and then details how it addresses each of these challenges in turn.
empirical action classification. FAM classifies actions as either empirically valid or empirically invalid for each item, based on their history of past subgoal outcomes. Specifically, for each item E Y and action E A, FAM maintains the number of successful and failed outcomes, denoted as S(a, v) and F(a, v) respectively. Based on these counts, an action a classified as empirically invalid for if it has failed repeatedly, (i.c., F(a, v) > S(a, v) 2o); otherwise, it is classified as empirically valid if it has succeeded at least once (i.c., S(a, > and S(a, v) F(a, v) .ry). The hyperparameter 2o controls the tolerance for this classification, accounting for the possibility that an imperfect controller might fail even with an indeed valid action.
Core mechanism:
Addressing challenge 1: discovering valid actions. FAM helps XENON discover valid actions by avoiding repeatedly failed actions when making subgoal sgi (at, qi, w). Only when FAM has no empirically valid action for u, XENON queries the LLM to select an under-explored action for constructing sg,. To accelerate this search for valid action, we query the L.M with (i) the
5

---

Published as a conference paper at ICLR 2026
current subgoal item uy (ii) empirically valid actions for top- similar items successfully obtained and stored in FAM (using Sentence-BERR similarity as in Section [4J]). and (iii) candidate actions for ut that remain after removing all empirically invalid actions from A (Figure 4b). We prune action candidates rather than include the full failure history because I.LMs struggle to effectively utilize long prompts (Li et al. 2024a] Liu et al.) 2024). If FAM already has an empirically valid one, XENON reuses it to make sg: without using LLM. Detailed procedures and prompts are in Appendix F
Addressing challenge 2: disambiguating failure causes. By ensuring systematic action exploration, FAM allows XENON determine that persistent subgoal failures stem from flawed dependency knowledge rather than from the actions. Specifically, once FAM classifies all actions in A for an item as empirically invalid, XENON concludes that the error lies within ADG and triggers its revision. Subsequently, XENON resets the item's 's history in FAM to allow for a fresh exploration of actions with the revised ADG.
4.3 ADDITIONAL TECHNIQUE: CONTEXT-AWARD REPROMPTING (CRE) FOR CONTROLLER
In real-world- environments, imperfect controller can stall (e.g., in deep water). To address this, XENON employs context-aware reprompting (CRe), where an LLM uses the current image observation and the controller's language subgoal decide whether replace the subgoal and propose a new temporary subgoal to escape the stalled state (e.g.. "get out of the water"). Our CRe is adapted from Optimus-1 I (Li al. 2024b) to be suitable for smaller LLMs, with two differences: (I) a two-stage reasoning process that captions the observation first and then makes a text-only decision on whether to replace the subgoal, and (2) a conditional trigger that activates only when the subgoal for item acquisition makes no progress, rather than at fixed intervals. See Appendix H for details.
5
EXPERIMENTS
5.1 SETUPS
Environments. We conduct experiments in three Minecraft environments, which we separate into two categories based on their controller capacity. First, as realistic, visually-rich embodied AI environments, we use MineRL (Guss et 2009) and Mineflayer (PrismarineJJS] (023) with imperfect low-level controllers:
STEVE-1 (Lifshitz et al.) 2023) in MineRL. and hand-crafted codes (Yu & Lu 2024) in Mineflayer. Second, we use We-TextWorld (Zheng et al.) (025) as a controlled testbed with a perfect controller. Each experiment in this environment is repeated over 15 runs; in our results, we report the mean and standard deviation, omitting the latter when it is negligible. In all environments, the agent starts with an empty inventory. Further details environments in [ppendix Additional experiments a household task planning domain other than Minecraft are reported in Appendix A where XENON also exhibits robust performance.
provided
Evaluation metrics. For both dependency learning and planning evaluations, we utilize the 67 goals from 7 groups proposed in the long- horizon task benchmark (Li et al.] (0224)). To evaluate dependency learning with an intuitive performance score between O and 1, we report Nuwe (C), where Nuuee (9) is defined in Equa- tion ( We refer this normalized score as Experienced Graph Accuracy (EGA). To evalu- ate planning performance, we follow the bench- mark setting (Li et al., 2024bb:: at the beginning of each episode, goal item is specified exter- nally for the agent, and measure the average success rate (SR) of obtaining this goal item in MineRL. See Table for the full list of goals.
Table Comparison of knowledge correction mechanisms across agents, O: Our proposed mech- anism (XENON), A: LLM self-correction, X: No correction, -: Not applicable.
Dependency Correction
Action Correction
Agent
XENON
O
SC
A
A
DECKARD
X
X
ADAM
X
RAND
Implementation details. For the planner, we use Qwen2.5-Vil 5---7BB (Bai et al. 2025). The learned dependency graph is initialized with human-written plans for three goals ("craft iron sword x"' "craft a golden sword x." "mine a diamond @ "), providing minimal knowledge; the agent must learn dependencies for over 80% of goal items through experience. We employ CRe only for long-horizon

---

Published as a conference paper at ICLR 2026
1.0
1.0
Table 2:
Robustness to LLM hallucina- tions. The number of correctly learned de- pendencies of items that are descendants of a hallucinated item the initial L.M- predicted dependency graph (out of 12).
DECKARD ADAMI
0.8
0.8
0.4
0.4
0.2
0.2
Agent
Learned descendants of hallucinated items
100
200
100
200
Episade
Episode
XENON
0.33 0
SC
(a) MineRL
(b) Mineflayer
ADAM
0
Figure 5: Robustness against flawed prior knowledge. EGA over 400 episodes in (a) MineRL and (b) Mineflayer. XENON consistently outperforms the baselines.
DECKARD
0
RAND
0
goal planning in MineRL. All hyperparameters are kept consistent across experiments. Further details on hyperparameters and human- human-written written plans are in Appendix [[
Baselines. As no prior work learns dependencies in our exact setting, we adapt four baselines, whose knowledge correction mechanisms are summarized in Table For dependency knowledge, (1) LLM Self-Correction (SC) starts with an LLM
dependency graph and prompts the
LLM revise it upon failures; (2) DECKARD (Nottingham et al., 2023) also relies on an L.LM- predicted graph but with no correction mechanism; (3) ADAM (Yu & Lu 2024) assumes that any goal item requires all previously used resource items, each in sufficient quantity; and (4) RAND, the simplest baseline, uses a static graph similar to DECKARD, Regarding action knowledge, all baselines except for RAND store successful actions. However, only the SC baseline attempts to correct its flawed knowledge upon failures. The SC prompts the LLM to revise both its dependency and action knowledge using previous L.LM predictions and interaction trajectories, as done in many seff-correction methods (Shinn et al.) 2023 (Stechly et al.) (024). See Appendix [B for the prompts of SC and Appendix [. for detailed descriptions of these baselines. To evaluate planning on diverse long-horizon goals, we further compare XENON with recent planning agents that are provided with
oracle dependencies: DEPS Wang et al. (2023)), Jarvis-1 Wang et al. (2023c). Optimus-1
Li et al.
(2024b), and Optimus-2 Li et al. (2025b).
5.2 ROBUST DEPENDENCY LEARNING AGAINST FLAWED PRIOR KNOWLEDDGE
XENON demonstrates robust dependency learning from flawed prior knowledge, consistently outper- forming baselines with an EGA of approximately 0.6 in MineRL and 0.9 in Mineflayer (Figure 5). despite the challenging setting with imperfect controllers. This superior performance is driven by its algorithmic correction mechanism, Revi sssiiinn RevissonByAne onByAnalogy. logy, which corrects flawed dependency knowledge while also accommodating imperfect controllers by gradually scaling required items quantities. The robustness of this algorithmic correction is particularly evident in two key analyses of the learned graph for each agent from the MineRL experiments. First, as shown in Table XENON uniquely robust to LLM hallucinations, learning dependencies for descendant items non-existent, hallucinated items in the initial LLM-predicted graph. Second, XENON outperforms the baselines in learning dependencies for items that are unobtainable by the initial graph, as shown in Table [3
Our results demonstrate the unreliability of relying on LLM corfecoornttion or blindly trusting an LLM's 's flawed knowledge; in practice, SC achieves the same EGA as DECKARD, with both plateauing around 0.4 in both environments.
We observe that controller capacity strongly impacts dependency learning. This is evident in ADAM, whose EGA differs markedly between MineRL ( 0.1), which has a limited controller, and Mineflayer (As 0.6), which has a more competent controller. While ADAM unrealistically assumes a controller can gather large quantities of all resource items before attempting a new item, MineRL's controller STEVE-1 (Lifshitz et al. 2023) cannot execute this demanding strategy, causing ADAM's EGA to fall below even the simplest baseline. RAND. Controller capacity also accounts for XENON's 's lower a EGA in MineRL. For instance, XENON learns none of the dependencies of the Redstone group items, as STEVE-1 cannot execute XENON's strategy for inadmissible items (Section 4.1). In contrast, the
7

---

Published as a conference paper at ICLR 2026
Table 3: Performance on long-horizon task benchmark. Average success rate of each group on the long-horizon task benchmark Li et al. (2024b) in MineRL. Oracle indicates that the true dependency graph is known in advance, Learned indicates that the graph is learned via experience across 400 episodes. For fair comparison across LLMs, we include Optimus- 1t, reproduction of Optimus-1 using Qwen2.5-VL Due to resource limits, results for DEPS, Jarvis- 1, Optimus-1 I, and Optimus-2 cited directly from (Li et al. 2025b). See Appendix K.12 for the success rate each goal.
Method
Dependency
Planner LLM
Overall
Wood
Stone
Iron
Diamond
Gold
Armor
Redstone
DEPS
Codex
0.22
0.77
0.48
0.16
0.01
0.00
0.10
0.000
Jarvis-1
Oracle
GPT-4
0.93
0.89
0.36
0.08
0.07
0.15
0.16
Optimus-1
Orucle
GPT-4V
0.43
0.98
0.92
0,46
0.11
0.08
0.19
0.25
Optimus-2
Oracle
GPT-4V
0.45
0.99
0,93
0.53
0.13
0.09
0.21
0.28
Optimus-11 17
Oracle
Qwen2.5-VL LL
0.34
0.92
0.80
0.22
0.10
0.09
0.17
0.04
XENON
Orucle
Qwen2.5-VL 5-VL-7B
0.79
0.95
0.93
0.83
0.75
0.73
0.61
0.75
XENON
Learned
Qwen2.5-VL
0.54
0.85
0.81
0.46
0.64
0.74
0.28
0.00
more capable Mineflayer controller executes this strategy successfully, allowing XENON to learn
the correct dependencies for of 6 Redstone items. This difference highlights the critical role of controllers for dependency learning, as detailed in our analysis in Appendix K.3
5.3 EFFECTIVE PLANNING TO SOLVE DIVERSE GOALS
As shown in Table 3 XENON significantly outperforms baselines in solving diverse long-horizz goals despite using the lightweight Owen2.5-VL-7B LLM (Bai al., 2025), while the baselines rely on large proprietary models such Codex (Chen et al. 2021). GPT- (OpenAl 2024). and GPT-4V (OpenAI 2023). Remarkably, even with its learned dependency knowledge (Section (.2).
XENON surpasses the baselines with the oracle knowledge on challenging late-game goals, achieving
high SRs for item groups like Gold (0) and Diamond (0.64).
XENON's superiority stems from two key factors. First, its FAM provides systematic, fine-grained action correction for each goal. Second, it reduces reliance on the LLM for planning in two ways: shortens prompts and outputs by requiring it to predict one action per subgoal item, and it bypasses the LLM entirely by reusing successful actions from FAM. In contrast, the baselines lack a systematic, fine-grained action correction mechanism and instead make L.LMs generate long plans from lengthy prompts-a strategy known to be ineffective for I.LMs (Wu et al.) 2024 Li et al,, 2024a). This challenge is exemplified by Optimus-1 1 Despite using knowledge graph for planning like XENON, its long-context generation strategy causes LLM to predict incorrect actions or omit items explicitly provided in its prompt, as detailed Appendix K.5
We find that accurate knowledge is critical for long-horizon planning, as its absence can make even capable agent ineffective. The Redstone group from Table (abbli/providess an example: while XENON* with oracle knowledge succeeds (0.75 SR), XENON with learned knowledge fails entirely (0.00 SR), because it failed to learn the dependencies for Redstone goals due to the controller's limited capacity in MineRL. (Section 5.2). This finding is further supported by our comprehensive ablation study, which confirms that accurate dependency knowledge is most critical for success across all goals (See Table 17 in Appendix K.7
5.4 ROBUST DEPENDENCY LEARNING AGAINST KNOWLEDGE CONFLICTS
To isolate dependency learning from controller capacity, we shift to the MC-TextWorld environment with a perfect controller. In this setting, we test each agent's 's robustness to conflicts with its prior knowledge (derived from the LLM'' initial predictions and human-writter plans) by introducing arbitrary perturbations to the ground-truth required items and actions. These perturbations are applied with an intensity level; a higher intensity affects a greater number of items, as shown in Table 4 This intensity is denoted by tuple (r, a) for required items and actions, respectively. (0, 0) represents the vanilla setting with no perturbations. See Figure 21 for the detailed perturbation process.
Table 4: Effect of ground-truft -rrth pertur- bations prior knowledge.
Perturbation Goal items obtainable Intensity
via prior knowledge
(no perturbation) (12 %)
11 (31 %)
9 (44 %)
8

---

Published as a conference paper at ICLR 2026
XENON
SC
ADAM
DECKARD
RAND
0.8
0.6
EGA
0.6
0.6
0.4
0.4
0.4
0.2
0.2
0.2
(0. 0)
(1. 0)
(2. 0) 0)
(0.0) (0, () (0,
(0. 3)
(0. 0)
(1, 1) (2, 2)
3)
Perturbed (required items, action)
Perturbed (required items, action)
Perturbed (required items, action)
(a) Perturbed True Required Items
(b) Perturbed True Actions
(c) Perturbed Both Rules
Figure 6: Robustness against knowledge conflicts. EGA after 3,000 environment steps in MC- TextWorld under different perturbations of the ground-truth rules. The plots show performance with increasing intensities of perturbation applied to: (a) requirements only, (b) actions only, and (c) both (see Table 4)
Figure 6 shows XENON's robustness to knowledge conflicts, as it maintains a near-perfect EGA (==0.97). In contrast, the performance of all baselines degrades as perturbation intensity increases across all three perturbation scenarios (required items, actions, or both). We find that prompting an LLM to self-correct ineffective when the ground truth conflicts with its parametric knowledge: SC shows no significant advantage over DECKARD, which lacks a correction mechanism. ADAM is vulnerable to action perturbations; its strategy of gathering all resource items before attempting a new item fails when the valid actions for those resources are perturbed, effectively halting its learning.
5.5 ABLATION STUDIES ON KNOWLEDGE CORRECTION MECHANISMS
As shown in Table to analyze XENON's knowledge correction mechanisms for de- pendencies and actions, we conduct abla- tion studies in Me-TextWorld. While de- pendency correction generally more im- portant for overall performance, action cor- rection becomes vital under action pertur- bations. In contrast, LLM self-correction is ineffective for complex scenarios: it of- fers minimal gains for dependency correc- tion even in the vanilla setting and fails entirely for perturbed actions. Its effective- ness is limited to simpler scenarios, such as action correction in the vanilla setting. These results demonstrate that our algorith- mie knowledge correction approach enables robust learning from experience, overcoming the limita- tions of both LLM self-correction and flawed initial knowledge.
Table 5: Ablation study of knowledge correction mech- anisms. Of XENON; A: LLM self-correction: X: No correction. All entries denote the EGA after 3,000 envi- ronment steps. Columns denote the perturbation setting ar, For LLM self-correction, we use the same prompt the SC baseline (see Appendix Bp.
Dependency Correction
Action Correction
(0,0)
(3,0)
(0, 3)
(3, 3)
O
O
0.97
0.97
0.97
0.97
O
A
0.93
0.93
0.12
0.12
O
X
0,84
0.84
0.12
0.12
A
O
0.57
0,30
0.57
0.29
X
O
0.53
0.13
0.53
0.13
x
X
0.46
0.13
0.19
0.11
5.6 ABLATION STUDIES ON HYPERPARAMETER
To validate XENON's stability to its hyperparameters, we conduct comprehensive ablation studies in both MC-TextWorld and MineRL. In these studies, we vary one hyperparameter at a time while keeping the others fixed to their default values (co 3. a4 8, a, 2, zo 2).
Our results (Figure 7 Figure g show that although XENON is generally stable across hyperpa- rameters, an effective learning strategy should account for controller capacity when the controller is imperfect. In MC-TextWorld (Figure 7 XENON maintains near-perfect EGA across a wide range of all tested hyperparameters, confirming its stability when perfect controller is used. In MineRL (Figure B). with an imperfect controller, the results demonstrate two findings. First, while influenced by hyperparameters, XENON still demonstrates robust performance, showing EGA after
9

---

Published as a conference paper at ICLR 2026
1.-
1.0
1.04
1.0
0.-
0.0
0.8
0.5
04-
0.4
6.4
02
0.2
0.2
0.2
1000 7003
2000
2000
3000
Envronment
Environment stop
Ervirommen stop
stop
(a)
(b) Oks
(c) Ots
(d) 200
Figure 7: Hyperparameter ablation study in MC-TextWorld. EGA over 3,000 environment steps under different hyperparameters. The plots show EGA when varying: (a) co (revision count threshold for inadmissible items), (b) aç (required items quantities for inadmissible items), (c) a, (required items quantities for less-tried items), and (d) zu (invalid action threshold). Each study varies one
hyperparameter while keeping the others fixed to their default values (co = 3, 0g 8, a2 2,
300 2).
10
1.0
1.0
100
18
0.4
0.4-
0.4-
0.4
300
Epluode
Epiodd
Episode
Sploode
(a) Co
(b) cas
(c) Cka
(d) 200
Figure 8: Hyperparameter ablation study MineRL. EGA over 400 episodes under different hyperparameters. The plots show EGA when varying: (a) co (revision count threshold for inadmissible items), (b) ag (required items quantities for inadmissible items), (c) as (required items quantities for less-tried items), and (d) zo (invalid action threshold). Each study varies one hyperparameter while keeping the others fixed to their default values (cg = 3, 0z = 8, a. = 2, xo 2).
400 episodes for all tested values remains near or above 0.5, outperforming baselines that plateau around below 0.4 (Figure Sap. Second, controller capacity should be considered when designing dependency and action learning strategies. For example, the ablation on (Figure &c) shows that while gathering sufficient quantity of items necessary (a, = 1), overburdening the controller with excessive items (a, 4) also degrades performance. Similarly, the ablation shows the need to balance tolerating controller failures against wasting time on invalid actions.
(Figure 8d)
We provide additional ablations in the Appendix on dependency and action learning-whin initializ- ing the dependency graph from an external source mismatched to the environment (Figure 22)) when scaling to more goals/actions (Figure 24). and when using smaller 4B planner LLM (Figure 26 as
well as an ablation action selection methods for subgoal construction (Figure 25).
6 CONCLUSION
We address the challenge of robust planning via experience-baat algorithmic knowledge correction. With XENON, we show that directly revising external knowledge through experience enables an LLM-based agent to overcome flawed priors and sparse feedback, surpassing the limits of LLM self-correction. Experiments across diverse Minecraft benchmarks demonstrate that this approach not only strengthens knowledge acquisition and long-horiza planning, but also enables an agent with a lightweight 7B open- weight LLM to outperform prior methods that rely much larger proprietary models. Our work delivers key lesson for building robust LLM-based embodied agents: LLM priors should be treated with skepticism and continuously managed and corrected algorithmically.
Limitations. Despite its contributions, XENON faces limitation. XENON's performance is influenced by the underlying controller; in MineRL, STEVE-1 (Lifshitz et al. 2023) controller struggles with spatial exploration tasks, making a performance gap compared to competent controllers like Mineflayer. Future work could involve jointly training the planner and controller, potentially using hierarchical reinforcement learning.
10

---

Published as a conference paper at ICLR 2026
ACKNOWLEDGMENTS
This work was supported by the Institute Information & Communications Technology Planning Evaluation (IITP) and HTT--ITRC (Information Technology Research Center) grant funded by the Korea government (MSIT) (No. RS-2019-11191906, Artificial Intelligence Graduate School Program (POSTECH); ITTP-2026-RS 00026--R--22220004776666
33-2024-005002288 Global Al Frontier Lab), by grant from the Korea Institute for Advancement of Technology (KIAT), funded by the Ministry of Trade, Industry and Energy (MOTIE), Republic of Korea
and by Scoul R&BD Program (SP240008) through the Seoul Business Agency (SBA) funded by The Seoul Metropolitan Government.
REFERENCES
Shuai Bai, Keqin Chen, Xuejing Liu, Jialin Wang, Wenbin Ge, Sibo Song, Kai Dang, Peng Wang, Shijie Wang, Jun Tang, Humen Zhong, Yuanzhi Zhu, Mingkun Yang, Zhaohai Li. Jianqiang Wan. Pengfei Wang, Wei Ding. Zheren Fu, Yiheng Xu, Jiabo Ye, Xi Zhang, Tianbao Xic, Zesen Cheng, Hang Zhang, Zhibo Yang. Haiyang Xu, and Junyang Lin. Qwen2.5-vl technical report. arXiv preprint ar 2502 13923, 2025.
Bowen Baker, lgge Akkaya, Peter Zhokhov, Joost Huizinga, Jie Tang, Adrien Ecoffet, Brandon Houghton, Raul Sampedro, and Jeff Clune. Video pretraining (vpt): Learning to act by watching unlabeled online videos, 2022. URL hRtthttss////att http://aaxxiv....aaaa/a www.ab/........ 12755
Peter Belcak, Greg Heinrich, Shizhe Diao, Yonggan Fu, Xin Dong, Saurav Muralidharan, Yingyan Ce- line Lin, and Pavlo Molchanov. Small language models are the future of agentic ai, 2025. URL https: //axxv ottp:////g.......///// 02153
Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray, Nick Ryder, Mikhail Pavlov, Alethea Power, Lukasz Kaiser, Mohammad Bavarian, Clemens Winter, Philippe Tillet, Felipe Petroski Such, Dave Cummings, Matthias Plappert, Fotios Chantzis, Elizabeth Barnes, Ariel Herbert-Voss. William Hebgen Guss, Alex Nichol, Alex Paino, Nikolas Tezak, Jie Tang, Igor Babuschkin, Suchir Balaji, Shantanu Jain, William Saunders, Christopher Hesse, Andrew N. Carr, Jan Leike, Josh Achiam, Vedant Misra, Evan Morikawa, Alec Radford, Matthew Knight, Miles Brundage, Mira Murati, Katie Mayer, Peter Welinder, Bob McGrew, Dario Amodei, Sam McCandlish, Ilya Sutskever, and Wojeiech Zaremba. Evaluating large language models trained on code. 2021.
Minghao Chen, Yihang Li, Yanting Yang, Shiyu Yu, Binbin Lin, and Xiaofci Hc. Automanual: Constructing instruction manuals by 11m agents via interactive environmental learning, 2024.
Mare-Alexandre Côté, Ákos Kádár, Xingdi Yuan, Ben Kybartas, Tavian Barnes, Emery Fine, James Moore, Ruo Yu Tao, Matthew Hausknecht, Layla El Asri, Mahmoud Adada, Wendy Tay, and Adam Trischler. Textworld: A learning environment for text-based games. CoRR, abs/1806.1 10531, 2018.
Kevin Du. Vésteinn Snæbbarrnrson,, Niklas Stochr, Jennifer White, Aaron Schein, and Ryan Cot- terell. Context versus prior knowledge in language models. In Lun-Wei Ku, Andre Martins, and Vivek Srikumar (eds.), Proceedings of the 62nd Anmual Meeting of the Association for Compu- fational Linguistics (Volume I: Long Papers), pp. 13211-13235. Bangkok, Thailand, August 2024. Association for Computational Linguistics. doi: 10. 1/2286655//12222aaaoaaaoooo 714. URL
https::/acclantholooy.
1.4.4..c---- acl. long.
Linxi Fan, Guanzhi Wang, Yunfan Jiang, Ajay Mandlekar, Yuncong Yang. Haoyi Zhu, Andrew Tang, De-An Huang, Yuke Zhu, and Anima Anandkumar, Minedojo: Building open-ended embodied agents with internet-scale knowledge. In Tiit Conference Neural Information Processing Systems Datasets and Benchmarks Track, 2022, URL htthttts:// http:///eeeeeeiieeee /R//attss:://peeeeeeee net fortffrrm?
dd=arcoo_88888 T8X
11

---

Published as a conference paper at ICLR 2026
Yicheng Feng, Yuxuan Wang. Jiazheng Liu, Sipeng Zheng, and Zongqing Lu. LLaMA-rider: Spurring large language models to explore the open world. In Kevin Duh, Helena Gomez, and Steven Bethard (eds.), Findings of the Association for Computational Linguistics: NAACL 2024, pp. 4705 -724, Mexico City, Mexico, June 2024. Association for Computational Linguis- tics. doi: 10.18653/1/2024. 22n.666351222244nnnnnssn-aaa 2992. URL htt.:ppss/accc.ancooooggggg.././
Findings - maa.c..292//
Zhibin Gou, Zhihong Shao. Yeyun Gong, Yelong Shen, Yujiu Yang, Nan Duan, and Weizhu Chen. Critic: Large language models can self-correct with tool-interactive critiquing, 2024. URL
attps:///aris> org/ als / 2305. 11738
William H. Guss, Brandon Houghton, Nicholay Topin, Phillip Wang, Cayden Codel, Manuela Veloso, and Ruslan Salakhutdinov. Minerl: large-scale dataset of minecraft demonstrations, 2019, URL
org/ /ts/aa//////ooooooa//./a//aaaara abs/ 1907. 13440
Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song, and Denny Zhou. Large language models cannot self-correct reasoning yet, 2024. (tthtt
//axxiv. org/ abaaabaa/33100 01798
Jiajian Li, Qi Wang, Yunbo Wang, Xin Jin, Yang Li, Wenjun Zeng, and Xiaokang Yang. Open-world reinforcement learning over long short-term imagination. In ICLR, 2025a.
Tianle Li, Ge Zhang, Quy Duc Do, Xiang Yue, and Wenhu Chen. Long-context Ilms struggle with long in-context learning, 2024a.
Zaijing Li, Yuquan Xie, Rui Shao, Gongwei Chen, Dongmei Jiang, and Liqiang Nie. Optimus-1, Hybrid multimodal memory empowered agents excel in long-horizon tasks. Advances in neural information processing systems, 37:49881 1-49933, 2024b.
Zaijing Li, Yuquan Xie, Rui Shao, Gongwei Chen, Dongmei Jiang, and Liqiang Nie. Optimus-2: Multimodal minecraft agent with goal- iibservvtiionaccionn conditioned policy. In 2025 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR). JEEE, 2025b.
Shalev Lifshitz, Keiran Paster, Harris Chan, Jimmy Ba, and Sheila Mcllraith. Steve-1: A generative model for text-to-behavior in minecraft. 2023.
Zichuan Lin, Junyou Li, Jianing Shi, Deheng Ye, Qiang Fu, and Wei Yang. Juewu-me:
Playing minecraft with sample-efficient hierarchical reinforcement learning. arXiv preprint 1rXiv:21 2021.
Nelson Liu, Kevin Lin, John Hewitt, Ashwin Paranjape, Michele Bevilacqua, Fabio Petroni, and Percy Liang. Lost in the middle: How language models use long contexts. Transactions of the Association for Computational Linguistics, 12:157-173, 2024. doi: 2a11662/acLa_000333 URL
https::/acclanee
logy www.org/2200 t
Shunyu Liu, Yaoru Li, Kongcheng Zhang, Zhenyu Cui, Wenkai Fang, Yuxuan Zheng, Tongya Zheng, and Mingli Song. Odyssey: Empowering minecraft agents with open-world skills. In International Joint Conference on Artificial Intelligence, 2025.
Hangyu Mao, Chao Wang, Xiaotian Hao, Yihuan Mao, Yiming Lu, Chengjie Wu, Jianye Hao, Dong Li, and Pingzhong Tang. Seihai: A sample-efficient hierarchical ai for the minerl competition. In Distributed Artificial Intelligence: Third International Conference, DAI 2021, Shanghai, China, December 17-18, 2021, Proceedings 3, pp. 38-51. Springer, 2022.
Microsoft, Abdelrahman Abouelenin, Atabak Ashfaq. Adam Atkinson, Hany Awadalla, Nguyen Bach, Jianmin Bao, Alon Benhaim, Martin Cai, Vishrav Chaudhary, Congcong Chen, Dong Chen, Dongdong Chen, Junkun Chen, Weizhu Chen, Yen-Chun Chen, Yi ling Chen, Qi Dai, Xiyang Dai, Ruchao Fan, Mei Gao, Min Gao, Amit Garg, Abhishek Goswami, Junheng Hao, Amr Hendy, Yuxuan Hu, Xin Jin, Mahmoud Khademi, Dongwoo Kim, Young Jin Kim, Gina Lee, Jinyu Li, Yunsheng Li, Chen Liang, Xihui Lin, Zeqi Lin, Mengchen Liu, Yang Liu, Gilsinia Lopez, Chong Luo, Piyush Madan, Vadim Mazalov, Arindam Mitra, Ali Mousavi, Anh Nguyen, Jing Pan, Daniel Perez- Becker, Jacob Platin, Thomas Portet, Kai Qiu, Bo Ren. Liliang Ren, Sambuddha Roy, Ning Shang, Yelong Shen, Saksham Singhal, Subhojit Som, Xia Song, Tetyana Sych, Praneetha
12

---

Published as a conference paper at ICLR 2026
Vaddamanu, Shuohang Wang, Yiming Wang, Zhenghao Wang, Haibin Wu, Haoran Xu, Weijian Xu, Yifan Yang, Ziyi Yang, Donghan Yu, Ishmam Zabir, Jianwen Zhang, Li Lyna Zhang, Yunan Zhang, and Xiren Zhou. Phi-4-mini technical report: Compact yet powerful multimodal language models via mixture-of-lood loraa,,, 2025. URL
250... 01743)
Kolby Nottingham, Prithviraj Ammanabrolu, Alane Suhr, Yejin Choi, Hannanch Hajishirzi, Sameer Singh, and Roy Fox. Do embodied agents dream of pixelated sheep? embodied decision making using language guided world modelling. In Proceedings of the 40th International Conference on Machine Learning, ICMI.22. Jog.. 2023.
OpenAL. Gpt-4w(ision) system card, 2023.
URL https://openaa..cmm/mm /nnd//xxxiccom////
gpt- -ott-4v-yystem-caa//
OpenAl. Gpt-4 technical report, 2024. URL ULL.ttts///arxxrrrrr/////2200000
PrismarineJS. Prismarineij/miinellayy, 2023. URL httttpp:://ittuu..cm//
mineflayer https//giiabb.com//Pismniieeee/p
Yiran Qin, Enshen Zhou, Qichang Liu, Zhenfei Yin, Lu Sheng, Ruimao Zhang, Yu Qiao, and Jing Shao. Mp5: A multi-modal open-ended embodied system in minecraft via active perception. In 2024 IEEE/CVF Conference Computer Vision and Pattern Recognition (CVPR), pp. 16307- 16316. IEEE, 2024.
Nils Reimers and Iryna Gurevych. Sentence-bert: Sentence embeddings using siamese bert-networks. In Proceedings of the 2019 Conference on Empirical Methods in Natural Language Processing. Association for Computational Linguistics, 11 2019. htth:tt:: http:://aaxvvviio owg/ abs/ 1908
10084
Noah Shinn, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. Reflexion: Language agents with verbal reinforcement learning, 2023.
Kaya Stechly, Karthik Valmeekam, and Subbarao Kambhampati. On the self-verification limitations of large language models on reasoning and planning tasks, 2024. URL URL httph:tt///// /ttp:/://axvvvvvo
abs/ 2402. 081 15
Andrew Szot, Alex Clegg, Eric Undersander, Erik Wijmans, Yili Zhao, John Turner, Noah Maestre, Mustafa Mukadam, Devendra Chaplot, Oleksandr Maksymets, Aaron Gokaslan, Vladimir Vondrus, Sameer Dharur, Franziska Meier, Wojciech Galuba, Angll Chang, Zsolt Kira, Vladlen Koltun, Jitendra Malik, Manolis Savva, and Dhruv Batra. Habitat 2.0: Training home assistants to rearrange their habitat. In Advances in Neural Information Processing Systems (NeurIPS), 2021.
Gladys Tyen, Hassan Mansoor, Victor Carbune, Peter Chen, and Tony Mak. LLMs cannot find reasoning errors, but can correct them given the error location. In Lun-Wei Ku, Andre Martins, and Vivek Srikumar (eds.). Findings of the Association for Computational Linguistics: ACI. 2024, pp. 13998. Bangkok, Thailand, August 2024. Association for Computational Linguis- tics. doi: 10. 01188655/1122222 hwt.///.....insaaaae. acl.nns--al.826... URL https: http//aaaanntttty..oooo Findings-acl. 826/
/ org./o000.or//299
Guanzhi Wang, Yuqi Xie, Yunfan Jiang, Ajay Mandlekar, Chaowei Xiao, Yuke Zhu, Linxi Fan, and Anima Anandkumar. Voyager: An open-ended embodied agent with large language models. arXiv preprint arXiv: 2xi1-2305..1629) 2023a.
Zihao Wang, Shaofei Cai, Guanzhou Chen, Anji Liu, Xiaojian (Shawn) Ma, and Yitao Liang. Describe, explain, plan and select: Interactive planning with llms enables oorldworld multi-task agents. Advances in Neural Information Processing Systems, 36:34153-34189, 2023b.
Zihao Wang, Shaofei Cai, Anji Liu, Yonggang Jin, Jinbing Hou, Bowei Zhang, Haowei Lin, Zhaofeng He, Zilong Zheng, Yaodong Yang, Xiaojian Ma, and Yitao Liang. Jarvis-1: Open-worke multi-task agents with memory- aegmorea multimodal language models. arXiv preprint arXiv: 23/ 1.05977, 2023c.
Yuhao Wu, Ming Shan Hee, Zhiqing Hu, and Roy Ka- Wei Lee. Longgenbench: Benchmarking Beng long- form generation in long context 1lms, 2024. URL Btt.hhccc.s//aarr.rrr//////2...0
13

---

Published as a conference paper at ICLR 2026
Ling Yang, Zhaochen Yu, Tianjun Zhang, Minkai Xu, Joseph E Gonzalez, Bin Cui, and Shuicheng Yan. Supercorrect: Supervising and correcting language models with error-driven insights. In International Conference Learning Representations, 2025.
Youngsik Yoon, Gangbok Lee, Sungsoo Ahn, and Jungseul Ok. Breadth-first exploration adaptive grid for reinforcement learning. In Forty-first International Conference on Machine Learning, 2024.
Shu Yu and Chaochao Lu. Adam: An embodied causal agent in open- ppen-world environments. arXiv preprint arXiv:2410.22194 2024.
Haoqi Yuan, Chi Zhang, Hongcheng Wang. Feiyang Xie, Penglin Cai, Hao Dong, and Zongqing Lu. Plan4MC: Skill reinforcement learning and planning for open-world Minecraft tasks. arXiv preprint ar 2rX1v:2303.16663, 2023.
Yunxiang Zhang, Muhammad Khalifa, Lajanugen Logeswaran, Jackyeom Kim, Moontae Lee. Honglak Lee, and Lu Wang. Small language models need strong verifiers to self-correct rea- soning. Lun- Wei Ku, Andre Martins, and Vivek Srikumar (eds.), Findings of the Associa- fion for Computational Linguistics: ACL 2024, pp. 15637-15653, Bangkok, Thailand, August findings-acl.924, 2024. Association for Computational Linguistics. doi: 10. 18653/81/12224 1 https://ace conttoooogy org. 2024. findings-aeeee acl. 9247
URL
Andrew Zhao, Daniel Huang, Quentin Xu, Matthieu Lin, Yong-Jin Liu, and Gao Huang. Expel: Lim agents are experiential learners. In Michael J. Wooldridge, Jennifer G. Dy, and Sriraam Natarajan (eds.), Thirty-Eighth AAAI Conference on Artificial Intelligence, AAAI 2024, Thirty- Sixth Conference on Innovative Applications of Artificial Intelligence, IAAI 2024, Fourteenth Symposium on Educational Advances in Artificial Intelligence, EAAI 2024, February 20-27, 2024, Vancouver, Canada, pp. 19632-19642) AAAI Press, 2024. doi: 100.1609/aaai.vv3811...222 https://ojs aaw./ aaai..
URL
org/ index.iix.. Lntdd//..aa//.aa//aaaaa////////2
Zhonghan Zhao, Wenhao Chai, Xuan Wang, Li Boyi, Shengyu Hao, Shidong Cao, Tian Ye, Jenq- Neng Hwang, and Gaoang Wang. See and think: Embodied agent in virtual environment. arXiv preprint arXiv:2311.
2023.
Xinyue Zheng, Haowei Lin, Kaichen He, Zihao Wang, Zilong Zheng, and Yitao Liang. Meu: An evaluation framework for open-ended game agents, 2025. URL httpp:://axxi...rrrr..rtr abs/ 2310. 08367
Xizhou Zhu, Yuntao Chen, Hao Tian, Chenxin Tao, Weijie Su, Chenyu Yang, Gao Huang, Bin Li, Lewei Lu, Xiaogang Wang, Yu Qiao, Zhaoxiang Zhang, and Jifeng Dai. Ghost the minecraft: Generally capable agents for open-world environments via large language models with text-based knowledge and memory. arXiv preprint arXiv:2305. 171444 2023.
14

---

Published as a conference paper at ICLR 2026
This appendix is organized as follows:
Appendix
Experiments in a domain other than Minecraft (Microsoft TextWorld Cooking).
Appendix
Prompts and qualitative results of LLM self-correction in our experiments.
Appendix
Detailed procedure for experienced requirement set determination and depen-
dency graph updates, discussed in Section 3
Appendix
Detailed pseudocode and the prompt for ADG in Section
Appendix in Section 4.2
Detailed pseudocode and the prompt for step-by-step planning using FAM
Appendix
Detailed descriptions and the prompt for CRe in Section 4.3
Appendix
Detailed descriptions of implementation, human-written plans, and hyperpa-
rameters.
Appendix J Detailed descriptions of the baselines and experimental environments in Sec- tion
Appendix
Analysis of experimental results and additional experimental results.
Appendix
Descriptions about LLM usage.
15

---

Published as a conference paper at ICLR 2026
Table Success rates in the TextWorld Cooking environment, comparing XENON against the SC (LLM self-correction) and DECKARD baselines from Section 5.1 We report the mean + standard deviation over independent runs, where each rum consists of 100 episodes.
DECKARD
SC
XENON
Success Rate 0.09 + 0.02
0.75 + 0.04 1.00 0.00
A ADDITIONAL EXPERIMENTS IN ANOTHER DOMAIN
To assess generalization beyond Minecraft, we evaluate XENON on the Microsoft TextWorld Cooking environment (Côté et al. 2018). a text-based household task planning benchmark. We demonstrate XENON can correct LLM's flawed knowledge of preconditions (e.g., required tools) and valid actions for plans using ADG and FAM in this domain as well. We note that XENON is applied with minimal modification: FAM is applied without modification, while ADG is adapted from its original design, which supports multiple incoming edges (preconditions) for a node, to one that allows only a single incoming edge, as this domain requires only single precondition per node.
A.1 EXPERIMENT SETUP
Environment Rules. The goal is to prepare and eat a meal by reading a cookbook, which provides a plan as a list of (action, ingredient) pairs, e.g., ("fry", "pepper"). We note that an agent cannot succeed by naively following this plan. This is because the agent must solve two key challenges: (1) it must discover the valid tool required for each cookbook action, and (2) it must discover the valid, executable action for each cookbook action, as some cookbook actions are not directly accepted by the environment (i.c., not in its action space).
Specifically, to succeed a cookbook's (action, ingredient) pair, an agent must make subgoal, formatted as (executable tcol must be valid for the cookbook action. For example. the cookbook's 's ("fry", "pepper") pair requires the agent to make a subgoal (cook, "pepper", stove). The available executable action space consists of { ""chop", "close", "cook", "dice", "drop", "eat", "examine", "slice", "prepare") ), and the available tools are "knife", "oven", "stove", "fridge", "table", "counter") ).
con, ingredient, tool), where the executable act inn and
Baselines and Evaluation. All agents use an LLM (Qwen2.5-VLL -LL--B to make subgoals. The tool for each cookbook action is predicted by the LLM from the available tools before an episode begins. At each timestep during the episode, given a cookbook action, the LLM predicts an executabl action from the executable action space, constructing subgoal from this predicted executable action, the input ingredient, and the predicted tool.
To isolate the challenge of planning knowledge correction, we assume a competent controller gathers all ingredients and tools; thus, an agent starts each episode with all necessary ingredients and tools. An episode (max 50 timesteps) is successful if the agent completes the plan.
A.2 RESULTS
Table that XENON achieves perfect success rate (1.00 + 0.00), significantly outperforming both SC (0.75 + 0.04) and DECKARD (0.09 + 0.02). These results demonstrate that XENON's core mechanisms (ADG and FAM) are generalizable, effectively correcting flawed planning knowledge in a domain that requires the agent to discover valid symbolic actions and preconditions. Notably, the SC bascline fails to achieve high performance, even in the TextWorld Cooking environment which is simpler than Minecraft. This reinforces our claim that relying on LLM self-correction is less reliable than XENON's experience-baceeee bassed algorithmic knowledge correction.
16

---

Published as a conference paper at ICLR 2026
B PROMPTS AND QUALITATIVE RESULTS OF LLM SELF-CORRECTION
B.1 DEPENDENCY CORRECTION
Figure 9
shows the prompt used for dependency correction.
You are professional game analyst. For given <item_name>> you need to get the item. If you make <required_items> well, will give you 1 $.
make crequired_items
I will give you recent transitiens. Recent failed trajectories given [Failed examplel
<item_name>: (item_name)
retemss>>iitt: (original_predictionn <inventory>: (inventory)
<plan>: (failed
subgoal) [
11
<success>: false
12
I will give you learned items similar to <itom_name>, and their validated required items, just for reference.
K similar experienced items and their requirements are given [Success Example]
15
16 <item_name>: (experienced_itee item) trequired_items> (experienced_regs eequeerreueeeieeeeeeeeeeee rements)
19
Make new predicted requirement set
20
YYour turn]
21
Here is <item_name>,
MUST output <required_itens to obtain the item in JSON format. Remember izequired_items MUST be in JSON format.
23
<item name>: sitem_name>: (item_name) requireddiitmm>>
24
Figure 9: Prompt used for LLM self-correction about dependencies.
We provide some examples of actual prompts and LLM outputs in Figure 10 Figure 11
B.2 ACTION CORRECTION
Figure 12 the prompt used self-reflection for failed actions.
We provide examples of actual prompts and LLM outputs in Figure 13
Figure 14
17

---

Published as a conference paper at ICLR 2026
You ace a professional game analyst. For given <item_name>, you need to make crequired_ to get the item. II make crequized_iteme well, will give you 1 8,
will you recent transitions.
[Failed example]
<item_name>: iron_nugget
<laventozy>: ('erafting_table" ("iron_ore" 1, rerafting_table'
shypothes1zed seccheesszedd__eeee
'wooden_sword"; pickeen_pcckaee 1, "Lorhh's 4, furnace': 1, 'stone_pickaxe': 1, 'iron_axe"; 1, izon_shovel' i, "stick': firen_ pickaxe': 'diamond' 'iron_ingat's 'iron_ore'; 2, 'gold 1, fcaalf; 1) <planz: dig down and mine iron_nagget
12
will give you learned items similar to <item_names, and their validated sequiced items, just for reference.
[Success Example]
<item_name>:
tron_ingot 16
crequired_items>
18
('recipe': furnace': 1, "izen_ore': 1, 'coals': 1)]
[Success Example]
<item_name>:
21
ircn_pickaxa
<required_itema>
23
(' ('recipe': (' 2, 'iron_ingot'; 3, terleting_table' 13)
[Success Example)
25
<item_name>:
26
iren_shovell
crequired_itenss
(' 'rrecppe: : ('stick'; 2, "iron_ingat' 1, Ccrafting_table"" 1]]
30
[Your tuza]
<item_name>, you MUST output crequired
Remember sengiiirdd_ttmss MUST he in JSCN format.
32
<item_name>>
tron_nugget
required_itemas
36
: LLM output: l'recipe': (? iren_oze' 1, "cxafting_table': 13)
Figure 10: Example of dependency self-correction for iron nugget.
18

---

Published as a conference paper at ICLR 2026
You ace a professional game analyst. For given <item_name>, you need to make crequired to get the item. II make crequized_iteme> well, will give you 1 8,
will you recent transitions.
[Failed example]
<item_name>: charcoal
("oak_ l'oak_log's 8)
<laventozya: ('diet'; 1, ' : 2, 'erafting_table's 'wooden_hoe's 'wooden_ pickaxe'
1, 'zorch': 4, 'stone_axe's 1, 'Surnace': 1, picke__ickexe" 1, "stick': "iren_ pickaxe': 'diamond's 'iron_ingat's 'iron_ore's : 2, fcoal's
caction>; craft charcoal
12
will give you learned items similar to <item_names, and their validated sequized items, just for reference.
[Success Example]
<item_name>:
16
coals
srequired
18
(' r'eeippe:: : pixoesee__iccaxe': 1)]
[Success Example]
<item_name>;
21
furnace
crequired_itent
23
(' l'recipe': cosblesstoae 8, tablet 11F
[Success Example]
25
<item_name>:
26
diamond
crequired_itenn Litems>:
(' ('recipe': : (" ('iron_pickaxe's 1]]
30
[Your tuza]
<item_name>, you MUST output crequired ittems>> achieve charcoal in format. Remember croquired_iteno) MUST he in JSCN format.
32
<item_name>:
charcoa
crequired_ ittmm=>>_ttet
36
$ LLM output: ( ('recipe': ( ("osk_log": B:)
Figure 11: Example of dependency self-correction for charcoal.
19

---

Published as a conference paper at ICLR 2026
LLM self-reflection to analyze failure reasons You professional game analyst. For a given <item_nt <item_name> _ame>> and <inventery>, you need to analyze why <plan> failed to get the item.
I will give you examples of analysis as follow.
[Kxample]
<item_name>: wooden_pickaxe
<inventory>: ('stick': 4, 'planks': 4, 'erafting_table'' 1) <plan>: smelt gooden_piccknn <failure analysis>
11
("analysis:: "You failed because you cannot smelt cooden_pickenee You should craft it instead.")
[Example]
<item_name>: stone_pickaxe
15
<inventory>: ('stick': 4, 'planks': 4, 'crafting_tablee" 1}
16
<plan>: craft stons_pickaxe
[tailure_anallsiss
("analysis"; "You failed secause you not have enough cobblestones.
20
[Your turn]
21
Here is <item_name>, <inventory> and <plan>, you MUST output <failure_ analysis> concisely in JSON format.
23 name?: (item (item_name) name)
24
<inventory>: (inventory)
25 <plan>: (plan) <tailure_analysis>
27
28
Then, using the self-reflection results, LiM self-correct its actions. For an item name, you need to make a plan, by selecting one among provided ded options. will give you examples which plans needed to achieve item, just for reference. [Example]
29
31
<item name> (similar_item) <task planning>
35
(sucoessful_plaa
36
Here scme analyses previcus failed plans for this item. [Analysis]
39
iitem_namee' litem), 'inventory': (inventory), 'plan': (plan)', tailure_analysis': (iself-reflection)
[Your turn]
Here is <item name>, you select one from below <options>, make task planning>.
43 you MUST select one from below <eptions>. DO NOT MAKE A PLAN NOT IN options>.
45
coptions>:
46
1: ("task": "dig down and mine (item)", "goal": [(item), (quantity)l
47
2: ("task": "craft (item)", "goal": [fitem), (quantityll]
3: ("task": "smelt (item)", "item": [[item), [quantity]]
50
<item name>
51 (item)
<task planning>
Figure 12: Prompts used for LLM self-correction about actions.
20

---

Published as a conference paper at ICLR 2026
item name, need plan, by eatingg among ded opt
I will give you examples of whica plans are needed to achleve an item, juat for reference.
[Examole]
<item name?
ircn_ingot
<task planning>
(*taak"; *smelt iron__ngot", "goal"; (Miron_ingot",
[Example]
<item name>
ircr_pickaxe
<task planning>
("task*: *craft tron_piokaxe", "goal"; ("iron_plokaxe", 1])
16
[Example]
<item names
ires_shovel
19
stask planning>
("taak"; *craft tron_ahovai", "goal"; ("iron_shovel",
21
are analyses on previous failed plans this
23
[Amslysis]
24
(' ('item_namee: 'iron_nugget',
25
'inventory'; ('crafting_table" 1, 'vooden_sword"
'wcoden_pickaxe" 1, 'torch': 4, furnace': 1, 'szone_pickoxe': 1, "iron_axa": 1, "iron_shovall i, 'stick': 2, "iren_. pickaxe': 'diamond' 'iron_ingot's 'iron_ore's "gold_ore''s 1, Keoal "plan'; ; 'dig down and mine izon_auggel', meilure_enaalsit
26
failed because you for iron nuggets.')
any
diamond
[Yeur turn]
Hare is <itam name?, you MUST select one from bellww ow coptions>, so make <task plannings. coptions>,
MAKE PLAM NOT soptionss,
32
coptions>
34 1. (*task*: "dig down and mine iron ttan__ugges", "goal": ["iron_nugged 1]]
35 2. ("task"; "craft iron_nugget", "goal"; "_roo__ugge""" 111
3. (*task": "smelt iron_nuggat", "goal*; ["iron_nugges", 1]1
37
39
irer_augget.
output: '(teask"; "dig
iron_nugge=",
"goal"; ["iron_nugget", 11)*
Figure 13: Example of action self-correction for iron_ nungnt
21

---

Published as a conference paper at ICLR 2026
For an item nome, you need to make plan, by seleccting one among proviced opt
will give you examples whica plans are needed to achieve an item, juat for reference.
[Εxample]
<item
coals
<task planning>
("task": *dlg down and mine coals", "goal"; : (*coals", 1]]
[Rxample]
11
<item names
13
<task planning>
(*task*: Furnace", "goal"; [*furnace", 1]]
15
[Example]
<item
18
diamond
planning>
20
(*taak*: *dig down and mine diamond", "goal"; ["dicmand", 1]}
22
Here
analyses previous failed plana for this item.
23
[Analysis]
('item_name': 'charcoal',
25
'Laventozy': ('dict'; 1, 'ook_log'; : 2, teeell' 1, 'wooden_hoe's 1, 'wouden "wooden_pickaze" pickaze': 'sorch'; 'stone_axe's : 1, aateneppickaee i, 'stick': vizen_
pickoxe': 'diamond': 'iron_ingot' 3, 'iron_ore's 2, 'caal" 2),
"plan': "mine iron_nugget',
27
"aailureensllsis'": 'You failed because already have enough charcosl.'|
28
30
[Yeur tura]
below <options>, so <task planning>. MUST sel one from be low coptions>, 50 NOT MAKE A PIAM NOT IN coptionss.
<item name?, you MUST select
32
34
coptions>
35
1. ("task"; "mine iron trogent "gesl"; ("charcoal", 1]}
(*task*; "craft charceal", "goal*: ["charcoal",
37
3. ("task*: "smeit charecsi", "goal*: ("charcoal", 11)
39
<item name>
charcoal
<task planning>
42 LLM output: "("toak"; *craft charcoal", "goal": ("charcoal", 11)'
Figure 14: Example of action self-correction for charcoal.
22

---

Published as a conference paper at ICLR 2026
C EXPERIENCED REQUIREMENT SET AND DEPENDENCY GRAPH UPDATE
We note that the assumptions explained in this section are largely similar to those in the implementa- tion of DECKARD (Nottingham al. 2023
Determining experienced requirement set. When the agent obtains item while executing subgoal (a, 9. u), it determines the experienced requirement set Rez((v) differently depending on whether the high-level action "mine" falls under "craft" or "smelt". If "mine", the agent determines Reep(v) (v) based on the pickaxe in its inventory. If no pickaxe is held, Resp(v) is Otherwise. Rezp(u) becomes {(the highest-tier pickaxe the agent has, 1)}. where the highest-tier pickaxe is determined following the hierarchy: "wooden _icckxe_ip_,,, "stone pickaxe", "iron "roo___ckaxc", "diamond_pickax"" pickaxe". If is "craft" or "smelt", the agent determines the used items and their quantities as Rexp ()) by observing inventory changes when crafting or smelting
Dependency graph update. When the agent obtains an item and its Rexp(v) for the first time, it updates its dependency graph 9 = E), Since Resp(t) only contains items acquired before v, cycles can be introduced to ADG during learning. The update proceeds as follows: The agent adds u to both the set of known items V. Then, it updates the edge set & by replacing v's incoming edges with (v): it removes all of e's incoming edges (u, v) E E and adds new edges (u,, qs v) to for every (ui, (b) E (v)
23

---

Published as a conference paper at ICLR 2026
Algorithm 1: Pseudocode of XENON
input
ippu::nvallin invalid action threshold 2g. inadmissible item threshold co, less-explored item scale dg. inadmissible item scale a;
Initialize dependency 9 (V,E), E), revision counts C[v] for all v V
Initialize memory S(a, u) = 0, F(a, 2) = 0 for all v E V.
while learning do
Get an empty inventory inv
Og t SeleettcalMMttiiiifiiuttttCCCCC
// DEX Appendix
while H eppisnde do
if 0g E ine then
1/ + -ee.eettco....ttiitrrrroooooC...
Series aggregated requirements ((u: u)) using 9 and inv // from Section
Plan P + ((a), qt, u))== Ling by selecting az for each u, using LLM, S, F,20 foreach subgoal (a, q, u) E P do
11
Execute (a, q, u) then get the execution result success
13
Get an updated inventory inc, dependency graph ς if success then S(a, u) S(a. u) +1 else F(a, u) +- F(o, u) + if not success then
// from Section
15
if All actions are invalid then
G.C + R-e.eeiinByAnalogyylloooooo
Cl+) co. as 04)
// ADG Section 4.1
Reset memory S(,,u) < U. F(,,)) < 0
2/ f SeLLectcoalWLDDDFFfoouutt..CCC.
break
D FULL PROCEDURE OF XENON
The full procedure XENON is outlined in Algorithm
24

---

Published as a conference paper at ICLR 2026
E DETAILS IN ADAPTIVE DEPENDENCY GRAPH (ADG)
E. RATIONALE FOR INITIAL KNOWLEDGE
In real-world applications. human may wish for autonomous agent accomplish certain goals, yet the user themselves may have limited or no knowledge of how to achieve them within specify goal items without providing
complex environment. We model this scenario by having the detailed requirements, and then the agent should autonomously learn how to obtain these goal items. The set of 67 goal item names (V)) provided to the agent represents such user-specified goal items, defining the learning objectives.
To bootstrap learning in complex environments, LLMM-based planning literature often utilizes minimal plans for initial knowledge (Zhao et al.) 2024; Chen et al. (024). In our case, we
provide the agent with 3 human-written plans (shown Appendix D}. By executing these plans, our agent can experience items and their dependencies, thereby bootstrapping the dependency learning process.
E.2 DETAILS IN DEPENDENCY GRAPH INITIALIZATION
Keeping ADG acyclic during initialization. During initialization, XENON prevents cycles in ADG algorithmically and maintains ADG as directed acyelic graph, by, whenever adding LLM- predicted requirement set for an item, discarding any set that would make a cycle and instead assign an empty requirement
that item. Specifically, identify and prevent cycles three steps when adding LLM- -.Me-ipedeeeed incoming edges for an item First, we tentatively insert the LLM -LM--redicted incoming edges of into the current ADG. Second, we detect eycles by checking whether any of v's parents now appears among v's descendants in the updated graph. Third, if cycle is detected, we discard the L..M- -e.e---peditted incoming edges for u and instead assign an empty set of incoming edges to in the ADG.
Pseudocode shown in Algorithm
The prompt shown in Figure 15
Algorithm 2: GraphInitializztioon
input :Goal items Vo. (optional) human written plans Po
output: : Initialized dependency graph 9 = (V, E), experienced items V
Initialize set of known items V +- Vo. edge set +- 0
Initialize set of experienced items V + 0 foreach plan in Po do
Execute the plan and get experienced items and their experienced requirement sets {Lons (v))()n))) n=1
foreach (v, Rezp(u)) E {(e,, (e)p()x))) do
if v &f then
graph update from Appendix
+ (u).. D+ (u
Add edges to & according to (em
Graph construction using LLM predi ctions
while 3e E D' whose requirement set R(u) has not yet been predicted by the LLM do
Select such an item v E Y V (i.e., R(v) has not yet been predicted)
10
Select VK based Top-K semantic similarity v, |V K
Predict R(v) <- (LM(c, (u, R(u, }
12
13
foreach (uy,9;) E R(v) do
E+ E E ( di 4).
14
if uy E & then V VU (
25

---

Published as a conference paper at ICLR 2026
You are a professional game analyst. For given <item nane?, you need make irequired_iteme> to get the item.
If you make <tequired_items> well, I will give you 1 $.
will give you examples <item_natm name> and <required_items ittms>
6 [Example] TopK similar experienced items are given as examples <item_name>: (experienced_ erequirec_items>>
10
[Your turn]
11
Here is a item name, you MJST output <requi red_items? in JSON format. Remember trequirediitent MUST be in JSON format.
13
<item name?: (item name)
<required [ 14
Figure 15: Prompt for requirement prediction for dependency graph initialization
E.3
PSEUDOCODE OF REVISIONBYANALOGY
Pseudocode shown in Algorithm 3
26

---

Published as a conference paper at ICLR 2026
Algorithm 3: RevisionByAnalogy
input Dependency graph = (V, E). an item to revise v, exploration counts C/+),
inadmissible item threshold co. less-explored item scale as, inadmissible item scale os output: : Revised dependency graph 9 = (V, E), exploration counts C|-]
Consider cases based on Clul:
C'vl > co then
is inadmissible
* resource set: items previously consumed for crafting
other items
R(e) + [(u, 0;) u u "resource" set)
x Remove all incoming edges to in & and add new edges (x,q.0) &)
E ((x, g.
foreach (u, do
* Revise requirement sets of descendants of v Find the set all descendants in 9 (excluding v): W FindAllDescendantsrr, 9) */ for each item in W do Invoke AovisionByAnalon for w
10
else
/* is less explored yet. Revise based on analogy
Find similar successfully obtained items Vx S & based on Top-K semantic similarity to v Candidate items Ucand {u Bw E VK, (u, w) e E) /* all items required to obtain similar successfully obtained items Vx Start construct requirement set, R(v) 0 for each item u in Ueand do if u is in "resource" set then Add (u, as x C(ul) to R(v)
11
14
15
16
17
else
Add (u, to Rvv)
Update g: Remove all incoming edges to v in E, and add new edges (u, v) to for each 19
(u, q) E (D))
27

---

Published as a conference paper at ICLR 2026
F STEP-BY-STEP PLANNING USING FAM
Given sequence of aggregated requirements ((q), Dt)) XENON employs a step-by-step planning approach, iteratively selecting high-level action aj for each requirement item to make subgoal (ar, qt, vy). This process considers the past attempts to obtain vy using specific actions. Specifically, for given item V/. if FAM has empirically valid action, XENON reuses it without prompting the L.M. Otherwise, XENON prompts the LLM to select an action, leveraging information from (i) valid actions for items semantically similar to y (ii) empirically invalid actions for et.
The pseudocode for this action selection process is detailed in Algorithm in Figure
The prompt is shown
Algorithm 4: Step-by-step Planning with FAM
Input :An item v, Action set A, Success/Failure counts from FAM S(...) and F(5.), Invalid action threshold Zo
Output:
:Selctee action aselected
x
1. Classify actions based on FAM history (5 and counts)
+/
Agalid
{a E A S(a, 8) > 0A S(a > F(a, v) ro}
Ag Aivaaid
t {a E A A F(a, 2 S(a,v) +
Agalid + then
/* Reuse the empirically valid action if it exists
Select aselected from Agalid return @selected
else
Otherwise, query LLM with similar examples and filtered candidates
(i) Retrieve valid actions from other items for examples +/
Vsource fue ( (u) Da', S(d,, u) > 0A S(a, u) F(a', u) m0} Identify VeoR& C Vsouroe as the K items most similar to v (using S-BERT) D Dexamples t {(u, apatid) u ViopK avalid E Avalid)
/ (ii) Prune invalid actions to form candidates Acand AA) A Adnvalid
10
Agand then Acand A
11
12
Qselected f- LLM(U, Dezamples: A Acand)
13
return aselected
28

---

Published as a conference paper at ICLR 2026
For item name, you need to make plan, by selecting among provided options.
will give you examples which plans are needed to achi eve an iten, just for reference.
Similar items and their successful plans given [Example]
<item name>
(similar_item}
<task planning>
(successful_plan)
11
[Your turn]
Here is <item name>, you MJST select one from below <options>, to make task planning>.
you MUST select one from pelow <eptions>, DO NOT MAKE A PLAN NOT IN options>.
14
$ Three actions are given, excluding any that were empirically invalid coptions>;
17 1: ("task": "dig down and mine (item]", "goal": [(item), (quantity)
18
2: ("task": "craft (item)", "goal": [fitem), (quantity]]
3: ("task": "smelt (item)", "item": [[item), [quantity]]
21
<item name>
22 (item)
23 <task planning>
Figure 16: Prompt for action selection
29

---

Published as a conference paper at ICLR 2026
G DIFFICULTY-BSSED EXPLORATION (DEX)
For autonomous dependency learning, we introduce DEX. DEX strategically selects items that (1) appear easier obtain, prioritizing those (2) under-explored for diversity and (3) having fewer immediate prerequisite items according the learned graph G. (line in Algorithm p. First. DEX defines the previously unobtained items but whose required items are all obtained according to learned dependency G as the frontier F. Next, the least explored frontier set Fmin == {f F } is identified, based on revision counts C(-). For items f Fmin difficulty D(f") is estimated as Lp, the number of distinct required items needed to obtain f' according to G. The intrinsic goal g is then selected as the item Fmin with the minimum estimated difficulty: = arg yEFms (ff). Ties are broken uniformly at random.
C()) fF C(f"))
While our frontier concept motivated by DECKARD (Nottingham al. 2023), DEX's selection process differs significantly. DECKARD selects randomly from { E F C(e) Co but if this set empty. it selects randomly from the union of frontier and previously obtained item set. This risks inefficient attempts on already obtained items. In contrast, DEX exclusively selects goals from Fuin: inherently avoiding obtained items. This efficiently guides exploration towards achievable, novel dependencies.
30

---

Published as a conference paper at ICLR 2026
H CONTEXT-AWARE REPROMPTING (CRE)
Minecraft, a real-world-like environment can lead to situations where the controller stalls (e.g., when stuck in deep water or cave). To assist the controller, the agent provides lemporary prompls guide it (e.g., "get out of the water and find trees"), "). XENON proposes a context-aware reprompting scheme. is inspired by Optimus-1 et al. (004bb) but introduces two key differences:
(a) Two-stage reasoning. When invoked, in Optimus-1, LLM simultaneously interprets image observations, decides whether to reprompt, and generates new prompts. XENON decomposes this process into two distinct steps:
the LLM generates caption for the current image observation, and
iii using text-only input (the generated caption and the current subgoal prompt), the LLM determines if reprompting is necessary and, if so, produces temporary prompt.
(b) Trigger. Unlike Optimus-1, which invokes the LLM at fixed intervals, XENON calls the LLM only if the current subgoal item has been obtained within that interval. This approach avoids unnecessary spurious interventions from smaller LLM.
The prompt is shown in Figure 17
31

---

Published as a conference paper at ICLR 2026
Prompt for the first step: image captioning Given Minecraft game image, describe nearby Minecraft objects, like
tree, grass, cobblestone, etc.
[Example]
"There is a large tree with dark green leaves surrounding the area. "The image shows a dark, cave-like environment in Minecraft. The player is digging downwards. There are no visible trees or grass in this particular view."
"The image shows a dark, narrow tunnel made stone blocks. The player is digging downwards."
[Your turn] Desoribe the given image, simply and clearly like the examples.
Prompt for the second step: reascning whether reprompting needed or not
Gi ven <task> and tvisual duual_ddsrrpptenn determine if the player needs intervention to achieve the goal. If intervention is needed, suggest a task that the player should perform.
12
I will give you examples.
13
[Example]
<task>: chop tree <visual_deseription:: There is large tree with dark green leaves surrounding the area.
16
<goal_item>: logs
<reasoning>:
"neea intervention": false,
20
"thoughts"; "The player can see a tree and can chop it down to get logs.", "task"; "",
}}
23 [Example]
24 <task>: chop tree
<visual_dee qnual_description>. The image shows dirt block in Minecraft. There is tree in the image, but it is too far from here.
26
<goal_item>: logs
27
<reasoning>:
28
{1
inre__innterenttoo"" true,
"thoughts"; "The player is far from trees. The player needs the trees.",
31
"task": "explore to find trees",
32 1)
[Example]
<task>: dig down to iron_ore wvisual_descripting The image shows a dark, narrow tunnel made of stone
35
blocks. The player is digging downwards.
<goal_item>: iron_ore
<reasoning>: {1
39
"need_ intervetttrr:n::nnn false, "thoughts"; "The player is already digging down and is likely to find iron ore.",
"task": ""
42 }}
43
[Your turn]
fere is the <task>, <visual description>, and item>.
You MUST output the <reasoning> in JSON format.
46
<task>: (task] current prompt for the controller wviuul_desccipptonn
47
dnisualddescription $ caption from the step <goal_item>: (geal_item) $ current subgoal item <reasoning>:
48
Figure 17: Prompt for context-aware reprompting
32

---

Published as a conference paper at ICLR 2026
I IMPLEMENTATION DETAILS
To identify similar items, semantic similarity between two items is computed as the cosine similarity of their Sentence-BERT (all-MiniLM--L--22 model) embeddings (Reimers & Gurevych 2019). This metric is utilized whenever item similarity comparisons are needed, such as in Algorithm Algorithm and Algorithm
1.1 HYPERPARAMETERS
Table 7: Hyperparameters used in our experiments.
Hyperparameter
Notation
Value
Failure threshold for invalid action Revision count threshold for inadmissible items
20
3
Required items quantity scale for less explored items Required items quantity scale for inadmissible items Number top-K similar experienced items used
Cts
2
Or
For all experiments, we use consistent hyperparameters across environments. The hyperparameters, whose values are determined with mainly considering robustness against imperfect controllers. All hyperparameters are listed in Table 7 The implications of increasing each hyperparameter's 's value detailed below:
(failure threshold for empirically invalid action): Prevents valid actions from being mis- classified as invalid due to accidental failures from an imperfect controller or environmental stochasticity. Values that are too small or large hinder dependency learning and planning by hampering the discovery of valid actions.
co (exploration count threshold for inadmissible items): Ensures an item is sufficiently attempted before being deemed 'inadmissible' and triggering revision for its descendants. Too small/large values could cause inefficiency; small values prematurely abandon poten- tially correct LLM predictions for descendants, while large values prevent attempts descendant items.
as (required items quantity scale for less explored items): Controls the gradual increase of required quantities for revised required items. Small values make learning inefficient by hindering item obtaining due insufficient required items, yet large values lower robustness overburdening controllers with excessive quantity demands.
(required items quantity scale for inadmissible items): Ensures sufficient acquisition of potential required items before retrying inadmissible items to increase the chance of success. Improper values reduce robustness; too small leads to failure in obtaining items necessitating many items; too large burdens controllers with excessive quantity demands.
(Number of similar items to retrieve): Determines how many similar, previously suc- cessful experiences are retrieved to inform dependency revision (Algorithm 3) and action selection (Algorithm
I.2 HUMAN-WRITTED PLANS
We utilize three human-writte plans (for iron sword, golden sword, and diamond, shown in Plan 18 19 and 20 respectively). the format of which borrowed from the human-written plan examples in the publicly released Optimus-1 repository We leverage the experiences gained from executing these plans to initialize XENON's knowledge.
https://githhn
py
33

---

Published as a conference paper at ICLR 2026
iron_sword: str uиn
<goal>: craft iron sword.
<requirements>:
1. log: need 7
2. planks: need 21
3. stick: need
4. crafting table: need 1
8 5. wooden_pickaxe: need 1
6. cobblestone: need 11
7. furnace: need 1
8. stone_pickaxe need
12 9. iron_ore need
13
10. iron_inget: need 2
14
11. iron_swerd: need 1
<plan>
17 "step 1": ("prompt": "mine logs", "item": ["logs", 71),
18
"step 2": ("prompt": "craft planks", "item": ["planks", 21])
"step 3": ("prompt": "craft stick", "item": ["stick", 5]},
"step 4":
("prompt": "craft crafting_tablet" "item": ["crafting_table"
11b,
21 "step 5": ("prompt": "craft wooden pickkxe,, "item": ["wooden pocoddenpiccaxe,,,,,,
111,
"step 6": ("prompt": "mine cobblestcne", "item": [*cobblestone", 111h,
23
"step 7"; ("prompt": "craft furnace", "item": ["furnace", 11), ("prompt": "craft stone_pickaxe", "item": ("stone_pickaxe",
24
"step 8":
1]
"step 9*: ("prompt": "mine iron_ere", "item": ["iron_ore", 2]),
"step 10": ("prompt": "smelt iren_ingot", "item": ("iron_ingot", 2]
27
"step 11"; ("prompt"; "craft iron_sword", "item": ("iron_sword", 1]
28
Figure 18: furtte-wrttten plan for crafting an iron sword.
34

---

Published as a conference paper at ICLR 2026
swodd_ str **.
<goal>: craft a golden sword. <roquircments>>:
1. log: need 9
2. planks: need 27
6 3. stick: need
7 4. crafting_table: need 1
5. pickaxxe need 1
6. cobblestene: need 11
7. furnace: need
11 8. stone_pickaxe: need 1
9. iron_ore: need
10. iron_inget: need 3
11. iron pickaeic need
15
12. gold_ore need
16
13. gold_inget: need 2
14. golden_sword; need 1
<plan>
20 "step 1": ("prompt": "mine logs", "item": ["logs", 71),
21
"step 2": ("prompt": "craft planks", "item": ["planks", 21]),
"step 3": ("prompt": "craft stick", "item": ["stick", 5]},
"step 4":
("prompt": "craft crafting_tables "item": ["crafting_tabler
11b,
24 "step 5": ("prompt": "craft wooden pickkxe,, "item": ["wooden pocoddenpiccaxe,,,,,,
111,
"step 6": ("prompt": "mine cobblestcne", "item": [*cobblestone", 111h,
26
"step 7"; ("prompt": "craft furnace", "item": ["furnace", 11), ("prompt": "craft stone_pickaxe", "item": ("stone_pickaxe"
27
"step 8":
1]},
"step 9*: ("prompt": "mine iron_cre", "item": ["iron_ore", 3}},
"step 10": ("prompt": "smelt iren con__nngo",, "item": ("iron_ingot", 3]
30
"step 11": ["task": "craft iron_pickexe", "goal"; ("iron_pickaxe" ill,
31
"step 12": ("prompt": "mine gold_cre", "item": ["gold_ore", 21),
32
"step 13": ("proupt"; "smelt ingot", "item": ingot"" 2)
"step 14"; ("task": "craft golden_sword", "goal": ["golden_sword",
35
Figure 19: Human- Human-written written plan for crafting golden sword.
35

---

Published as a conference paper at ICLR 2026
diamond: str
<goal>; mine diamond.
<requirements>:
1. log: need
2. planks: need 21
3. stick: need
4. crafting table: need 1
5. wooden pickaxe: need 1
6. cobblestone: need 11
7. furnace: need 1
8. stone_pickaxe: need 1
9. iron_ore: need
13
10. iron tron_ingot: need
14
11. iron_ iron_pickaxe: need 1
12. diamond: need
<plan>
"step 1": ("prompt": "mine logs", "item": ["logs", 71),
19 "step 2": ("prompt": "craft planks", "item": ["planks", 21])
"step 3": ("prompt": "craft stick", "item": ["stick", 5]},
"step 4":
("prompt": "craft crafting_tablet "item": ["crafting_table"
11b,
22 "step 5": ("prompt": "craft wooden pickkxe,, "item": ["wooden pocoddenpiccaxe,,,,,,
111,
"step 6": ("prompt": "mine cobblestcne", "item": [*cobblestone", 111h,
24
"step 7"; ("prompt": "craft furnace", "item": ["furnace", 11), ("prompt": "craft stone_pickaxe", "item": ""stone_pickaxe",
25
"step 8":
1]
"step 9*: ("prompt": "mine iron_cre", "item": ["iron_ore' 2]),
"step 10": ("prompt": "smelt iren_ingot", "item": ("iron_ingot", 2]),
28
"step 11": ("prompt"; "craft iron_pickaxe", "item": ("iron_pickaxe", 1l),
29
"step 12": ("prompt"; "mine diamend", "item": ["diamond", 11]
30
Figure 20: Human-written plan for mining a diamond.
36

---

Published as a conference paper at ICLR 2026
J DETAILS FOR EXPERIMENTAL SETUP
J.1 COMPARED BASELINES FOR DEPENDENCY LEARNING
We compare proposed method, XENON, against four baselines: LLM self-correction (SC), DECKARD (oottnnhnttn et al. (2023), ADAM (Yu & Lu 2024), and RAND (the simplest baseline). As no prior baselines were evaluated under our specific experimental setup (i.e., empty initial inventory. pre-trained low-level controller), we adapted their implementation to align with our environment. SC is implemented following common methods that prompt the LLM to correct its knowledge upon plan failures (Shinn et al. 2023; Stechly et al.) 2024). A summary of all methods compared in our experiments provided in Table 8 All methods share the following common experimental setting: each episode starts with an imitial experienced requirements for some items, derived from human-writte plans (details in Appendix []. Additionally, all agents begin each episode with an initial empty inventory.
Table 8: Summary of methods compared in our experiments.
Method
Predicted Requirement Set
Action Memory
Intrinsic Goal Selection
XENON
L-n-errrtte (with revision)
Success & Failure
DEX
SC
LLM generated (with revision)
Success Failure
Random
ADAM & 2024
"B x resources"
Successonnly Success-only
Random
DECKARD Nollingham et 2023
LLM generated (wilhout revision) 1.1 geneeratd (without revision)
Frontier
obtained items
RAND
None
Random
LLM self-correction (SC). While no prior work specifically uses LLM celf-correction to learn Minecraft item dependencies in our setting, we include this bascline demonstrate the unreliability of this approach. For predicted requirements, similar to XENON, SC initializes its dependency graph with -----rddicted requirements for each item. When a plan for an item fails repeatedly, attempts to revise the requirements using LLM. SC prompts the LLM itself to perform the correction, providing it with recent trajectories and the validated requirements of similar, previously obtained items in the input prompt. SC's action memory stores both successful and failed actions for each item. Upon a plan failure, the LLM is prompted to self-reflect on the recent trajectory to determine the cause of failure. When the agent later plans obtain an item which it previously failed, this reflection is included in the LLM's prompt to guide its action selection. Intrinsic goals are selected randomly from the set of previously unobtained items. The specific prompts used for the L.M self-correction and self-reflection in this baseline are provided in Appendix B
The original DECKARD utilizes --eedddddeeed requirements for each item but does revise these initial predictions. It has no explicit action memory for the planner; instead, it trains and maintains specialized policies for each obtained item. It selects an intrinsic goal randomly from less explored frontier items (i.e.. {u F C(v) S cu)). no such items are available, it selects randomly from the union of experienced items and all frontier items.
DECKARD.
In our experiments, the DECKARD bascline implemented largely mirror the original version, with the exception of its memory system. Its memory is implemented to store only successful actions without recording failures. This design choice aligns with the original DECKARD's approach, which, by only learning policies for successfully obtained items, lacks policies for unobtained items.
ADAM. The original ADAM started with an initial inventory containing 32 quantities of experienced resource items (i.e.. items used for crafting other items) and quantity of tool items (e.g., pickaxes, crafting table), implicitly treating those items as a predicted requirement set for each item. Its memory recorded which actions were used for each subgoal item without noting success or failure, and its intrinsic goal selection was guided by expert-defined exploration curriculum.
In our experiments, ADAM starts with an empty initial inventory. The predicted requirements for each goal item in our ADAM implementation assume a fixed quantity of 8 for all resource items. This quantity was chosen to align with a, the hyperparameter for the quantity scale of requirement items for inadmissible items, thereby ensuring fair comparison with XENON. The memory stores successful actions for each item, but did not record failures. This modification aligns the memory mechanism with SC and DECKARD baselines, enabling more consistent comparison across
37

---

Published as a conference paper at ICLR 2026
baselines in experimental setup. Intrinsic goal selection is random, we do not assume such an expert-defined exploration curriculum.
RAND. RAND is a simple baseline specifically designed for our experimental setup. started with empty initial inventory and an LLM -LM--pdddcted requirement set for each item. RAND did not incorporate any action memory. Its intrinsic goal selection involved randomly selecting from unexperienced items.
J.2
MINERL ENVIRONMENT
J.2.1 BASIC RULES
Minecraft has been adopted as suitable testbed for validating performance of Al agents long- horizon tasks (Mao et al., 2022 Lin et al. [202T] Baker et al.] [022]] Li et al. (025a), largely because of the inherent dependency in item acquisition where agents must obtain prerequisite items before more advanced ones. Specifically, Minecraft features multiple technology levels ievels-including wood, stone, iron, gold, diamond, etc. wwhich dictate item and tool dependencies. For instance, an agent must first craft a lower-level tool like a wooden pickaxe to mine materials such as stone. Subsequently, stone pickaxe is required mine even higher-level materials like iron. An iron pickaxe is required to mine materials like gold and diamond. Respecting the dependency is crucial for achieving complex goals, such as crafting an iron sword or mining diamond.
J.2.2 OBSERVATION AND ACTION SPACE
First, we employ MineRL (Gus et 2019) with Minecraft version 1.16.5.
Observation. When making a plan, agent receives inventory information (i.e., item with their quantities) as text. When executing the plan, our agent receives an RGB image with dimensions of 640 360, including the hotbar, health indicators, food saturation, and animations of the player's hands.
Action space. Following Optimus-1 (Li et al. 2024b), our low-level action space primarily consists of keyboard and mouse controls, except for craft and smelt high-level actions. Crucially, craft and smelt actions are included into our action space, following (Li et al.) 2024b). This means these high-level actions automatically succeed in producing an item if the agent possesses all the required items and valid actions for that item is chosen; otherwise, they fail. This abstraction removes the need for complex, precise low-level mouse control for these specific actions. For low-level controls, keyboard presses control agent movement (e.g., jumping, moving forward, backward) and mouse movements control the agent's perspective. The mouse's left and right buttons are used for attacking, using, placing items. The detailed action space is described in Table 9
Table 9: Action space in MineRL environment
Index
Action
Human Action
Description
Forward
key W
Move forward.
Back
key S
Move back.
Left
key A
Move left.
Right
key D
Move right.
Jump
key Space
Jump. When swimming. keeps player afloat. Slowly move in the current direction movement. Move quickly in the direction of current movement.
Sneak
key left Shift
Sprint
key left Ctrl
Attack
left Button
Destroy blocks (hold down); Attack entity (click once).
Use
right Button
Place blocks, entity, open items other interact actions defined by game.
hotbar [1-9]
keys
Selects the appropriate hotbar item.
11
Open/Close Inventory
key E
Opens the Inventory. Close any open GUL.
12
Yaw
move Mouse X
Turning: aiming; camera movement. movement.Ranging from -180 to +180. Tuming: aiming; movement. Ranging from -180 +180.
Pitch
Mouse
Craft
Execute crafting to obtuin new item
15
Smelt
Execute smelting to obtain new item.
38

---

Published as a conference paper at ICLR 2026
J.2.3 GOALS
We consider 67 goals from the long-horizon tasks benchmark suggested in (Li et al. 2024b). These goals are categorized into 7 groups based on Minecraft's item categories: Wood Stone Iron @, and Armor All goal items within each group are listed
Gold @ Diamond c Redstone
in Table TO
Table 10: Setting of groups encompassing 67 Minecraft long-horizon goals.
Group
Goal Num.
All goal items
Wood
10
bowl, srafting_table chest, ladder, stick, wooden_ar _xxe wooden hoe, wooden pickkxe_ wooden wooden_shovel, wooden_swort
Stone
charcoal, furnace, smoker, _xone_axe, stone_hoe, stone_pickaxe, stone_shovel, stone_sword, torch
Iron
16
bucket, chain, hopper, iron_axe _xe_ iron tron_bars, iron_hoe, iron_ non_nuggee, iron tron_pickaxe, iron tron_shovel, iron_sword, rail, shears, smithing stonecutter, tripwire_hook
Gold
gold_ingon, golden_axe axe, golden_hoe, golden_pickase golden_shovel golden_sword
Redstone
activator rail, compass, dropper, note block, piston, red- stone torch
Diamond
diamond, diamond_an diamond_her diamond_pickake diamond_shoved diamond_sword juw.o,,
Armor
13
diamond boots, diamond diamond_chestplanne chestplate, diamond helmet,
diamond _eggings, golden_ _booss golden_ chestplate, [eden_helmmt, golden_leggings iron_ con__chestllaee iron_ iron rrog_nnggings, shield
iron_boots,
Additional goals for scalability experiments.. To evaluate the scalability of XENON with respect to the number of goals Appendix K.9) we extend the above 67-goal set (Table by adding additional goal items to construct two larger settings with 100 and 120 goals; the added goals are listed in Table
Specifically, in the setting with 100 goals, we add 33 goals in total by introducing "leather", "paper", and "flint" groups and by adding more items to the existing "wood" and "stone" groups. In the setting with 120 goals, we further add 20 goals in the "iron", "gold", "redstone", and "diamond" groups
J.2.4 EPISODE HORIZON
The episode horizon varies depending the experiment phase: dependency learning long- horizon goal planning. During the dependency learning phase, each episode has a fixed horizon of 36,000 steps. In this phase, if the agent successfully achieves an intrinsic goal within episode, is allowed to select another intrinsic goal and continue exploration without the episode ending. After dependency learning, when measuring the success rate of goals from the long-horizon task benchmark, the episode horizon differs based on the goal's category group. And this phase, the episode immediately terminates upon success of a goal. The specific episode horizons for each group are as follows: Wood: 3,600 steps; Stone: 7,200 steps; Iron: 12,000 steps; and Gold, Diamond, Redstone, and Armor: 36,000 steps each.
J.2.5 ITEM SPAWN PROBABILITY DETAILS
Following Optimus- I's public implementation, we have modified environment configuration different from original MineRL environment (Guss et al., 2019). In Minecraft, obtaining essential resources
39

---

Published as a conference paper at ICLR 2026
Table 11: Additional goals used for the scalability experiments. The setting with 100 goals extends the 67-goal set in Table TO by adding all items in the top block; the setting with 120 goals further includes both the top and bottom blocks.
Group
Goal Num.
Added goal items
Additional items in the setting with 100 goals (33 items)
leather
7
leather, leather_boots, leather_ saanherrchestplate, beather_helmee leather_leggings, leather_horse_ammeee item_frand map, book, cartography_rade bookshelf, lectern flint, flint_and_stedd fletching_ arrow
paper
5
flint
4
wood
bow, boat, wooden_slan gooden_staing gooden_door, wooden_sign, wooden_fence, woodenfence_gart
stone
9
cobblestone_slar cobblestone_ stairssstsss,,,t cobblestone_ wall, lever, stone_slab, stone_button, stone_pressure_ stone bricks, grindstone
Additional items only in the setting with 120 goals (20 more items)
iron
7
iron_ pra_trapdor, heavy weirryyweetedddeeoo weighted__presuure pressure_plate, iron_doom crossbow, minecart, cauldron, lantern gold_n light_weighted pressure_platte aaden_aaplc, golden_camey redstone, powered_raii, target, dispenser, clock, repeater, detector rail obsidian, enchanting_taie table
gold
4
redstone
diamond
table
such iron, gold, and diamond requires mining their respective naturally rare, making them challenging to obtain. This inherent difficulty can significantly hinder an agent's goal completion, even with accurate plan. This challenge in resource gathering due an imperfect controller is a common bottleneck, leading many prior works to employ environmental modifications focus on planning. For example. DEPS (Wang al. 2023b) restricts the controller's actions based on the goal items Optimus-1 (Li et al. 2024b) also made resource items easier to obtain by increasing item ore spawn probabilities. To focus on our primary goal of robust planning and isolate this challenge, we follow Optimus-1 I and adopt its item ore spawn procedure directly from the publicly released Optimus-1 repository, without any modifications its source code [
However, these
The ore spawn procedure probabilistically spawns ore blocks in the vicinity of the agent's 's current coordinates (a, y, z). Specifically, at each timestep, the procedure has 10% chance of activating. When activated, it spawns specific type of ore block based on the agent's y-coordinate. Furthermore, for any given episode, the procedure is not activate more than once at the same y-coordinate. The types of ore blocks spawned at different levels
follows:
Coal Ore: between y=45 and y=50.
Iron Ore: between y=26 and y=43.
Gold Ore: between y=15 and y=26
Redstone Ore: between y=15 and y=26
Diamond Ore: below y=14
http:///thttaaaooooooo///////aaa wrapper.Py
40

---

Published as a conference paper at ICLR 2026
J.3 MINEFLAYER ENVIRONMENT
We use the Mineflayer [PrismarineJS] 2023) environment with Minecraft version 1.19. In Mineflayer, resource item spawn probabilities do need to be adjusted, unlike in MineRL Appendix [.2.5] This is because the controller, JavaScript APIS provided by Mineflayer, is competent to gather many resource items.
J.3.1 OBSERVATION AND ACTION SPACE
The agent's observation space is multimodal. For planning, the agent receives its current inventory (i.e., item names and their quantities) as text. For plan execution, it receives first-person RGB image that includes the hotbar, health and food indicators, and player hand animations. For action space, following ADAM (Yu & Lu (024),, we use the JavaScript APIs provided by Mineflayer for low-level control. Specifically, our high-level actions, such as "craft", "smelt", and "mine", are mapped to corresponding Mineflayer APIs like craft Ittm, sme 1t em,m, and mineBlock.
J.3.2 EPISODE HORIZON
For dependency learning, each episode has a fixed horizon of 30 minutes, which is equivalent to 36,000 steps in the MineRL environment. the agent successfully achieves a goal within this horizon, it selects another exploratory goal and continues within the same episode.
J.4 MC-TEXTWORLD
MC-Textworld is text-based environment based on Minecraft game rules (Zheng et al.) 2025). We employ Minecraft version 1.16.5. this environment, basic rules and goals are the same as those in the MineRL envirommett Appendix J.2 Furthermore, resource item spawn probabilities do not need to be adjusted, unlike in MineRL Appendix This is because an agent succeeds in mining an item immediately without spatial exploration. if has a required tool and "mine" is valid action for that item.
In the following subsections, we detail the remaining aspects of experiment setups in this environment: the observation and action space, and the episode horizon.
J.4.1 OBSERVATION AND ACTION SPACE
The agent receives a text-based observation consisting of inventory information (i.e., currently possessed items and their quantities). Actions also text-based, where each action represented as an high-level action followed by an item name (e.g.. "mine diamond"). Thus, to execute a subgoal specified as (a, q, v) (high-level action a, quantity g. item v), the agent repeatedly performs the action (a, e) until units of are obtained.
J.4.2 EPISODE HORIZON
In this environment, we conduct experiments for dependency learning only. Each episode has fixed horizon of 3,000 steps. If the agent successfully achieves an intrinsic goal within an episode, is then allowed to select another intrinsic goal and continue exploration, without termination of the episode.
J.4.3 PERTURBATION ON GROUND TRUTH RULES
To evaluate each agent's robustness to conflicts with its prior knowledge, we perturb the ground-truth rules (required items and actions) for a subset of goal items, as shown in Figure 22] The perturbation is applied at different intensity levels (from 1 to 3), where higher levels affect greater number of items. These levels are cumulative, meaning Level 2 perturbation includes perturbations from Level 1 plus additional ones.
Vanilla Setting: In the setting with no perturbation (Figure 21 a), the ground-truth rules are unmodified. In the figure, items in the black solid boxes the goal items, and those with arrows pointing to them are their true required items. Each goal item has "craft" as a valid action.
41

---

Published as a conference paper at ICLR 2026
(a) Vanilla
(b) Perturbed True Required items
(c) Perturbed True Actions
Replace
Level
Level
Level
Level
Level
Level
Valid action: craft
Valid action: craft
Valid action: craft mine OR smelt
Figure 21: Illustration of the ground truth rule perturbation settings. (a) in the vanilla setting, goal items (black boxes) have standard required items (incoming edges) and "craft" is the valid action; (b) in the Perturbed Requirements setting, required item (red dashed circle) is replaced by randomly from a candidate pool (blue dashed box); (c) in the Perturbed Actions setting, the valid action is changed either "mine" "smelt".
Perturbed True Required Items: In this setting (Figure 21 b), one of the true required items (indicated by a red dashed circle) for goal is replaced. The new required item is chosen uniformly at random from a candidate pool (blue dashed box). The valid action remains craft.
In this setting (Figure 21 c). the valid action for goal is randomly changed from "craft" to either "mine" or "smelt". The required items are not modified.
Perturbed True Actions:
Perturbed Both Rules: In this setting, both the required items and the valid actions are modified according to the rules described above.
42

---

Published as a conference paper at ICLR 2026
K ADDITIONAL EXPERIMENTAL RESULTS
K.1 LLM-PREDICTED INITIAL DEPENDENCY GRAPH ANALYSIS
Table 12:
Performance analysis for the initial LLM-predicted requirement sets over 75 Minecraft items, used to build the initial dependency graph. Note that while began the prediction process with 67 goal items, the total number predicted items expanded 75. This expansion occurred because, the LLM predicted requirement sets for items in the dependency graph (initially for those goal items), any newly mentioned items that were not yet part of the graph are also included. This iterative process is detailed in Section 4. (Dependency graph initialization) of method.
Metric
Value
Requirement Set Prediction Accuracy
Correct items (ignoring quantities)
23%
Exact items quantities
8%
Non-existent Item Rates
Non-existent items
8%
Descendants of non-existent items
23%
Required Items Errors
Unnecessary items included
57%
Required items omitted
57%
Required Item Quantity Prediction Errors
Standard deviation of quantity error
2.74
Mean absolute quantity error
2.05
Mcan signed quantity error
-0.55
The initial dependency graph, constructed from predictions by Qwen2.5-VL-7B (Bai et al. 2025),
forms the initial planning knowledge for XENON (Section 4.1) This section analyzes quality. highlighting limitations that necessitate our adaptive dependency learning.
As shown in Table [2] the 7B LLM's initial requirement sets exhibit significant inaccuracies. Ac- curacy for correct item types was 23%, dropping to 8% for exact items and quantities. Errors in dependency among items are also prevalent: 57% of items included unnecessary items, and 57% omitted required items. Furthermore, 8% of predicted items were non-existent (hallucinated), making 23% of descendant items unattainable. Quantity predictions also showed substantial errors, with mean absolute eтror of 2.05.
These results clearly demonstrate the LLM-generated initial dependency graph is imperfect. Its low accuracy and high eиror rates underscore the unreliability of raw LLM knowledge for precise planning. particularly for smaller models like the 7B LLM which are known to have limited prior knowledge Minecraft, noted in previous work (ADAM. Yu & Lu (2024). Appendix A. L.MS' Prior Knowledge on Minecraft). This analysis therefore highlights the importance of the adaptive dependency learning within XENON, which is designed refine this initial, imperfect knowledge for robust planning.
Table 13: Ratio of dependencies learned for items which unobtainable by the flawed initial dependency graph (out of 51). Analysis is based on the final learned graphs from the MineRL experiments.
Learned ratio
Agent
(initially unobtainable items)
XENON
0.51
SC
0.25
DECKARD
0.25
ADAM
0.00
RAND
0.02
43

---

achieves a 0.00 success rate for the Diamond Published as a conference paper at ICLR 2026
K.2 ADDITIONAL ANALYSIS OF LEARNED DEPENDENCY GRAPH
As shown in Table 13 XENON demonstrates significantly greater robustness to the LLM's flawed prior knowledge compared to baselines. successfully learned the correct dependencies for over half (0.51) of the 51 items that were initially unobtainable by the flawed graph. In contrast, both DECKARD (with no correction) and the SC baseline (with LLM selffcorrection) learned only a quarter of these items (0.25). This result strongly indicates that relying on the LLM to correct its own errors is as ineffective as having no correction mechanism at all in this setting. The other baselines, ADAM and RAND, failed almost completely, highlighting the difficulty of this challenge.
K.3 IMPACT OF CONTROLLER CAPACITY ON DEPENDENCY LEARNING
We observe that controller capacity significantly impacts an agent's 's ability to learn dependencies from interaction. Specifically, in our MineRL experiments, we find that ADAM fails to learn any new dependencies due to the inherent incompatibility between its strategy and the controller's ' limitations. In our realistic setting with empty initial inventories, ADAM's strategy requires gathering a sufficient quantity (fixed at 8, same with our hyperparameter ( of all previously used resources before attempting a new item. This list of required resource items includes gold ingot @ because of an initially provided human-written plan for golden sword; however, the controller STEVE-1 never managed to collect more than seven units of gold a single episode across all our experiments. Consequently, this controller bottleneck prevents ADAM from ever attempting to learn new items, causing its dependency learning to stall completely.
Although XENON fails to learn dependencies for the Redstone group items in MineRL, our analysis shows this stems from controller limitations rather than algorithmic ones. Specifically, in MineRL, STEVE-1 cannot execute XENON's exploration strategy for inadmissible items, which involves gathering a sufficient quantity of all previously used resources before a retry (Section 4.1) The Redstone group items become inadmissible because the LLM's initial predictions for them are entirely incorrect. This lack of a valid starting point prevents XENON from ever experiencing the core item, redstone, being used as a requirement for any other item. Consequently, our Revis LnnByAnala ogy mechanism has no analogous experience to propose redstone as a potential required item for other items during its revision process.
In contrast, with more competent controllers, XENON successfully overcomes even such severely flawed prior knowledge to learn the challenging Redstone group dependencies, as demonstrated in Mineflayer and MC-Tex(World. First, in Mineflayer, XENON learns the correct dependencies for 5 out of 6 Redstone items. This success is possible because its more competent controller can execute the exploration strategy for inadmissible items, which increases the chance of possessing the core required item (redstone) during resource gathering. Second, with a perfect controller in MC-TextWorld, XENON successfully learns the dependencies for all 6 Redstone group items in every single episode.
K.4 IMPACT OF CONTROLLER CAPACITY IN LONG-HORIZON GOAL PLANNING
Because our work focuses on building robust planner, isolate the planning from the significant difficulty of item gathering- task assigned to the controller-on main experiments for long-horizon tasks (Section5) 5.3) uses a modified MineRL environment following the official implementation of Optimus-1. 1. This modification makes essential resource items like iron, gold, and diamond easier for the controller to find, allowing for a clearer evaluation of planning algorithms (modifications are detailed in Appendix J.2.5). However, to provide a more comprehensive analysis, we also evaluated our agent and baselines in the unmodified, standard MineRL. environment. In this setting, items like iron, gold, and diamond are naturally rare, making item gathering major bottleneck.
The results are shown in Table 14 Most importantly, XENON" consistently outperforms the baselines in both the modified and standard MineRL. Notably, in the standard environment, XENON* 's performance on the Iron group (0.24 SR) is comparable to that of the OracleActionPllnnerr (0.27 SR), which always generates correct plans for all goals. This comparison highlights the severity of the controller bottleneck: even the OracleActionPlanne
"The scaling factor for required item quantities for inadmissible items.
44

---

Published as a conference paper at ICLR 2026
Table 14: Long-horizon task success rate (SR) comparison between the Modified MineRL (a setting where resource items are easier to obtain) and Standard MineRL environments. All methods are provided with the correct dependency graph. DEPSi and Optimus-1f are our reproductions of the respective methods using Qwen2.5-VL-7B as planner. OracleActionPlammer, which generates the correct plan for all goals, represents performance upper bound. SR for Optimus-1 i and XENON" in the Modified MineRL column are taken from Table 3
in Section 5.3
Modified MineRL
Standard MineRL
Method
Dependency
Iron
Diamond
Gold
Iron
Diamond
Gold
DEPSi
0.02
0.00
0.01
0.01
0.00
0.00
Optimus-1f
Oracle
0.23
0.10
0.11
0.13
0.00
0.00
XENON*
Oracle
0.83
0.75
0.73
0.24
0.00
0.00
OrackeActionPlanner
Oracle
0.27
0.00
0.00
and Gold groups in the standard MineRI. This shows that the failures due the controller's inability to gather rare resources in the standard environment.
K.5 LONG-HORIZON TASK BENCHMARK EXPERIMENT' ANALYSIS
This section provides a detailed analysis of the performance differences observed Table between Optimus-11 and XENON* long- long-horizon tasks, even when both access to a true dependency graph and increased item spawn probabilities (Appendix (.2.5). specifically examine various plan errors encountered when reproducing Optimus-1 using Qwen2.5-VL VL--BB as the planner, and explain how XENON" robustly constructs plans through step-by-ste step-py-tepppp planning with FAM.
Table 15: Analysis of primary plan errors observed in Optimus-1 11 and XENON during long-horizon tasks benchmark experiments. This table presents the ratio of specified plan error among the failed episodes for Optimus-11 1 and XENON" respectively. Invalid Action indicates errors where an invalid action is used for an item subgoal. Subgoal Omission refers to errors where a necessary subgoal for required item is omitted from the plan. Note that these plan error values are not exclusive; one episode can exhibit multiple types of plan errors.
Plan Error Type
Optimus-1 Error Rate ( (%)
XENON' Error Rate ( (%)
Invalid Action
37
2
Subgoal Omission
44
0
Optimus-1 1 has fine-grained action knowledge correction mechanism. Furthermore, Optimus- It's LLM planner generates a long plan at once with a long input prompt including a sequence of aggregated requirements ((g1, uI)...., (gL., uL.) (1, u)) for the goal item v. Consequently. as shown in Table [5] Optimus-1 generates plans with invalid actions for required items, denoted as Invalid Action. Furthermore, Optimus-1 1 omits necessary subgoals for required items, even they are in the input prompts, denoted as Subgoal Omission.
In contrast, XENON discovers valid actions by leveraging FAM, which records the outcomes of each action for every item, thereby enabling it to avoid empirically failed ones and and reuse successful ones. Furthermore, XENON mitigates the problem of subgoal omission through constructing plan by making subgoal for each required item one-by-one.
45

---

Published as a conference paper at ICLR 2026
K.6
ROBUST DEPENDENCY LEARNING UNDER DYNAMIC TRUE KNOWLEDGE
XENON
SC
ADAM
DECKARD
RAND
1.0
0.8
Thue requirements fare changed
0.8
True actions
0.8
Both true rules fare changed
fare changed
0.6
EGA
0.6
0.6
0.4
0.4
0.4
0
1000
2000
3000
0
1000
2000
3000
0
1000
2000
3000
Environment step
Environment step
Environment step
(a) Dynamic True Required Items
(b) Dynamic True Actions
(c) Dynamic Both Rules
Figure 22: Robustness against dynamic true knowledge. EGA over 3,000 environment steps in the where the true item acquisition rules are changed during the learning process.
Additionally, We show XENON is also applicable sce- narios where the latent true knowledge changes dynami- cally. We design three dynamic scenarios where the en- vironment begins with the vanilla setting, (0, 0) for the first 1,500 steps, then transitions to a level-3 perturbation setting for the subsequent 1,500 steps: either required items-only (3, 0), action-only (0, 3), or both (3, Upon this change. the agent is informed of which items' rules are modificd but not what the new rules are, forc- ing it to relearn from experience. As shown in Figure 22] XENON rapidly adapts by re-learning the new depen- dencies and recovering its near-perfect EGA in all three scenarios. In contrast, all baselines fail to adapt effectively. with their performance remaining significantly degraded after the change. Specifically, for the items whose rules are altered, Table shows shows that XENON achieves a perfect re-learning ratio of 1.0 in all scenarios, while all baselines score 0.0 whenever actions are modified.
Table 16: The ratio of correctly learned dependencies among whose rules are dy- namically changed (out of 7 total) by each agent. Columns correspond to the type of ground -tuth rules changed dur- ing learning: requirements only, actions only, or both.
Agent
(3,0)
(0,3)
(3,3)
XENON
1.0
1.0
1.0
SC
0.80
0.0
0.0
ADAM
0.83
0.0
0.0
DECKARD
0.49
0.0
0.0
RAND
0.29
0.0
0.0
K.7 A ABLATION STUDIES FOR LONG-HORZION GOAL PLANNING
Table 17: Ablation experiment results for long- long-horizon goal planning in MineRL. Without Learned Dependency, XENON employs a dependency graph initialized with LLM predictions and human- written examples. Without Action Correction, XENON saves and reuses successful actions in FAM, but it does not utilize the information of failed actions.
Learned Action
CRe
Dependency
Correction
Wood
Stone
Iron
Diamond
Gold
Armor
Redstone
0.54
0.39
0.10
0.26
0.45
0.0
0.0
0.54
0.38
0.09
0.29
0.45
0.0
0.0
0.82
0.69
0.36
0.59
0,69
0.22
0.0
0.82
0.79
0.45
0.59
0.68
0.21
0.0
0.85
0.81
0.46
0.64
0.74
0.28
0.0
To analyze how each of XENON's components contributes to its long-horizon planning, we conducted
an ablation study in MineRL, with results shown in Table 17 The findings first indicate that without accurate dependency knowledge, our action correction using FAM provides significant benefit on its own (row vs. row 2). The most critical component is the learned dependency graph, which dramatically improves success rates across all item groups (row 3). Building this, adding FAM's
46

---

Published as a conference paper at ICLR 2026
action correction further boosts performance, particularly for the Stone and Iron groups where it helps overcome the LLM's flawed action priors (row 4). Finally. Context-aware Reprompting (CRe, Section 4.3) provides an additional performance gain on more challenging late-gan gite- items, such as Iron, Gold, and Armor. This is likely because their longer episode horizons offer more opportunities for CRe rescue stalled controller.
K.8 THE NECESSITY OF KNOWLEDGE CORRECTION EVEN WITH EXTERNAL SOURCES
Even when external source is available to initialize an agent's knowledge, correcting that knowledge from interaction remains essential for dependency and action learning, because such sources can be flawed or outdated. To support this, we evaluate XENON and the baselines in the MC-Text Wer-old environment where each agent's depen-
1.0
XENON
Experienced Iitems Ratio
0.8
ADAM
DECKARD
RAND
0.6
dency graph is initialized from an oracle graph, while the environment's s ground-truth dependency graph is perturbed (perturbation level 3 in 4.. We measure performance as the ratio of the 67 goal items obtained within single episode, We use an intrinsic exploratory item selection method for all agents (i.e., which item each agent chooses on its own to try to obtain next): they choose, among items not yet obtained in the current episode, the one with the fewest attempts so far.
1000 2000
3000
Environment step
Figure 23: Ratio of goal items obtained one MC-TextWorld episode when each agent's dependency graph is ini- tialized from an oracle graph while the environment's ground-truth dependency graph is perturbed. Solid lines denote the mean over 15 runs; shaded areas de- note the standard deviation.
As shown in Figure 23 this experiment demonstrates that, even when an external source is available, (1) interaction experience-base based knowledge correction remains crucial when the external source is mismatched with the environ- ment, and (2) XENON is also applicable and robust this scenario. By continually revising its dependency knowledge, XENON achieves much higher ratio of goal items obtained in an episode than all baselines. In contrast, the baselines either rely on unreliable LLM self-correction (e.g., SC) or do not correct flawed knowledge at all (e.g.. DECKARD, ADAM, RAND), and therefore fail to obtain many goal items. Their performance is especially poor because there are dependencies between goals: for example, when the true required items for stone pickaxe and iron pickaxe are perturbed, the baselines cannot obtain these items and thus cannot obtain other goal items that depend on them.
K.9 SCALABILITY OF DEPENDENCY AND ACTION LEARNING WITH MORE GOALS AND ACTIONS
To evaluate the scalability of XENON's s dependency and action learning, we vary the number of goal items and available actions in the MC-TextWorld environment. For the goal-scaling experiment, increase the number of goals from 67 to 100 and 120 by adding new goal items (see (T the added goals), while keeping the original three actions "mine", "craft", and "smelt" fixed. For the action-scaling experiment, we increase the available actions from 3 to 15, 30, and 45 (e.g., "harvest", "hunt", "place"), while keeping the original 67 goals fixed.
The results in Figure 24sshw that XENON maintains high EGA as both the number of goals and the number of actions grow, although the number of environment steps required for convergence naturally increases. As seen in Figure 24a increasing the number of goals from 67 to 100 and 120 only moderately delays convergence (from around 1,400 to about 2,100 and 2,600 steps). In contrast, Figure 24b shows larger slowdown when increasing the number of actions (from about 1,400 steps with 3 actions to roughly 4,000, 7,000, and 10,000 steps with 15, 30, and 45 actions), which is expected because XENON only revises an item's dependency after all available actions for that item have been classified as empirically invalid by FAM. We believe this convergence speed could be improved with minimal changes, such as by lowering Zo. the failure count threshold for classifying an action as invalid, or by triggering dependency revision once the agent has failed to obtain an item fixed number of times, regardless of which actions were tried in subgoals.
47

---

Published as a conference paper at ICLR 2026
1.0
1.0
0.8
0.8
EGA
EGA
0.4
0.4
of actions: 3
goals:
actions:
0.2
of goals: 100
0.2
of actions:
of goals: 120
of actions: 45
1000
2000
3000
5000
10000
Environment step
Environment step
(a) Effect increasing the number of (b) Effect of increasing the number goals
actions
Figure 24: Scalability of XENON with more goals and actions. EGA environment steps in MC-Tex(World when (a) increasing the number of goal items and (b) increasing the number of available actions. In (a), keep the three actions ("mine", "craft", "smelt") fixed, while in (b) keep the 67 goal items fixed. Solid lines denote the mean over 15 runs; shaded areas denote the standard deviation.
K.10 ABLATION ON ACTION SELECTION METHODS FOR MAKING SUBGOALS
Random+ FAM
LLM
SC
XENON
1.0
Environment Steps to Success
300
0.8
Success Rate
200
0.6
150
0.4
100
0.2
50
0.0
15
30
45
15
30
actions
actions
(a) Success
(b) Steps success (lower is better)
Figure 25: Ablation on action selection methods for subgoal construction. We evaluate different action selection methods for solving long-horizon goals given an oracle dependency graph, as the size of the available action set increases. (a) Success rate and (b) number of environment steps per successful episode. Note that in (a), the curves for LLM and SC overlap at 0.0 because they fail on all episodes, and in (b), they are omitted since they never succeed.
We find that, while LLMs can principle accelerate the search for valid actions, they do so effectively only when their flawed knowledge is corrected algorithnically. To support this, we study how different action selection methods for subgoal construction affect performance on long-horizon goals. this ablation, the agent is given oracle dependency graph and long- hong-horizon goal, and only needs to output one valid action from the available actions for each subgoal item to achieve that goal. Each episode specifies single goal item, and it is counted successful if the agent obtains this item within 300 environment steps in MC-TextWorld. To study scalability with respect to the size of the available action set, vary the number of actions as 3, 15, 30, and 45 by gradually adding actions such as "harvest" and "hunt" to the original three actions ("mine"" "craft", "smelt").
Methods and metrics. We compare five action selection methods: Random+FAM (which randomly samples from available actions that have not yet repeatedly failed and reuses past successful actions),
48

---

Published as a conference paper at ICLR 2026
XENON
SC
ADAM
DECKARD
RAND
1.0
1.0
0.8
0.8
EGA
0.6
0.6
0.2
0.2
# of provided human-written plans
# of provided human-written plans
(a) Planner LLM size: 4B
(b) Planner LLM size: 7B
Figure 26: Effeec of planner LLM size and initial dependency graph quality in dependency and action learning. The plots show EGA after 3,000 enviromment steps of dependency and action learning MC-TextWorld, obtained by varying the planner L.IM size and the amount of correct knowledge in the initial dependency graph (controlled by the number of provided human-writter plans). In (a), the planner is Phi-4-mini (4B) (Microsoft et al. 2025): in (b), the planner is Qwen2.5- VL-7B (7B) (Bai et al. 2025)
UCB, LLM without memory, LLM self-correction (SC), and XENON, which combines an LLM with FAM. We report the average success rate and the average number of environment steps to success over 20 runs per goal item, where goal items are drawn from the Redstone group.
As shown in Figure 25 among the three -LMeddsed methods (LLM, SC, XENON), only XENON- which corrects the LLM's action knowledge by removing repeatedly failed actions from the set of candidate actions the LLM is allowed to select-sollvss long-horizon goals reliably, maintaining success rate of 1.0 and requiring roughly 50 environment steps across all sizes of the available action set. In contrast, LLM and SC never succeed in any episode, because they keep selecting incorrect actions for subgoal items (e.g., redstone), and therefore perform worse than the non-LLM baselines, Random+FAM and UCB. Random+FAM and UCB perform well when the number of available actions is small, but become increasingly slow and unreliable as the number of actions grows, often failing to reach the goal within the episode horizon.
K.11 ROBUSTNESS TO SMALLER PLANNER LLMS AND LIMITED INITIAL KNOWLEDGE
We further evaluate robustness of XENON and the baselines to limited prior knowledge by measuring dependency and action learning in MC-TextWorld while (i) varying the planner LLM size and (ii) degrading the quality of the initial dependency graph. For the planner LLM, we compare 7B model (Qwen2.5- VL-7B (Bai et al. 2025)) )) against 4B model (Phi-4-mini (Microsoft al. 2025); )) for the initial graph quality, we vary the number of provided human-written plans used to initialize the graph from three ("craft fronssword", "mine diamond"' "craft
to one ("craft iron_ rron_wword").
As shown in Figure 26 XENON remains robust across all these settings: its EGA stays near- pear-perfect even with the smaller 4B planner and the weakest initial graph, indicating that leveraging experiences can quickly compensate for weak priors. In contrast, baselines that rely LLM self-correction (SC) or that strongly depend on the LLM or initial graph (ADAM, DECKARD) suffer substantial drops in EGA as the planner LLM becomes smaller and the initial graph contains less correct prior knowledge. This suggests that, in our setting, algorithmic knowledge correction is more critical than scaling up the planner L.MM richer initial human-provin knowledge.
49

---

Published as a conference paper at ICLR 2026
K.12 FULL RESULTS ON THE LONG-HORIZON TASKS BENCHMARK
In this section, we report XENON's performance on each goal within the long-horizon tasks bench- mark, detailing metrics such the goal item, number of sub-goals, success rate (SR), and evaluation episodes.
Table 18 and 19 present XENON's results when utilizing the dependency graph learned through 400 episodes exploration. Conversely, Table and display XENON*S performance, which leverages oracle dependency graph.
Table 18: The results of XENON (with dependency graph learned via exploration across 400 episodes) on the Wood group, Stone group, and Iron group. SR denotes success rate.
Group
Goal
Sub-Goal Num.
SR
Eval Episodes
bowl
4
92.68
chest
4
95.24
42
crafting_tabe table
3
95.83
ladder stick
5
0.00
3
95.45
Wood
wooden_ axe
5
90.91
44
wooden_hoe
5
95.35
43
wooden_ppckaxe
5
93.02
43
wooden_shovel
5
93.75
48
wooden_sword
5
95.35
43
charcoal
8
87.50
40
furnace
7
88.10
42
smoker
8
0.00
47
stone_ _xe
7
97.78
45
Stone
stone_hoe
7
90.70
43
(lone_pickan)
7
95.45
44
shove_shovel
7
89.58
48
stone_sword
7
89.80
49
torch
7
93.02
43
blast furnace
13
0.00
42
bucket
11
0.00
47
chain
12
0.00
42
hopper
12
0.00
iron_axe
11 75.56
iron_bart
11 80.43
46
iron hoe
11 89.13
46
iron_ con_nugget
11 79.55
44
Iron
iron_pickaux
11 77.08
iron_shovel
11 75.56
45
iron_sword
11
84.78
46
rail
11 0.00
44
shears
11 0.00
43
smithing_tabbe table
11
93.75
48
stonecutter
12
0.00
43
tripwire hook
hook
11
78.43
51
50

---

Published as a conference paper at ICLR 2026
Table 19: The results of XENON (with dependeney graph learned via exploration across 400 episodes) on the Gold group. Diamond group, Redstone group, and Armor group. SR denotes success rate.
Group
Goal Item
Sub Goal Num.
SR
Eval Episodes
gold_ingot
13
76.92
52
golden_axe
14
72.00
50
golden_hox
14
66.67
48
Gold
golden_pickaxe
14
76.00
50
golden shovel
14
71.74
46
golden_sword
14
78.26
46
diamond
87.76
49
diamond axe
13
72.55
51
diamond_hoe
13
63.79
58
Diamond
diamond_pickee
13
60.71
56
@lamond_shovee
13
84.31
51
diamond_sworf
13
76.79
56
jukebox
13
0.00
48
activator rail compass
0.00
13
0.00
3
dropper note block
13
0.00
3
Redstone
13
0.00
4
piston
13
0.00
12
redstone_ coastone_torchh
13
0.00
19
diamond boots
13
64.29
42
diamond_chestpleee
13
0.00
diamond helmet
13
67.50
40
diagond_s
13
0.00
37
golden boots
14
69.23
39
salden_chestplate
14
0.00
39
Armor
golden helmet
14
60.53
38
golden_legging iron boots iron con__chsstplate
14
0.00
38
11
94.44
54
0.00
iron helmet
11
4.26
47
cron_leggings
11
0.00
41
shield
11
0.00
46
K.13 EXPERIMENTS COMPUTE RESOURCES
All experiments were conducted on internal computing cluster equipped with RTX3090, A5000, and A6000 GPUs. We report the total aggregated compute time from running multiple parallel exper- iments. For the dependency learning, exploration across 400 episodes in the MineRL environment, the total compute time was 24 days. The evaluation on the long-horizon tasks benchmark in the MineRL environment required a total of 34 days of compute. Experiments within the MC-TextWorld environment for dependency learning utilized total of 3 days of compute. We note that these values represent aggregated compute time, and the actual wall-clock time for individual experiments was significantly shorter due parallelization.
51

---

Published as a conference paper at ICLR 2026
Table 20: The results XENON* (with oracle dependency graph) on the Wood group, Stone group, and Iron group. SR denotes success rate.
Group
Goal Item
Sub-Goal Num.
SR
Eval Episodes
bowl
4
94.55
chest
4
94.74
57
crafting_table
3
94.83
58
ladder stick
5
94.74
57
3
95.08
61
Wood
wooden axe
5
94.64
56
wooden_hop
5
94.83
58
wooden_pickaxe
5
98.33
60
wooden_shovel
5
96.49
57
wooden_sword
5
94.83
58
charcoal
8
92.68
41
furnace
7
90.00
40
smoker
8
87.50
40
stone_asd axe
7
95.12
41
Stone
stone_hoe
7
94.87
39
stone_pickaxe
7
94.87
39
stone_shovel
7
94.87
39
stone_sword
7
92.11
38
torch
7
92.50
40
blast_ furnace
13
82.22
45
bucket
11
89.47
chain
12
83.33
36
hopper
12
77.78
36
iron_axe
11
82.50
40
iron_bars
11
85.29
34
iron_hoe
11
75.68
37
iron_nugget
11
84.78
46
Tron
iron_pickaxe
11
83.33
42
iron tron_shovel
11
78.38
37
iron_sword
11
85.42
48
rail
11
80.56
36
shears
11
82.05
39
smithing_tabe table
11
83.78
37
stonecutter
12
86.84
38
tripwire hook
hook
11
91.18
34
L THE USE OF LARGE LANGUAGE MODELS (LLMs)
In preparing this manuscript, we used an L.M as a writing assistant to improve the text. Its role included refining grammar and phrasing, suggesting clearer sentence structures, and maintaining consistent academic tone. All technical contributions, experimental designs, and final claims were developed by the human authors, who thoroughly reviewed and take full responsibility for the paper's content.
52

---

Published as a conference paper at ICLR 2026
Table 21: The results of XENON" (with oracle dependency graph) on the Gold group, Diamond group, Redstone group, and Armor group. SR denotes success rate.
Group
Goal Item
Sub Goal Num.
SR
Eval Episodes
gold_ingot
13
78.38
37
golden_ace axe
14
65.12
43
golden_ho hoe
14
70.27
37
Gold
-ickaxe_ golden_shovel
14
75.00
36
14
78.38
37
diamond diamond axe diamond_hoe diamond pickaxe diamond_ _ssovel
71.79
39
13
70.00
40
13
85.29
34
Diamond
_ickaee
13
72.09
43
13
76.19
42
_ _sword jukebox
13
80.56
36
13
69.77
43
activator_ran rail compass
67.39
13
70.00
40
dropper
13
75.00
40
Redstone
note block
13
89.19
37
piston
13
65.79
38
redstone_tore torch
13
84.85
33
diamond boots
13
60.78
51
diamond_chestppee
20.00
diamond helmet
13
71.79
39
diamond_leggings
13
33.33
39
_ boots
14
75.00
40
14
0.00
36
Armor
golden helmet
14
54.05
37
golden_ Leeginnl iron boots iron con__chsttllaee
14
0.00)
38
11
93.62
47
97.50
iron rro__helmet
11
86.36
44
tron_legging!
11
97.50
40
shield
11
97.62
42
53


Reviews:
[{"review_id": "DmRYCr4GaG", "reviewer": "Reviewer_VSc5", "summary": "The paper introduces XENON, an agent that provides a training-free solution to revise knowledge algorithmically from experience without changing the parameters of the LLM. This addresses hallucinations caused by flawed priors inherent in LLMs. Specifically, the paper models knowledge as a directed acyclic graph, where nodes represent Minecraft items and directed edges represent dependence and actions. The model initially uses an LLM to distill and initialize an imperfect Dependency Graph, which is then adaptively revised using the RevisionByAnalogy technique. If a dependency fails repeatedly during rollouts, it is deleted, while for less-tried items, a similar, previously obtained item is sampled to replace the original dependency. Action selection is optimized using Failure-aware Action Memory (FAM) through an elimination method. \nThe agent is validated using 7B-qwen2.5-vl in three different environments—MineRL, Mineflayer, and MC-TextWorld. The results show that XENON is uniquely robust to LLM hallucinations and adapts to different control policies, achieving state-of-the-art performance in the same domain.", "questions": "1. In the MineRL environment, approximately how many episodes are required for the dependency-action graph to converge? Additionally, while the current experiments focus on 67 goals with a limited number of items, how does the method scale when the item space becomes significantly larger? A brief comment on scalability or computational complexity would be valuable for understanding the broader applicability of XENON.", "limitations": "", "rating": 4, "confidence": 4, "soundness": 2, "presentation": 2, "contribution": 2, "strengths": "- The paper proposes a novel algorithmic approach for planning that does not require retraining LLMs, offering an efficient solution to improve LLMs’ knowledge representation from experience.\n- The ablation study clearly demonstrates that Adaptive Dependency Graph (ADG) and FAM are highly robust to initial errors. They effectively recover the correct dependency graph despite the presence of flawed priors. Moreover, no additional LLMs are required to generate these priors, which greatly enhances the efficiency of the ablation. The separate analysis of ADG and FAM’s impacts aids in understanding their individual contributions. This constitutes a well-designed experiment to validate the framework.\n- The visual quality of the figures is commendable. The graphical representations are intuitive and help readers easily grasp the experimental setup and results", "weaknesses": "1. The paper states (Line 126) that knowledge is modeled as a directed acyclic graph. However, it is unclear how the system detects and resolves cyclic structures that may arise during initialization ( e.g. when a wooden axe is required to obtain logs, logs produce planks, and planks are used to craft the axe). I suggest clarifying whether cycles are possible in practice and, if so, how they are algorithmically identified and dismantled.\n2. In Line 212, the method refers to selecting required items for less-tried nodes based on similarity. However, It seems that the notion of “similarity” is not formally defined in the current draft. \n3. The ADG is a relatively complex algorithm, and presenting it only with diagrams results in high information density. It is recommended to include pseudocode for better clarity and reproducibility.\n4. The paper discusses both the control policy and the XENON framework in detail; however, it lacks experimental analysis regarding the role of the LLM itself. If the initial dependency graph were directly provided without using an LLM, and actions were sampled using MCTS rather than LLM-based selection, would the agent still be able to complete the planning task? What is the essential contribution of the LLM within XENON? I believe an ablation study in this regard would be valuable.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "fSybLxgUv2", "reviewer": "Reviewer_JH8W", "summary": "This paper proposes XENON, a method for learning Minecraft recipes and using this learned knowledge to solve Minecraft problems. XENON uses an LLM to generate an initial set of recipes (the graph). Then, it refines it by trying to use it and observing if it works or not. If it does not work, XENON tries to modify the recipe. After sufficient amount of tries, XENON will give up and state that the item is an hallucination. The author evaluate this on a standard set of Minecraft tasks from the MineRL benchmark and a text version of Minecraft.", "questions": "1.\tLines 127-128: It seems your graph does not support cases where crafting N items of one type create M>1 items of another type, since you only have q for the quantity of the resource, but no parameter for the quantity of the resulting items. For example, consider the case where CRAFT on two logs create four sticks. \n2.\tLine 138: When the controller executions these subgoals” – how does the controller do this? \n3.\tWere the parameters of XENON tuned differently for each test goal?\n4.\tWhat is a “context-aware reprompting” technique mentioned in line 268?\n\nLine 22: What makes an LLM be “open-weight”?\nLines 84-90: The first and second contribution are actually only one contribution. What is the difference between them? (one proposes XENON, the other explains how XENON works…)\nLine 104: What is a “… robust action correlation”?\nLine 114: What is a “parametric knowledge”?\nThe EGA metric: isn’t it just the mean over the metric you mentioned in (1)? Why do we need a new name for this metric? (line 288)", "limitations": "", "rating": 4, "confidence": 3, "soundness": 3, "presentation": 3, "contribution": 2, "strengths": "1.\tLearning the recipes by interacting with the environment makes sense and I appreciate its integration with the LLM agent. \n2.\tThe results show nice improvements over the ablation and baseline. \n3.\tThe solution is designed to handle execution delays", "weaknesses": "1.\tThe paper is not sufficiently self-contained. In particular, there authors assume the reader knows how DECKARD works (e.g.,in line 172). Note that DECKARD was only published in Arxiv and it not well known. \n2.\tI am not convinced about the generality of the approach because it relies on hyper parameters that I guess are tuned for this domain. \n3.\tSome details are not clear, and there are quite a few design choices that seem arbitrary to me. See below in the list of questions.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "WWIqpXIbti", "reviewer": "Reviewer_DZb7", "summary": "The paper proposes XENON, an LLM-based agent that algorithmically corrects its external planning knowledge from interaction experience, aiming to overcome flawed LLM priors and sparse feedback in long-horizon Minecraft tasks. Two key components drive the method: (1) an Adaptive Dependency Graph (ADG) that initializes a dependency graph using an LLM and then revises it from successful trajectories via a procedure called RevisionByAnalogy; and (2) a Failure-aware Action Memory (FAM) that maintains empirical success/failure counts per (item, action) to prune invalid actions, explore under-tried ones, and trigger ADG revisions when all actions for an item are deemed invalid. The agent is evaluated across MineRL and Mineflayer. Experimental results show that XENON outperforms other baselines. With a 7B open-weight planner (Qwen2.5-VL-7B), it attains competitive or superior SR compared with agents that rely on larger proprietary models.", "questions": "Table 3 shows that some baselines, such as Optimus-1, outperform XENON on certain simple task groups, while XENON significantly outperforms the baseline on difficult task groups like Diamond. What causes this phenomenon? Are the experimental settings consistent?", "limitations": "", "rating": 6, "confidence": 5, "soundness": 2, "presentation": 3, "contribution": 3, "strengths": "1. The paper tackles a real failure mode: LLM priors over item dependencies and actions are brittle and hard to self-correct with only binary feedback. Treating the LLM as a planner while moving correction into algorithmic external memory is a crisp, testable design choice.\n\n2. Using Qwen2.5-VL-7B, XENON outperforms or rivals methods using GPT-4/4V on several long-horizon task groups, particularly when oracle dependencies are provided. It still performs strongly with learned dependencies on challenging tasks.\n\n3. This paper provides a detailed account of the motivation and methodology, along with comprehensive implementation details and experimental setup, making it easy to follow.", "weaknesses": "1. The proposed method is simple and intuitive, akin to prompting an LLM to correct memory and graphs, lacking technical innovation.\n\n2. The procedure references “similar, successfully obtained items” but the similarity function, features, and retrieval specifics are not fully spelled out in the main text (embedding choice, distance metric, negatives, and sensitivity). This matters because ADG’s replacement set can systematically bias learning if similarity is noisy.\n\n3. The design hinges on $c_0$, $x_0$, $a_i$, $a_s$. While intuitively motivated (hallucination handling, controller tolerance), the paper does not present comprehensive ablations on these hyperparameters or learning stability across seeds, leaving robustness to tuning somewhat unclear.\n\n4. The approach is tested only in Minecraft variants; claims about “practical embodied agents” would be stronger with at least one additional domain (e.g., household manipulation or web-based embodied tasks) or a clearer argument for portability.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}, {"review_id": "R68kXQBqGw", "reviewer": "Reviewer_S6YL", "summary": "This paper presents XENON (eXpErience-based kNOwledge correctioN), an LLM-based planning framework for embodied agents in long-horizon environments such as Minecraft. The paper argues that LLMs often carry flawed priors about item dependencies and actions, and fail to self-correct even with feedback. XENON introduces two algorithmic mechanisms—Adaptive Dependency Graph (ADG) for dependency correction and Failure-aware Action Memory (FAM) for action correction—allowing the agent to revise its external knowledge from binary success/failure feedback. Experiments in several Minecraft environments demonstrate that XENON achieves strong performance and robustness, outperforming prior agents including those relying on larger proprietary LLMs.", "questions": "see weakness", "limitations": "", "rating": 4, "confidence": 3, "soundness": 2, "presentation": 3, "contribution": 2, "strengths": "1. The paper is clearly written and easy to follow. The modular decomposition into ADG and FAM makes the system architecture understandable and well-motivated.\n\n2. The implementation and experimental setup are extensive. The authors carefully evaluate across multiple environments (MineRL, Mineflayer, MC-TextWorld) and provide comprehensive ablations, demonstrating the effectiveness of each module.\n\n3. The work highlights an important issue — how to make lightweight LLM-based agents robust to flawed priors and minimal feedback. This direction is relevant to building scalable, open-weight embodied agents.", "weaknesses": "1. The core contribution lies more in system design. The proposed ADG and FAM modules are essentially heuristic procedures (revision by analogy, empirical counting of failed/successful actions) that combine ideas from prior memory-based and failure-driven learning frameworks (e.g., Reflexion, DECKARD, ADAM).\nWhile the integration is clean, the novelty at the algorithmic level is modest.\n\n2. The evaluation is entirely confined to Minecraft-like environments, where planning graphs and item dependencies are discrete and well-defined. It remains unclear whether the proposed mechanisms generalize to less structured or continuous domains (e.g., physical robot control, household tasks).\n\n3. Although ablation studies are included, some aspects (e.g., sensitivity to hyperparameters like $c_0$, $\\alpha_i$, $x_0$) are not deeply explored. It is also unclear how well the algorithm scales when the number of items or actions grows substantially.\n\n4. While the paper argues for learning dependencies purely from interaction, it does not explain why using external structured sources such as Minecraft Wiki is undesirable or infeasible. Since such knowledge bases can already provide accurate dependency graphs, the motivation for building and correcting knowledge from scratch appears weak or artificially constrained. A discussion comparing learning from experience vs. retrieving from knowledge bases would strengthen the motivation.", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "extra_scores": {}}]

Author rebuttal:

Decision: Accept (Poster)