CoNavBench: Collaborative Long-Horizon Vision-Language Navigation Benchmark
Authors: Tianhang Wang
Xinhai Li
Fan Lu
Tianshi Gong
Jiankun Dong
Weiyi Xue
Sanqing Qu
Chenjia Bai
Guang Chen
Venue: ICLR 2026 Poster (2026)
Keywords: collaborative vision-and-language navigation; LLM agents; benchmark
Primary area: datasets and benchmarks

Abstract: Vision-and-Language Navigation (VLN) primarily focuses on a single-agent-centric approach that executes human instructions step-by-step. In real environments with high demand or parallel workflows, collaboration VLN offers distinct benefits including shorter makespan and greater robustness through parallelism and role specialization. Collaboration VLN also brings new challenges including congestion, handoff errors, and rendezvous timing, which single-agent formulations overlook. Current datasets and protocols remain single-agent centered, which hides opportunities for assistance and ignores inter-robot interference. We fill this gap with Collaborative Long-Horizon VLN benchmark (\textbf{CoNavBench}), consisting of 4048 single and collaborative episodes with graph-level annotations and a collaboration type taxonomy that controls handoff styles and rendezvous patterns. To generate and evaluate at scale, we build \textbf{NavCraft}, an automated graph-grounded data generation platform. A two-stage hierarchical agent first produces a long-horizon base mission for the primary robot and then instantiates helper robots, allocates subgoals, and specifies validated handoffs and rendezvous. The agents operate with a scene graph in the loop derived from Habitat-Sim, which enables reachability checks, travel time, and interference assessment, and iterative schedule repair via an efficiency tool library. As a reference, we provide a collaborative baseline based on a finetuned Qwen2.5-VL-3B. Trained with CoNavBench, collaborative policies reduce makespan and improve reliability over strong single robot counterparts, yielding \textbf{18.11\%} step level success. Anonymous Website: https://navcraft.github.io.

Published as a conference paper at ICLR 2026
CONAVBENCH: COLLABORATIVE LONG-HORIZON VISION-LANGUAGE NAVIGATION BENCHMARK
Tianhang Wangh2 Xinhai Li', Fan Lu', Tiansii Gong', Jiankun Dong',
Weiyi Xue', Sanqing Qu', Chenjia Bai*,
Guang Chen 2.44, 7
TTongii University *Shanghai Innovation Institution 'Institute of Artificial Intelligence,
China Telecom Shanghai Westwell Technology Co., Ltd
Collabrative tive Navigation Subtasks x
showers, please take the towel in bedroom to both cablnet bethtoom.
The user just requested towel for their shower.
Copy. I'm closest. find towel and stage the litchon counter for you
Stagee
Siaaee
Perfect! 11l get the hot water ready everything's set the arrives.
Stage
Waiting long...
less time, more things!
No parallel working
Stage
Stage
Stage
Stage
Stage 2
Stage 3
Tomeline
Pre Stage
Stage
Timeline
(a) Single Robot Navigation
(b) Collabrative Robots Navigation
NavCraft
Comparison of single-robot and collaborative multi-robot navigation. (a) In the single- robot case, the agent must complete all stages sequentially, resulting in long delays and idle waiting. (b) In the collaborative case, subtasks are distributed across robots and executed in parallel, reducing overall completion time and enabling the team accomplish more within the same horizon.
Figure I:
ABSTRACT
Lisinnaand-Language Navigation (VLN) primarily focuses on a single-agent- centric approach that executes human instructions step-by-step. In real environ- ments with high demand or parallel workflows, collaboration VINN offers distinct benefits including shorter makespan and greater robustness through parallelism and role specialization. Collaboration VLN also brings new challenges includ- ing congestion, handoff errors, and rendezvous timing, which single-agent for- mulations overlook. Current datasets and protocols remain single-agent centered, which hides opportunities for assistance and ignores inter-robot interference. We fill this gap with Collaborative Long-Horizas VLN benchmark (CoNavBench), consisting of 4048 single and collaborative episodes with graph-level annotations and collaboration type taxonomy that controls handoff styles and rendezvous patterns. To generate and evaluate scale, we build NavCraft, an automated data generation platform. A two-stage hierarchical agent first produces long- hang-hoizoon base mission for the primary robot and then instantiates helper robots, allocates subgoals, and specifies validated handoffs and rendezvous. The agents operate with a scene graph in the loop derived from Habitat-Sim. which enables reachability checks, travel time, and interference assessment, and iterative schedule repair via an efficiency tool library. As reference, we provide a collabo- rative baseline based on a finetuned Qwen2.5-Vi VL-33B. Trained with Bench, collaborative policies reduce makespan and improve reliability over strong single robot counterparts, yielding 18.11 % step level success. CenayBench
Corresponding author. Email: guangchen wrangchheettnggi.dddu..m Project leader, supervised the work and defined the conceptualization.

---

Published as a conference paper at ICLR 2026
Table I: Comparison to VLN benchmarks. * The scale of our released benchmark is 4048, however NavCraft is able generate unlimited data to be tested.
Single Task
Collab Task
Total Task
Benchmark
Simulator
Task Type
Num
Avg. Gain
R2R
Matterport3D
Step-by-step Nav
21567
21567
REVERIE
Matterport3D
Obj Nav
21702
21702
VLN-CE
Habitat
Step-by-step Nav
4475
4475
FAO
Matterport3D
Obj Nav
3848
3848
Behavior- 1k
OmniGibson
Complex Housework
1000
1000
IVLN
MaDtHabitat
Iterative VLN
789
789
Beat-Bench
Habitat
Iterative VLN
725360
725360
LHPR- -
Habitat
Multi-stage VLN
3260
3260
CoNayBench
Habitat
Multi-agent VLN
2436*
1612'
21.08%
4048"
INTRODUCTION
Biioo-anddLanggaaee Navigation (VLN) (Anderson et al. 2018: Thomason et al. 2019 Hong et al.) 2020) has advanced from stepwise waypoint following to long- hong-horizon, multi-stage settings that de- mand persistent reasoning and continual re- re-planning (Khamna et al. 2024). However, most formula- tions and datasets still assume single robot agent, suppressing parallelism and ignoring inter-robot interference. In contrast, collaborative VLN views multiple robots as a coordinated team that ex- ploits parallelism, anticipates and mitigates inter-robot interference, and optimizes wall-clock time and energy, which are central to user experience in real deployments (Puig et al.) 2023).
To close this gap, introduce Collaborative Long-Horizen VLN benchmark CoNavBench, to knowledge the first systematic benchmark for collaborative VLN. CoNavBench comprises 4048 single- and multi-robot episodes together with a collaboration type laxonomy controlling handoff styles and rendezvous patterns. Each episode pairs long- long-horizon instructions with graph-level anno- tations, enabling efficient metries including task success, makespan, and interference time. Given long-range instruction, team must decompose the mission, assign roles, and coordinate handoffs or rendezvous to minimize time while avoiding congestion.
We identify three escalating challenges for collaborative VLN: (i) Cooperation-ready task synthe- sis: constructing long- morizoorzzon single-robot base tasks with explicit stage boundaries and cross-room dependencies that create genuine opportunities for assistance (Xu et al.) 2022); (ii) Conflict-free team scheduling: lifting a base task into multi-robot schedule with role assignments, temporal ordering, and rendezvous; and (iii) In-loop efficiency optimization: given feasible schedule, esti- mating team-level time, anticipating bottlenecks, and issuing actionable guidance.
To address the above challenges, present NavCraft, graph-grounded generation platform for CoNavBench. NavCraft first constructs a semantically augmented scene graph from Habitat- Sim (Savva et al.] 2019) the planning blueprint (Rana al. (023). Each node is labeled via hier- archical clustering to assign room categories and functional properties, and edges encode topology and traversability. Over this spatially grounded representation, two-stage hierarchical agent oper- ates: NavCraft-S produces a long-horizon single-robot base plan with cross-room scope and explicit stage structure, and NavCraft-C lifts into a collaborative schedule by instantiating helper robots, allocating subgoals, and validating handoffs and rendezvous. Unlike text-only prompting (White) al. 2023), which lacks spatial grounding, and asset-speeific simulators (Yang et al. 2022). which limit throughput and versatility. NavCraft enables context-ave -wware task generation conditioned on user profiles (Wang et al. (025b) and robot capabilities, improving diversity and schedule validity.
We further propose on-graph efficiency tool library that unifies validation and guidance within the scene-graph loop. The library translates language intents into numerical constraints over dis- tances, widths, occlusions, and occupancy; verifies reachability, interference, and estimates time. then issues recommendations for subgoal allocation, rendezvous timing, helper deployment, and route revision. The agent consumes these recommendations in closed loop, preserving accuracy while avoiding full-physics rollouts at each step (Wang et al. 2025a).
Finally, provide reference stack coupling Qwen-series LLMs (Bai al. 2025 with memory- aware mechanism (Song et al.) 2025). Policies trained on CoNavBench achieve 18.11% % step level success than single-robot, indicating practical path toward deployable collaborative navigation.
2

---

Published as a conference paper at ICLR 2026
Electronic Devices
Kichen Dining
Storge Bathoom
Safety Sensors
Organ.
Hygiane 7%
Textiles Household
62-
Protable Furniture 28%
CaNavB
Lightning Electrical 10%
02-
Decor
Art
Personal Leisuro
Prstable
Pensoual
Lightning
Textiles
Bathrron
Sterpe
Kiches Donung
Blecwosic
Safety
17%
Hoosehold
Higgenee
Organ.
Devices
Sensers
(a) Collahrative efficient gains va. category violin distribution
(b) Category and collabontiive type distribution
Figure 2: CoNavBench benchmark. (a) Collaborative efficiency by category. Violin plots show the distribution of category-wise efficiency gain over a single-robot baseline, yielding an average gain of 20% across categories. (b) Category and collaboration-tyee distribution. The benchmark covers a broad and balanced set of houschold target-object categories (outer ring) and two collaboration types (inner ring), evidencing rich object diversity that supports generalizable evaluation.
2 RELATED WORK
Vision-and-Lange Language Navigation Embodied Vision-and-Language Navigation (VLN) studies language-conditiones navigation in complex environments. Methods are typically studied in dis- crete and continuous settings. In discrete VLN (Chen et al. 2022 Zhou et al. 2023). agents move on a fixed panoramic graph of predefined nodes. The abstraction emphasizes high-level decisions while masking metric geometry and collisions. Recent work introduces LLM-augmented planners with retrieval-augeee -urgeval-augmennee memory to improve instruction parsing and subgoal proposal (Chen et al., 2024 ZZheng al., 2024), yet these systems still assume oracle connectivity and lack low-level feasibility checks. In continuous environments (Dong et al. 2025). many approaches pretrain way- point predictors propose candidate positions for high-level planning (Qiao
2025b) Shh al., alternatives re- duce this reliance: a high-level planner performs embodied plamning with a slow/fast context (Wei) et al. 2025), and low-level controller utilizes diffusion-polic (Cai et al., (025) for local motion, improving responsiveness without scene-specific priors. However, across both settings, systems and benchmarks remain predominantly single-agent, with limited modeling of collaboration.
2025). but such models often overfit and generalize poorly. End-to-ens dual-
Benchmark for Vision-and-Language Navigation Progress in VLN has been driven by datasets QQao et 2025a) that steadily raise task complexity and evaluation fidelity. Early datasets, such as R2R (Anderson al., 2018) and R4R (Jain et al.] (019),, study step-by-step instruction following along predefined panoramic trajectories. VLN-CE (Krantz al. 2020) shifts to contin- wous control in photorealistic simulators, emphasizing perception and low-level decision making. More recent datasets, including CVDN (Thomason al. 2019), REVERIE (Qi et al.. 2019). and SOON (Zhu et al.] 2021), introduce dialogue history. object-centric grounding, and complex in- struction comprehension. OVMM (Yenamandra et al. 2023) and Behavior- IK (Li et al. (0022) cou- ple navigation with manipulation and interaction to approximate extended real-world workflows. IVLN (Krantz et al. 2022) and GOAT-Bench (Khanna al. 2024) enable sequential multi-episode navigation with memory across independent goals, and LHPR-VI VLN (Song et al.) (025) targets long- horizon planning with multi- stage subtasks in complex indoor environments. Despite this progress, existing benchmarks remain single-agent and lack collaboration primitives (Wang et al. (023a), which are necessary to study Collaborative VIN with multiple agents subtasks in highly complex environments. This gap motivates our collaborative long-horizon benchmark and platform.
LLM Agents for Vision-and -aaeo-nnn----nggnggn Language Navigation LLM agents are widely used as policies in in- teractive domains such as the Web (Chae et al. 20244, games (Hu et al., 2024a), robotics (Zitkovich et al. 2023 Wang et al. 2024b Cheng et al. 2025; Jing et al. 2025). and design (Hu et al., 2024b), where they parse instructions, perceive scenes, and invoke tools. In VLN, these agents typically serve as navigators, grounding observations to produce subgoals or actions. Representative exam- ples include VELMA (Schumann et al. 2023 in Street- View and indoor planners such Nav-
3

---

Published as a conference paper at ICLR 2026
Scene Pools
(a) GS-aware Scene Graph
Efficient Plans
Simudation
Region Cluster
NavCraft-C
Real World
CoT
Suitable Relay Zones
NavCraft-S
(c) NavCraft- Agent
Multi-agent Complex Insturction
User Profile
Task Instruction: Robot 1: Take the picture from cabinet in Hall to the door Laundry Room. Robot Take the plcture
the cabinet Hall.
Cross Embodied
Step-by-step Insturction
Instruction Robot room, turn right at the doorway Into the living room, and then move forward towards the cabinet, Robot 2: Move forward through the room towards the picture, (d) Data record, split trajectory and label
forward through the
View Height
Move
Work Abiliry:
T2E
T2E
Speed
Agent Start O End region
O
Target
(b) NavCraft-S Agent
Figure 3: NavCraft pipeline for CoNavBench benchmark data generation and scheduling.
iLLM Zheng et al. 2023) via prompts (Saravia 2022 These systems single-robot and evaluated zero-shot or with fine-tuning on existing datasets. However, prior work treats the agent as navigator (Wang al. 2024a) rather than generator. Our departure is to utilize the agent data generation and scheduling engine for CoNavBench NavCraft's hierarchical agent synthesizes cooperation-ready long-horizon tasks, allocates roles, and produces team-aware schedules.
PLATFORM, BENCHMARK AND METRICS
We introduce NavCraft, genzratienrtnnnn platform tailored for Collaborative VLN. Using NavCraft, we construct the CoNavBench benchmark, which enables systematic evaluation of models on long- horizon, multi-agent planning and execution within vision-language navigation.
3.1 NAVCRAFT
3.1.1 SCENE GRAPH GENERATION
We annotate each node Habitat connectivity graph G (V, F)) (Wang et al. 2023b with region types to obtain semantic-awan graph. Each node i V stores 3D position p: [x,, Bi, 2i] And we also know each region object m'ss 3D position X. = [mmm Vm Zm,] and region type r(m).
Instance Proximal Voting We seed each node by object-centric k-NN plurality to preserve coarse- grained cues. For node i, we search the & nearest annotated objects on the ground plane and assign the plurality region:
(i = arg topk [lp, -xm 122,
P!0) = max
Σ
1/r(m) = c).
MEM
meNe(1
where M is the set of all neighborhood objects, and k=3 by default.
Neighborhood Consensus After seeding node labels with IPV, observe occasional isolated mis- labels near narrow passages (c.g., doorways), where object-centric votes can flip a single node at region boundaries. To address this, apply targeted, local correction. A node is eligible for relabeling only if two guards hold simultaneously: (i) its graph degree modest, & deg(i) S 4,
and (ii) its provisional label e!0) disagrees with every neighbor C(i) in G. If both conditions
4

---

Published as a conference paper at ICLR 2026
0, 1, 6- 6 Bedroom
-
Bathroom
5 Kitchen
7- Tie 8 L-Livnng room
(a) Instance Proximal Voting (b) Neighborhood Consesus
(c) Contiguity Restoration
(d) Top-down View
Figure 4: Visualization of the scene graph generation pipeline.
met, the node adopts the label of the nearest labeled neighbor on the navigation plane:
(0)
if S deg(i) < 4 and Vj E C(i): 1 f!))
arg min P 1/ JEC(I)
otherwise.
Contiguity Restoration After IPV and NC seeding, we still observe mislabeled regions caused by structural barriers such walls, which fragment class into multiple small, fractured islands. To restore semantic contiguity without excessive smoothing, we operate at the connected-componen
level. For each class c, form the induced subgraph Ge Glf p(()) =}] and keep its largest component and process any remaining component C as follows. touches no other class, delete it; otherwise, reassign the entire component the adjacent class with boundary nodes closest the component centroid:
pec
ICI
Σ Pi
arg min
B
1
lP, Mella, jEB
Σ
+!)== = ViEC.
where By are boundary neighbors of C with class in G. As shown in Figure '5-Kitchen' island is relabeled into '6-Bedroom' via contiguity restoration.
the mislabeled
Graph Contextual Typing After the preceding steps, small fraction of regions may still be typed Unknown. Intuitively, these are ambiguous areas where local object votes and connectivity cues are not confident enough on their own. For any region type still Unknown, we make single pass that combines graph context and object inventory. We build compact summary: (i) the histogram of adjacent room types in G, and (ii) the top-5 object names in that region and query a lightweight cooructionffolowiinne model he for the most plausible type; otherwise, we keep the current label:
h (adjacentttyye hist, top-5 objects), if f((2) Unknown, (2)
plinal
otherwise.
where ha is the GP 1PT4ominni and its output updates the per-scene region dictionary, while node positions and edges remain unchanged.
3.1.2 NAVCRAFT-S
Goal Given the room-labeled connectivity graph and per-scene item lists, NavCraft-S selects a fea- sible triple: start region s, target-object region t, end region and validates with graph constraints, and synthesizes directed region-to-region path. A user profile π injected via the prompt as light preference when sampling target objects, and it never overrides feasibility.
Profile-conditioned sampling We simulate user demand with a lightweight role profile that en- codes age, occupation, and lifestyle. The profile is injected into the prompt to encourage diverse habits and phrasing. and is used only as a tie-breaker when multiple objects or destinations are equally eligible. Following the role templates in NavRAG (Wang et al. 2025b). NAVCRAFT-S then samples a portable object and compatible start and end regions conditioned on π. This simple conditioning increases variety without relying hand-crafted priors.
Feasibility Given a candidate triple (s,t,e), NavCraft-S must first ensure that the underlying naviga- tion problem is meaningful: each leg should be reachable the region graph and long enough to
5

---

Published as a conference paper at ICLR 2026
span multiple rooms. As shown in Figure
evaluate the two legs - and e on the region graph using the skill library. Let L(u, v) d (u, v) denote hop distance on the region graph, conn(u, t)) indicate reachability, and adj w) 3 L(u,v)
1. We introduce a hop threshold т 2 to control the minimum cross-room extent (CoNavBench sets r = 2). A leg is admissible if connected and non-trivial in length. To avoid redundancy with the non-adjacency rule, we enforce
leg_ok( (u, v) = (onn(u, v) A L(,, v) 2 max
valid leg ok(s,t) leg ok(t,
In words, each leg must be reachable and span least (2, hops, and larger t encourages longer-range plans. Once valid holds, we concatenate hop-shortest paths for the two legs and com- press consecutive nodes that belong the same region to obtain region transitions:
Path(s ~ e) SP,(s,t) @ (P
3.1.3 NAVCRAFT-C
Given the high-level triple (s, L, e) and the region path produced by NAVCRAFT-S, NAVCRAFT-C lifts the single agent plan collaborative execution on the same semantic and geometric graph. The module first decides whether collaboration is beneficial. If collaboration is selected, it fixes a collaboration type and hands off. Details of skill templates appear in the Appendix.
Type abstraction We use two canonical handoff patterns that allow the planner to reason about cooperation independently of motion primitives. Type A/: the collaborator picks up the object in region f, hands off at transfer region and the main agent delivers from z to Type A2: the main agent picks up in f, hands off at x, and the collaborator delivers from x to e.
Augmented metric graph Let T be the set of region nodes and A {a., azz} the set of anchors (end asset, candidate transfer asset). For any anchor a A, let c(a) E T denote the region that contains We build an augmented node graph G+ from the Habitat connectivity graph G. Edges in G use 2D Euclidean weights. Each anchor a is inserted at its physical location and linked to the nearest navigable node. We then use single distance on GT:
d(x, u) dist (x,
Collaborative Generation We quantify when worthwhile involve a second agent by com- paring how much travel load the main agent would bear alone versus under different collaboration patterns. Intuitively, collaboration only accepted bringing the helper strictly shortens the main agent's 's own route. The single agent baseline load borne by the main agent is:
Co = d(s,o) + d(o, a.).
Given candidate tuple (type, a,), evaluate the main agent load under two types of collaboration:
J d(s, + d(a,, (e),
JA2
d(s,t) + d(t, az).
Here Jr, denotes the load borne by the main agent, and the A1/A2 indexes the collaboration types. We accept collaboration
min min(JA1 JA2] Csolo:
and we report the improvement ratio a = min(JA. , , //al candidate must satisfy the scene-graph guards: (i) x * and ag exists under æ; (ii) both agents can reach in G+; (iii) the collaborator's start follows non-adjacency and connectedness rules (t, The planner iteratively proposes tuples and records them with a < 1.
3.2 THE CONAVBENCH BENCHMARK AND METRICS
Benchmark Definition The proposed CoNavBench benchmark is designed evaluate collabora- tive embodied navigation under multi-agent settings. Unlike conventional single-agent VLN tasks, where an agent must complete a long-horizon instruction end-to-end, CoNavBench decomposes a complex instruction into multiple collaborative subtasks (referred to collab stages). A typical high level user command follows the pattern: "Find object A at location X, and deliver it to location y". Instead of requiring single agent traverse and manipulate across the entire trajectory, the

---

Published as a conference paper at ICLR 2026
(a) Single-agent trajectory visualization
(b) Collabrative-agent trajectory visualization
Transfer Region
KK
Scene Top-down View
(c) Collahrative-agent interference work
Figure 5: (a) Single-agent trajectory visualization: the agent navigates independently following the given instruction. (b) Collaborative-agenl trajectory visualization: two agents cooperate during navigation, showing more efficient and coordinated exploration paths. (c) Collaborative-agent in- terference work: visual examples from the agents' first-person perspectives, illustrating interaction and coordination in shared environments.
task distributed across two agents. Concretely, one agent responsible for locating and transport- ing the target an intermediate relay point, after which another agent continues the delivery the final goal. As shown in Figure 5) this decomposition produces coordinated trajectories with clear relay handoff between agents. Compared to the single-agent rollout Figure (a), the collaborative setting in Figure (b) reduces backtracking and shortens paths by assigning complementary explo- ration regions. First-penn Hirs--person views Figure[3(c further illustrate the handoff and mutual avoidance behaviors that enable efficient, reliable delivery. This decomposition mirrors realistic multi-robot co- operation, mitigates memory overflow issues in long-horizon reasoning, and empirically improves task success rates. Meanwhile, also follow (Song et al. 2025) to decompose the high-level tasks and create step-by-step VLN tasks for each trajectory segment to alleviate the inherent difficulty of executing the abstract instructions.
Evaluation Metrics To rigorously measure performance on CoNavBench, we employ standard navigation metrics: (i) Success Rate (SR), the percentage episodes where the agent(s) success- fully complete the task within a 1.0 goal threshold; (ii) Success weighted by Path Length (SPL), which normalizes success by the efficiency of the trajectory; and (iii) Navigation Error, computed the geodesic distance between the agent's final position and the goal when the task terminates. In addition, we extend evaluation with two subtask metrics originally proposed LH-VLN (Song al., 2025): Independent Completion Rate (ICR) quantifies the success of each sub-task individ- ually, therehy providing insight into the robustness of agents when executing isolated segments of the collaborative pipeline. Conditional Success Rate (CSR) measures the overall success of the full multi-agent task, where completion depends on all preceding subtasks being successfully executed. CSR thus captures interdependencies across otlgeb and reflects the degree to which agents can coordinate seamlessly over extended task horizons.
4 EXPERIMENT
4.1 EXPERIMENTAL. SETTING
Simulator Settings All experiments are conducted in HABITAT3 (Puig et al. 2023), continuous 3D simulation platform for vision-and-language navigation (VLN). Unless otherwise specified, each

---

the visual Published as a conference paper at ICLR 2026
Table 2: Performance comparison on the Single-Agent Task in CoNavBench. Results are shown for both high-level tasks and step-by-step subtasks.
Single Agent Task (fighh-leve/Scee-by-stty Tasks)
Method
Type
SR1
SPLt
ISR1
CSR
NEJ
Random
0.00/1.26
0.00/1.26
1.61/1.26
1.21/1.26
7.25/7.56
Zero-shot
4.30/10.41
0.98/2.55
14.25/10.41
16.10/10.41
6.91/7.80
Qwen2.5-VL-33B
Finetuned
12.90/29.65
6.08/13.81
23.92/29.65
26.22/29.65
6.40/6.74
Zero-shot 0.00/1.26
0.00/1.26
1.84/1.26
1.33/1.26
7.21/7.56
Qwen2.5-VL-7B*
Finetuned
10.22/22.40
4.93/12.57
22.58/22.40
22.45/22.40
6.39/7.46
Table 3: Performance comparison on the Collaborative-Agen Task in CoNavBench. Results are shown for both high-level tasks and step-by-step subtasks.
Collaborative Agent Task (Highhlewel//See---yy-teg Tasks)
Method
Type
SRT
SPL1
ISR
CSR
NEG
Random
0.00/3.43
0.00/3.43
2.30/3.43
1.76/3.43
7.15/6.35
Zero-shot
8.67/19.86
2.89/5.44
16. 16.12/19.86
16. 16.12/19.86
6.82/6.50
Qwen2.5-VL-3B*
Finetuned
11.11/35.02
4.82/16.88
20.19/35.02
20.12/35.02
6.55/5.79
Zero-shot
0.00/3.61
0.00/3.61
1.90/3.61
1.36/3.61
7.12/6.35
Qwcn2.5-VL-7B
Finetuned
11.65/29.78
6.24/16.56
21.00/29.78
20.93/29.78
6.74/6.20
agent is equipped with synchronized RGB and depth sensors mounted in three directions: front, left (+60%), and right (-60%). To ensure comparability with prior work, we adopt the atomic action space used in LH-VLN (Song et al., 2025): move forward (+-0.25 m), turn left (+-30"), turn right (-30%), and stop. An episode (or sub- lub-episode) is regarded as completed either when the agent issues stop or when the geodesic distance the designated target falls below 1.0 m.
Embodied We instantiate two articulated robot embodiments from URDF models: the Fetch mo- bile manipulator and Boston Dynamics Spot. Fetch features a wheeled base with an upper-body manipulator and structural frame; Spot is quadruped robot capable of carrying a back-mounted arm. These embodiments allow us to test navigation and embodied interaction under heterogeneous morphology and locomotion dynamics, while keeping sensing and policy stacks consistent.
Scene Assets Our environments are primarily drawn from HM3D (Ramakrishnan et al. 2021). com- prising 216 large-scale, semantically annotated indoor reconstructions. We adopt the scene graph initialization from SCALEVLN to provide object- and room-level structure. addition, we develop real2sim pipeline that scans real-world indoor spaces and imports them into Habitat, enabling closed-loop validation of our data generation with NAYCRAFT. More details are in the Appendix.
Baselines and Training Settings We follow trajectory-supervisce supervised learning paradigm. For mul- timodal reasoning. we employ the Qwen-2.5VL family and report results for both small- and mid- scale variants (3B/7B), evaluated in zero-shot settings and after fine-tuning on the CoNavBench corpus. Visual features are extracted by a ViT backbone from encoder remains frozen during all training runs to stabilize optimization and reduce compute. Un- less noted otherwise, we fine-tune the language-conditonee policy and control heads (full- (full-parameter fine-tuning on the non-visual modules), using Adam with a learning rate of 10-5, Training is performed on four NVIDIA A800 GPUs with a per-step batch size of 1; complete run typically finishes about four days. We apply standard practices for reprodueibility: fixed random seeds, gradient clipping, and validation-based early stopping. More details are in the Appendix.
4.2 RESULT AND ANALYSIS
Single Agent Performance Table 2 reports single-agent results under both the high-level tasks and step-by-step protocols. Random policies fail across all metrics, confirming the benchmark's ''s non- trivial difficulty. Zero-shot Qwen2.5-VE VL models perform slightly above random on SR and ISR yet remain far from practical utility, with task-level SR below 5%. indicating that high- instruc- tions hard to follow. After finetuning, both Qwen2.5-VL-33 VLL-3B and 7B show clear absolute gains:
8

---

Published as a conference paper at ICLR 2026
Table Performance, efficiency, cost and latency of NAVCRAFT-powered agents. Higher numbers are better (1) except Cost (4). Note that the success rate represents task generation.
Success Rate
Collab Gain
Sample Eff. (sfiter)
Powered Agent
Cost
Single
Collab
Max
Avg
Google
2.0-flash
47%
8.51% %
29.72%
22.32%
0.265
16.82
2.5-flash-nothing
41%
9.76%
13.18%
9.24%
0.902
18.71
Claude
3-5-haiku
51%
3.90%
50.07%
37.06%
1.142
14.94
OpenAl
4o
77%
46.75%
75.23%
21.07%
5.242
30.85
4o-mini
64%
26.56%
47.32%
25.12%
0.360
21.41
4.1-mini
68%
23.53%
42.80%
19.10%
0.494
17.92
SR improves both the high-level and step-by-step settings, accompanied by consistent increases in SPL, ISR, and CSR, and a reduction in navigation error. Despite these improvements, abso- lute performance remains modest, underscoring that CoNavBench poses challenging single-agent benchmark and leaving ample headroom for future methods.
Collaborative Agent Performance Table 3 compares collaboration with single-agent execution. Under the step-by-step protocol, both Qwen2.5-VL-3B and 7B improve: the finetuned 3B model raises SR from 29.65 % to 35.02% 02, and the finetuned 7B model rises from 22.40 29.78% % with SPL increasing from 12.57 to 16.56 and NE decreasing, consistent with CoNavBench's design that splits a long multi-stag stage instruction into single-stage subtasks and shortens the decision horizon. In the high-level end-to-end evaluation, gains are smaller and some metrics slightly regress, partly because test-time relay planning introduces intermediate handoff points and auxiliary phrasing that cause mild vision language mismatches, and partly because high-level completion is inherently difficult: success compounds across stages (CSR), early errors propagate, and coordination overhead from state synchronization and re-localization enlarges the effective search space. Finally, although the 7B model is competitive, it does not surpass 3B under the current data budget, which suggests under-training rather than fundamental limitation; viewed in isolation, the collaborative setting still benefits 7B (SR 22.40% % to 29.78% SPL 12.57 to 16.56, NE decreases), indicating that multi-agent decomposition reliably improves local competence even when model capacity is not fully exploited.
4.3 ABLATION STUDIES
Table 4 evaluates representative off- the-hhhsh agents from Google, Claude, and OpenAl under both single and collaborative settings, revealing clear capability and cost-efficiency trade-offs. Collab- oration generally improves performance but with varying magnitude across families. Claude-3.5- haiku shows the second relative collaboration gain 50.07% despite very low absolute collaborative task generation success 3.90%. suggesting that weaker agents can benefit from task decomposi- tion but still fail to achieve reliable success. OpenAl's 4o achieves the strongest absolute results with 77% in the single-agent and 46.75% success rate in the collaborative task generation, while Google's models provide lower cost per sample but limited task generation success rate, which indicates that efficiency alone cannot compensate for weak grounding ability. Among these choices, GPT-4o- mini offers the most favorable balance: it reaches 26.56% collaborative task generation SR and the highest average collaboration gains among the OpenAl variants 22% at substantially lower cost, about 0.360 per sample compared to 5.242 for 4o. Based on this analysis, adopt GPT-4o-min as the data generation agent for CoNavBench. allowing us to scale instruction and trajectory synthesis while maintaining strong balance between quality and price efficiency.
Limitation Our framework still has several limitations. First, the data generation pipeline relies on GPT API models, which introduce stylistic bias and make reproducibility sensitive backend updates; a natural next step is to train or distill an open LLM specialized for CoNavBench and to improve throughput with batching, caching, and on-graph pruning. Second, NavCraft-C currently

---

Published as a conference paper at ICLR 2026
targets two-agent relay patterss in indoor HM3D-style scenes, coverage of richer collaboration and three or more robots remains limited, partly due to scene size.
5 CONCLUSION
We introduced CoNavBench, a collaborative ssioo-and-language navigation benchmark with 4048 episodes, collaboration type taxonomy, and graph-level annotations that enable team-aware evalu- ation (success, makespan, energy, and interference time). To populate and study this setting, we pre- sented NavCraft, a graph-grounded generation platform built on semantically augmented scene- graph substrate, along with a two-stage agent (NavCraft-S and NavCrafi-C) and an on-graph effi ciency tool library for closed-loop validation and guidance. Beyond establishing the benchmark, we provide a reference stack that couples Qwen-series LLMs. Policies trained on CoNavBench achieve 18.11% % step-level task success rate compared to single-robot, indicating a practical path toward deployable collaborative vision-and and-language navigation.
Acknowledgments: This work was supported by the National Key Research and Development Pro- gram of China (No. 2024YFE021 1000), in part by the National Natural Science Foundation of China (No. 62372329, 62506263, 62506264), in part by the Shanghai Scientific Innovation Founda- tion (No. 23DZ1203400), in part by the China Postdoctoral Science Foundation (No. BX20250383, GZB20250385, 2025M771530, 2025M771539), in part by Tongji-Qomolo Autonomous Driving Commercial Vehicle Joint Lab Project, and in part by Xiaomi Young Talents Program.
REFERENCES
Peter Anderson, Qi Wu, Damien Teney, Jake Bruce, Mark Johnson, Niko Sünderhauf, Ian Reid, Stephen Gould, and Anton Van Den Hengel. Assion-and-aagguae navigation: Interpreting yisually-grounded navigation instructions in real environments. In Proceedings of the IEEE con- ference on computer vision and pattern recognition, pp. 3674-3683, 2018.
Shuai Bai, Keqin Chen, Xuejing Liu, Jialin Wang, Wenbin Ge, Sibo Song, Kai Dang, Peng Wang, Shijie Wang, Jun Tang, al. Qwen2. 5-vl technical report. arXiv preprint 13X2: 2025.
Wenzhe Cai, Jiaqi Peng, Yuqiang Yang, Yujian Zhang, Meng Wei, Hanqing Wang, Yilun Chen, Tai Wang, and Jiangmiao Pang- Navdp: Learning sim-to-real navigation diffusion policy with privileged information guidance. arXiv preprint 250.::2500..8712,, 2025.
Hyungjoo Chae, Namyoung Kim, Kai Tzu-iunn Ong, Minju Gwak, Gwanwoo Song. Jihoon Kim, Sunghwan Kim, Dongha Lee, and Jinyoung Yeo. Web agents with world models: Learning and leveraging environment dynamics in web navigation. arXiv preprint arXiv:2410.13:: 132322 2024.
Jiaqi Chen, Bingqian Lin, Ran Xu, Zhenhua Chai, Xiaodan Liang, and Kwan- Yee K. Wong. Mapgpt: Map-guided prompting with adaptive path planning for rision-and-llape and-language navigation. In Pro- ceedings of the 62nd Annual Meeting of the Association for Computational Linguistics, 2024.
Shizhe Chen, Pierre-Louis Guhur, Makarand Tapaswi, Cordelia Schmid, and Ivan Laptev. Think global, act local: Dual-scale graph transformer for -ision- navigation. 2022 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), pp. 16516-16526. 2022.
An-Chieh Cheng, Yandong Ji, Zhaojing Yang. Zaitian Gongye, Xueyan Zou, Jan Kautz, Erdem Bıysk, Hongxu Yin, Sifei Liu, and Xiaolong Wang. Navila: Legged robot vision-language-action model for navigation. In RSS, 2025.
Yifei Dong, Fengyi WU, Qi He, Heng Li, Minghan Li, Zebang Cheng, Yuxuan Zhou, Jingdong Sun, Qi Dai, Zhi-Qi Cheng, et al. Ha-vln: A benchmark for human-aware navigation in discrete- continuous environments with dynamic multi-human interactions, real-world validation, and an open leaderboard. arXiv preprint Ttt:25003114299 2025.
Michael Hahsler, Matt Piekenbrock, and Derek Doran. dbscan: Fast density- based clustering with Journal of Statistical Software, 2019.
10

---

Published as a conference paper at ICLR 2026
Yicong Hong, Qi Wu, Yuankai Qi, Cristian Rodriguez- Opazo, and Stephen Gould. VIn-bert: A recurrent vision-and -annuugg bert for navigation. 2021 IEEE/CVE Conference on Computer Vision and Pattern Recognition (CVPR), pp. 1643-1653, 2020.
Sihao Hu, Tiansheng Huang, Gaowen I Liu, Ramana Rao Kompella, Fatih Ilhan, Selim Furkan Tekin, Yichang Xu, Zachary Yahn, and Ling Liu. A survey on large language model-based game agents. arXiv preprint XX11:2444.020333 2024a.
Ziniu Hu, Ahmet Iscen, Aashi Jain, Thomas Kipf, Yisong Yue, David A Ross, Cordelia Schmid, and Alireza Fathi. Scenecraft: An Ilm agent for synthesizing scenes as blender code. Forty-first International Conference Machine Learning, 2024b.
Vihan Jain, Gabriel Ilharco, Alexander Ku, Ashish Vaswani, Eugene Ie, and Jason Baldridge. Stay on the path: Instruction fidelity in vision-and-land iisoo-and-languuae language navigation. In Annual Meeting of the Association for Compulational Linguistics, 2019.
Zhi Jing, Siyuan Yang, Jicong Ao, Ting Xiao, Yugang Jiang, and Chenjia Bai. Humanoid- gen: Data generation for bimanual dexterous manipulation via Ilm reasoning. arXiv preprint arXiv:2507.00833, 2025.
Mukul Khanna, Ram Ramrakhya, Gunjan Chhablani, Sriram Yenamandra, Théophile Gervet, Matthew Chang, Zsolt Kira, Devendra Singh Chaplot, Dhruv Batra, and Roozbeh Mottaghi. Goat-bench: A benchmark for multi-modal lifelong navigation. 2024 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), pp. 16373-16383, 2024.
Jacob Krantz, Erik Wijmans, Arjun Majumdar, Dhruv Batra, and Stefan Lee. Beyond the nav- graph: Vision-anddlanguagge navigation in continuous environments. In European Conference on Computer Vision, pp. 104-120. Springer, 2020.
Jacob Krantz, Shurjo Banerjee, Wang Zhu, Jason J. Corso, Peter Anderson, Stefan Lee, and Jesse Thomason. Iterative aiboo--andlanguuage navigation. 2023 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), pp. 14921-14930, 2022.
Chengshu Li, Ruohan Zhang, Josiah Wong, Cem Gokmen, Sanjana Srivastava, Roberto Martín- Martín, Chen Wang, Gabrael Levine, Michael Lingelbach, Jiankai Sun, Mona Anvari, Minjune Hwang, Manasi Sharma, Anman Aydin, Dhruva Bansal, Samuel Hunter, Kyu- Young Kim, Alan Lou, Caleb R. Matthews, Ivan Villa-Renteria, Jerry Huayang Tang, Claire Tang, Fei Xia, Silvio Savarese, Hyowon Gweon, C. Karen Liu, Jiajun Wu, and Li Fei-Fei. Behavior-lk: A benchmark for embodied ai with 1, 000 everyday activities and realistic simulation. In Conference on Robot Learning. 2022.
Xavi Puig. Eric Undersander, Andrew Szot, Mikael Dallaire Cote, Ruslan Partsey, Jimmy Yang. Ruta Desai, Alexander William Clegg, Michal Hlavac, Tiffany Min, Theo Gervet, Vladimir Von- drus, Vincent-Pierre Berges, John Turner, Oleksandr Maksymets, Zsolt Kira, Mrinal Kalakr- ishnan, Jitendra Malik, Devendra Singh Chaplot, Unnat Jain, Dhruv Batra, Akshara Rai, and Roozbeh Mottaghi. Habitat 3.0: A co-habitat for humans, avatars and robots, 2023.
Yuankai Qi, Qi Wu, Peter Anderson, Xin Eric Wang, William Yang Wang, Chunhua Shen, and Anton van den Hengel. Reverie: Remote embodied visual referring expression in real indoor environments. 2020 IEEE/CV Conference Computer Vision and Pattern Recognition (CVPR), pp. 9979-9988, 2019.
Yanyuan Qiao, Haodong Hong, Wenqi Lyu, Dong An, Siqi Zhang, Yutong Xie, Xinyu Wang, and Qi Wu. Navbench: Probing multimodal large language models for embodied navigation. ArXiv, abs/2506.01031, 2025a.
Yanyuan Qiao, Wengi Lyu, Hui Wang, Zixu Wang, Zerui Li, Yuan Zhang, Mingkui Tan, and Qi Wu. Open-nav: Exploring zero vision-and- -nd---nddlaagggge navigation in continuous environment with open-source llms. 2025 IEEE International Conference on Robotics and Automation (ICRA), pp. 6710-6717. IEBE, 2025b.
11

---

Published as a conference paper at ICLR 2026
Santhosh Kumar Ramakrishnan, Aaron Gokaslan, Erik Wijmans, Oleksandr Maksymets, Alexander Clegg, John M Turner, Eric Undersander, Wojciech Galuba, Andrew Westbury, Angel X Chang, Manolis Savva, Yili Zhao, and Dhruv Batra. Habitat-matterpy scale 3d environments for embodied AI. In Thirty-fifth Conference on Neural Information Pro- cessing Systems Datasets and Benchmarks Track, 2021. URL
3d dataset (HM3d); 1000 large-
11099082330
Krishan Rana, Jesse Haviland, Sourav Garg, Jad Abou-Chakra, lan D. Reid, and Niko Sünderhauf. Sayplan: Grounding large language models using 3d scene graphs for scalable task planning. In Conference on Robot Learning. 2023.
Nikhila Ravi. Valentin Gabeur, Yuan- Yuan-Ting Hu, Ronghang Hu, Chaitanya Ryali, Tengyu Ma, Haitham Khedr, Roman Rädle, Chloe Rolland, Laura Gustafson, Eric Mintun, Junting Pan, Kalyan Va- sudev Alwala, Nicolas Carion, Chao- Yuan Wu, Ross Girshick, Piotr Dollár, and Christoph Fe- ichtenhofer. Sam 2: Segment anything in images and videos. arXiv preprint arXiv:2408.00714, 2024. URL[https: pestpss:/arxivvee htt////xxvv..rre abs 22t.//0000000011
Elvis Saravia. Prompt Engineering Guide. http:///iwt...oommocaaa//////ppp 12 2022.
Guide,
Manolis Savva, Abhishek Kadian, Oleksandr Maksymets, Yili Zhao, Erik Wijmans, Bhavana Jain, Julian Straub, Jia Liu, Vladlen Koltun, Jitendra Malik, et Habitat: A platform for embodied ai research. In Proceedings of the IEEF/CVF international conference on computer vision, pp- 2019.
Raphael Schumann, Wanrong Zhu, Weixi Feng, Tsu-Jui Fu, Stefan Riezler, and William Yang Wang. Velma: Verbalization embodiment of I1m agents for vision and language navigation in street view. In AAAI Conference on Artificial Intelligence, 2023.
Xiangyu Shi, Zerui Li, Wenqi Lyu, Jiatong Xia, Feras Dayoub, Yanyuan Qiao, and Qi Wu. Smart- way: Enhanced waypoint prediction and backtracking for zero-shot vision-ana lision-and-langee and-language naviga- tion. ArXiv, 10s6,, 2025.
Xinshuai Song, Weixing Chen, Yang Liu, Weikai Chen, Guanbin Li, and Liang Lin. Towards long- horizon vision-language navigation: Platform, benchmark and method. In Proceedings of the Computer Vision and Pattern Recognition Conference, pp. 12078- 12088, 2025.
Jesse Thomason, Michael Murray, Maya Cakmak, and Luke Zettlemoyer. Vision-and-dialog navi- gation. In Conference on Robot Learning, 2019.
Jiawei Wang, Renhe Jiang, Chuang Yang, Zengging Wu, Makoto Onizuka, Ryosuke Shibasaki, and Chuan Xiao. Large language models as urban residents: Ilm agent framework for personal mobility generation. ArXiv, abs/2402.14444 2024a.
Liuyi Wang, Xinyuan Xia, Hui Zhao, Hanqing Wang, Tai Wang. Yilun Chen, Chengju Liu, Qijun Chen, and Jiangmiao Pang. Rethinking the embodied gap in lisoon-and-aanguaee navigation: A holistic study of physical and visual disparities. arXiv preprint 1xXi:22507.13199 2025a.
Shihao Wang, Zhiding Yu, Xiaohui Jiang, Shiyi Lan, Min Shi, Nadine Chang, Jan Kautz, Ying Li, and José M. Álvarez. Omnidrive: A holistic Ilm-agent framework for autonomous driving with 3d perception, reasoning and planning. ArXiv, abs/2405.01533, 2024b.
Tianhang Wang, Guang Chen, Kai Chen, Zhengfa Liu, Bo Zhang, Alois Knoll, and Changjun Jiang- Ume: unified handwidth-efficiens and multi-resolution based collaborative perception frame- work. In Proceedings of the IEEE/CVF International Conference on Computer Vision, pp. 8187- 8196, 2023a.
Zihan Wang, Yaohui Zhu, Gim Hee Lee, and Yachun Fan. Navrag: Generating user demand instruc- tions for embodied navigation through eetrieval-augmennn 1lm. arXiv preprint 2rxhv:2502.11142 2025b.
Zun Wang, Jialu Li, Yicong Hong, Yi Wang, Qi Wu, Mohit Bansal, Stephen Gould, Hao Tan, and Yu Qiao. Scaling data generation in vision-and-language navigation. In ICCV 2023, 2023b.
12

---

Published as a conference paper at ICLR 2026
Meng Wei, Chenyang Wan, Xiqian Yu, Tai Wang, Yuqiang Yang. Xiaohan Mao, Chenming Zhu, Wenzhe Cai, Hanqing Wang, Yilun Chen, et al. Streamvin: Streaming ssioo-and-langueee navi- gation via slowfast context modeling. arXiv preprint arXtv:2507.05240, 2025.
Jules White, Quchen Fu, Sam Hays, Michael Sandborn, Carlos Olea, Henry Gilbert, Ashraf EI- nashar, Jesse Spencer-Smith, and Douglas C Schmidt, A prompt pattern catalog to enhance prompt engineering with chatgpt. arXiv preprint drXiv:2302.11382. 2023.
Runsheng Xu, Hao Xiang, Xin Xia, Xu Han, Jinlong Li, and Jiaqi Ma. Opv2v: An open benchmark dataset and fusion pipeline for perception with vehicle-to-vehie communication. In 2022 IEEE International Conference on Robotics and Automation (ICRA), 2022.
Yue Yang, Fan-Yur Sun, Luca Weihs, Eli VanderBilt, Alvaro Herrasti, Winson Han, Jiajun Wu, Nick Haber, Ranjay Krishna, Lingjie Liu, et al. Holodeck: Language guided generation of 3d embodied ai environments. In Proceedings of the IEEE/CVF Conference on Computer Vision and Putlern Recognition, pp. 16227-16237, 2024.
Sriram Yenamandra, A. Ramachandran, Karmesh Yadav, Austin Wang, Mukul Khanna, Théophile Gervet, Tsung- Yen Yang, Vidhi Jain, Alexander Clegg, John Turner, Zsolt Kira, Mano- lis Savva, Angel X. Chang, Devendra Singh Chaplot, Dhruv Batra, Roozbeh Mottaghi, Yonatan Bisk, and Chris Paxton. Homerobot: Open-vocabulary mobile manipulation. In Conference Robot Learning. 2023.
Duo Zheng, Shijia Huang, Lin Zhao, Yiwu Zhong, and Liwei Wang. Towards learning a generalist model for embodied navigation. 2024 IEEE/CVF Conference Computer Vision and Pattern Recognition (CVPR), pp. 13624-13634, 2023.
Duo Zheng, Shijia Huang. Lin Zhao, Yiwu Zhong, and Liwei Wang. Towards learning generalist model for embodied navigation. Proceedings the IEEE/CVF Conference on Computer Vision and Pattern Recognition, pp. 13624-13634, 2024.
Gengze Zhou, Yicong Hong, and Qi Wu. Navgpt: Explicit reasoning in vision-and- langugge navi- gation with large language models. In AAAI Conference on Artificial Intelligence, 2023.
Fengda Zhu, Xiwen Liang, Yi Zhu, Xiaojun Chang, and Xiaodan Liang. Soon: Scenario oriented object navigation with graph-based exploration. 2021 IEEE/CVF Conference on Computer Vision and Pattern Recognition (CVPR), pp. 12684-12694, 2021.
Brianna Zitkovich, Tianhe Yu, Sichun Xu, Peng Xu, Ted Xiao, Fei Xia, Jialin Wu, Paul Wohlhart, Stefan Welker, Ayzaan Wahid, al. Rt-2: Vision-language-action models transfer web knowledge to robotic control. In Conference Robot Learning, pp. 2165-2183, PMLR, 2023.
13

---

Published as a conference paper at ICLR 2026
A
APPENDIX
APPENDIX LISTS
Real2Sim ToolBox
Experimental Setup
Supplementary Experiments
Discussion
Large Language Models Usage Statement
Ethics statement
Human vs. NavCralt Case Study
User Profile
Real Robot Demo
Implementation details of NavCraft-S)
Implementation details of NavCraft-C
Prompts for Graph contextual Typing
Ablation for Prompts
A.1 REAL2SIM TooLBoX
(a) Scene Mesh Scanner App
(b) 3D Bounding boxes target objects
(c) Navmesh
Figure 6: Pipeline of Real-world into NavCraft data generation.
Algorithm Real2Sim ToolBox
Require: Mios {4, Kr, Rr, te)T=
Ensure: Object list O, navigable graph N,, scene graph G, tasks from NavCraft-S/C
1: Malign t- Taligu Moss; [R.tt]] Talign [R]tt Vt
2: for = to T do
3:
B, SSegmnntnnythnng(/
2D instance masks & boxes
4: for each b E B, do
5:
'Pc. BackProjec K2, Res te Maliga)
6:
δ.,b + Fit3DBox(Pr.)
provisional 3D proposal
7: end for
8: end for
9: DBSCAN Merge Merge(fór.s...) merge across views using 3D position/size 2D IoU cues AndeereeNaanesshAAAdddsdss(
10: N
via sca scaleVIN scripts & rooms/ohjects/portaks topology traversability attributes
G BuildSceneGraph((. O)
12: Plang <- NavCraft-S(())
-iigllerobot base plan with stages collaborative schedule with validated handoffs/rendeezous
13: Plang + NavCrafi-C(e Plans)
14: return O,N, G, Plang, Planc
Goal Lift a real indoor scene into a NavCraft-ready, semantics ceantticc-goomeety-awwaaa scene graph that supports task generation and collaborative scheduling.
14

---

Published as a conference paper at ICLR 2026
80
50
10
(1) Batch vs. Task length Information
(b) Task length vs. Instruction lengths
Figure 7: (a) Batch vs. task length information across different data splits. Each boxplot illustrates the distribution of task lengths within specific batch (1-11). (b) Task length vs. instruction lengths across different domains, showing their joint distribution with density overlays.
Inputs (i) An iOS LiDAR sean (triangle mesh M.os) with keyframe RGB images { camera intrinsics { [K], and extrinsics woold-to-cameett {[R t:]]; (ii) optional room labels or user notes. Outputs (i) An object list O {o,} with category, 3D bounding boxes, and size; (ii) navigable cemmantics-geomttryy NavCraft-C collaborative schedules.
graph N: (iii)
scene graph g = (V, (iv) NavCraft-S base tasks and
Pipeline 1) Scan & coordinate alignment. We import Miss from Scanner Appland align to Habi- tat's Y-up, right-handed convention via a fixed transform Talign (empirically, ARKit's (æ, y,z) maps to Habitat's (x, 2, y); apply the same transform to all camera poses), 2) Keyframe segmentation and 2D proposals. For each keyframe I, we run Segment-Anythinn
(Ravi et al. 2024) to obtain instance masks and 2D bounding boxes B, 3) 2D-33D projection mesh. Using (K,, Rd, tz), each 2D mask is back- projeproeet to Malign with z-buffering and visibility checks, yielding per-proposal 3D points and provisional 3D box. 4) Cross-view proposal merging. We cluster multi-view pro- posals with DBSCAN (Hahsler et al. 2019) in a joint space (3D centroid, size) augmented by 2D) IoU agreement across overlapping views, producing deduplicated objects O. Categories come from majority vote over views; sizes from robust box fitting. 5) Navigability and scene-graph construc- tion. We generate walkable navmesh and sample navigable nodes with ScaleVLN (Wang et al,, 2023b) scene scripts, then build G: room nodes (via proposed hierarchical clustering over spatial layout), object nodes (from O), and portal or doorway nodes; edges encode topology, traversabil- ity, doorway width, clearance, and occlusion statistics. 6) Task and schedule generation. On G, NayCraft-S synthesizes long-horizon single-robot base plans with explicit stages; NavCraft-C lifts them to collaborative schedules by instantiating helpers, allocating subgoals, and validating handoffs and rendezvous with our on- on-graph efficiency tools.
A.2 EXPERIMENTAL SETUP
Training We train the model via supervised fine-tuning on the CoNayBench trajectory corpus. Dur- ing training, the agent consumes observations, location cues, and action annotations from the dataset without being executed in the simulator. We use
2 with 1,000 warm- up steps. Due GPU memory constraints, we froze the first five layers of the model's language layers. Data are randomly shuffled and partitioned into 11 splits; splits 1-9 serve as training data, while splits 10-11 are held out for testing.
Qwen-series with memory-aware mechanism To adapt the collaborative long-horizon VLN, we follow the LH-VLN's two-level memory structure (Song et al. 2025) with short-term memory and long-term memory. The short-term memory stores temporally ordered observation-action sum- maries with associated confidence scores. Once the memory size exceeds a threshold, a pooling or forgetting strategy compresses older entries while preserving essential information. The long- term memory serves as retrieval database, where the agent retrieves top-k observation action pairs based on the current state support decision-making.
15

---

Published as a conference paper at ICLR 2026
Instruction words length
I
30
30
20
10
(a) Single Step-by-step Task length
(b) Collab Step-by-stop Task length
Figure 8: (a) Single-agent step-by-step tasks. (b) Collaborative step-by-step tasks. We observe
that both settings exhibit positive correlation between trajectory length and instruction complexity, while collaborative tasks generally involve denser instructions for similar path lengths, reflecting richer linguistic interactions and higher coordination demands.
Training loss curves
0.7
0.3
500
1k
1.5k
2k
2,5k
3K
3.5k
500
1k
1.5K
2k
2.5k
3k
3.5k
(a)
Qwen2.5-VIL 7B
(b)
Qwen2.5-VL. 3B
Figure 9: Training loss curves of Qwen2.5-VL VL models. Comparison of training dynamics for (a) QWen2.5-VL 7B and (b) Qwen2.5-VL. 3B. The x-axis denotes training steps, and the y-axis shows training loss. Both models exhibit general downward trend in loss with fluctuations, demonstrating stable convergence. Note that the blue curve represents the long- horizon loss, while the red curve represents the step-by-step loss.
A.3 SUPPLEMENTARY EXPERIMENTS
To further illustrate the effectiveness of our collaborative setting, we visualize both single-agent and multi-agent trajectories. As shown in Figure 10 a single agent typically follows a longer and less flexible route, whereas collaborative agents navigation. In addition, we provide qualitative examples from the agents' first-person perspectives, which highlight how collaboration helps reduce redundancy and improves coverage of the environ- ment. These visualizations confirm that multi-agent cooperation is beneficial for long-horizon VLN tasks, especially in complex indoor scenes.
coordinate their paths and achieve more efficient
As shown in Table 5 in the Single-Agent Task, both Qwen2.5-VL- LL-B3BBB and Qwen2.5-VL VL- demon- strate clear improvements over the random baseline once finetuned. While zero-shot performance remains relatively weak, supervised finetuning leads to significant gains in SR, SPL, and step-level success metrics (ISR, CSR), particularly under the Spot robot configuration. Notably, Qwen2.5- VL-3B achieves higher gains in SR compared to its 7B counterpart, suggesting that smaller models can still adapt effectively in constrained single-agent navigation. In contrast, higghihhs the benefits of collaborative-agent settings. Across both Fetch and SPOT robots, collaborative agents consistently achieve higher SR and SPL compared to the single-agent case, indicating that coop- eration facilitates more efficient path planning and execution. Finetuned models again outperform zero-shot ones by large margin, and the advantage of collaboration especially pronounced in step-level subtasks (ISR, CSR).
16

---

Published as a conference paper at ICLR 2026
Singe forward pazt harddwood floor, turn left the armchair. Stage Turn right doorway into white bedroom.
doorway, moving acrozs
T:Turn rightt the bedroom, go armchair. forward through badroom, a left turn at dourway, go along
Robot trajectory
Robot trajectory
Figure 10: Visualization cooperative navigation in CoNavBench. Robot and Robot traverse residential environment along the floor-plat plan map (left). Colored bounding boxes mark salient landmarks; the same colors are used in the instruction text to denote aligned references. The partner robot can help retrieve visual evidence and disambiguate targets, yielding more efficient progress.
Table 5: Performance comparison the Single-Agent Task in CoNavBench. Results are shown for both high-level tasks and step-by-step subtasks under different robot configurations.
Fetch
SPOT
Method
Type
SRT
SPL
ISR
CSR
NE
SR
SPL
ISR
CSR
NEJ
Random
0.00
0.00
2.87
2.01
7.11
0.00
0.00
0.51
0.51
7.36
Zero-shot
4.60
1.25
14.37
14.37
7.14
4.04
0.73
14.14
13.89
6.72
Qwen2.5-VL-3B
Finetuned
6.90
3.45
17.82
17.82
6.71
18.18
29.29
29.29
6.13
Zero-shot
0.00
0.00
2.87
2.01
7.09
0.00
0.00
1.01
0.76
7,30
Qwen2.5-VL-7B+
Finetuned
4.60
2.51
13.22
13.22
6.90
15.15
7.07
30.81
30.56
5.93
A.4 DISCUSSION
Planned vs. realized efficiency Our planning-time analysis shows that fine-tuned Qwen-series plan- ners synthesize shorter planned makespans by decomposing missions and exploiting parallelizable subgoals. This upper bound is informative about the capacity of the task generator and scheduler. However, the realized wall-clock on-policy exccution depends on downstream VLN controllers whose single-agent success and path optimality remain imperfect. Detours, re-localization, oscil- lations near ambiguous landmarks, and occasional dead-ends inflate step counts; multi-robot in- terference (blocking, contention narrow passages) and coordination overhead (handoffs, waits, communication latency) further erode the theoretical speedup. Consequently, despite better plans, multi-robot deployments may yet outperform strong single robot in measured time.
Why we did not foreground time-efficiency gains for Qwen-series Emphasizing planning-time savings without corresponding gains in realized makespan risks over-claiming. In our setting, the gap between planned and executed trajectories is dominated by (i) suboptimal path-following under partial observability, (ii) schedule slippage due to local replanning, and (iii) interference not fully captured by static scene-grane -ere--rrphhhhh checks. We therefore reported time improvements primarily as an up- per bound from task generation, while centering evaluation on completion-centric metries (success rate, SPL, navigation error), which are more stable under current VIN reliability.
Future Bridging the plan-execution gap will likely require tighter closed-loop integration: uncertainty-aware scheduling, online replanning with interference prediction, traffic rules for nar- row corridors, stronger low-level navigation, and learning cost models that penalize contention. In short, collaborative VLN remains long-term agenda: the planners can already propose efficient cooperation, but reliably realizing those gains in-the-loop is still work in progress.
A.5 LARGE LANGUAGE MODELS USAGE STATEMENT
We used large language models for two purposes. First, to polish writing by improving grammar, wording, and clarity of text drafted by the authors. Second, implemented an LLM based agent to generate collaborative Long-horizor VLN benchmark. All prompts, generation procedures are documented. The authors designed the approach, reviewed and edited all L.MM outputs.
17

---

Published as a conference paper at ICLR 2026
Table 6: Performance comparison on the Collaborative-Agent Task in CoNavBench. Results are shown for both high-level tasks and step-by-step subtasks under different robot configurations.
Fetch
SPOT
Method
Type
SRT
SPL1
ISR
CSR
NE
SR
SPLT
ISRT
CSRT
NEJ
Random
0.00
0.00
2.39
2.00
6.92
0.00
0.00
2.21
1.52
7.39
Zero-shot
9.04
2.53
17.82
17.82
6.58
8.29
3,26
14.36
14.36
7.06
Finetuned
11.70
4.65
20.74
20.61
6.37
10.50
4.99
19.61
6.74
Zero-shot
0.00
0.00
2.13
1.60
6.89
0,00
0.00
1.66
1.10
7.36
Qwen2.5-VL-78
Finetuned
9.04
6.21
19.41
19.28
6.62
14.36
6.26
22.65
22.65
6.86
A.6
ETHICS STATEMENT
All procedures in this paper were conducted in accordance with the ICLR Code of Ethics.
A.7
HUMAN vs. NAVCRAFT CASE STUDY
> Collaborative type must be chosen from the following: Type-At: robot_2 2 helps deliver target object to transfer region, robot_1 completes delivery.
Robot_1 Start Position:
Robot_2 2 Start Position:
Type-A2: robot_1 brings target object to a transfer region, robot_2 2 completes delivery.
Target object Position:
Desination Position:
> Note that if you chose A1 the path is:
Roboot1 -> transfer region Desination Robot_2 -> target object -> transfer region
From your aspect, the most efficient Planning:
Collaborative Type: A1 or A2
Note that you chose A2 the path is -obbt_11 1 -> target object -> transfer region
intermediate transfer region: (Please
mark on the image. Use should have asset to place object)
transfer region
Robot_2 -> transfer region -> Desination
Figure 11: User case study question template.
Robot_1 Start Posittio:
Target dbject Position:
Robot, Position:
Desination Pootton:
W723-H22MMB-B009
Figure 12: Visualization of top-down bird's eye view of three scenes.
We invite three volunteers. For three randomly selected HM3D scenes (IDs 00712, 00539, 000732, shown in Figure 12). we provided each participant with the same scene graph and high-level single- robot mission (shown in Figure [T) as used by NavCraft, along with a bird's-eya s--ee--view rendering of the environment. For each scene, participants were asked to (i) choose an ideal transfer region and (ii) select collaboration type (Type-A1 vs. Type-A2) that they considered most reasonable for two-robot execution. We compared their choices to NayCraft-C's automatically generated transfer region and collaboration type.
We observe that i) Scene 00712: NavCraft and all three participants chose the same transfer region and the same Type-A1 pattern; ii) Scene 00539: NavCraft's transfer region and type matched the choices of two participants (User A and User C). The remaining participant (User B) deliberately selected a relay region closer to the main robot, preferring design where the helper robot completes much of the physical delivery possible so that the main robot spend more time near the
18

---

Published as a conference paper at ICLR 2026
Transter Region:
Nav
User
User B
User C
00T12-RZZIWMBWRR0
06753 1200aa2n
Figure 13: Visualization of NavCraft and three User (A, B and C) collaborative plans.
user for interaction. Interestingly, this iuser-inerrcction-poe prioritizee" preference also appears in User B's choice for scene 000732, suggesting a consistent personal strategy rather than disagreement with the task semantics; iii) Scene 000732: Both NavCraft and the human annotators favored parallelism- first strategies, but they diverged on the exact relay region: human participants, with access to the BEV image, tended to select the wider kitchen bar safer, more spacious handoff' location, while NavCraft-operating only on the symbolic scene graph without asset footprint information, selected narrower bar table near the window the transfer region. This mismatch is therefore attributable to geometric detail (asset size usable surface) that is not represented the current graph abstraction, rather than failure of logical reasoning about the task.
A.8 USER PROFILE
We utilize five distinct roles: Role 1: 25-year-old single male PhD student; Role 2: 33- yeay-oroldd married female lawyer; Role 65-year-old married retired male: Role 4: 9-year-old single male student; Role 5: 20-year-old single female undergraduate.
For comparison, we also include a no-profile baseline. On set of 20 scenes, we fix the random seed and scene configuration, and only vary whether user profile is provided (and, if so, which role). NavCraft therefore receives identical environment inputs, and the difference comes solely from the presence and type of user profile. I) Overall diversity. As shown in Figure 14 adding user profiles increases both instruction and object diversity. Across the 20 scenes, the total number of unique instructions grows from 316 (no profile) to 367 (with profiles), 16.14% increase. The total number of unique pickup objects increases from 98 to 115, a 17.35% increase. On a per- scene basis, the average number of unique instructions rises from 18.22 to 21.11, corresponding
19

---

Published as a conference paper at ICLR 2026
to 15.86% increase. II) Role-specific task demand. With profiles enabled, different roles exhibit clearly different object-demand patterns the same scene, reflecting their underlying persona. As illustrated in Figure [5] for example, in scene request practical items such as hand soap for cleaning, Role (child) prefers playful or visually attractive objects such pictures, and Role 5 (young female undergraduate) is more likely to request decorative items like flowers.
Ses-CQOWESbbwwer Role 3 (retired) tends to
These results indicate that conditioning user profiles only increases overall instruction and object diversity but also induces meaningful, role-dependent variations in task demand, which we believe makes CoNavBenn Bench more realistic for user-centric multi-robot navigation.
Role conditioning impact on task diversity
Tesk diversty metrics
Distribution scenes/betcchs
Role
fol:
200
130
300
Uniise indrustoons
Petop ohierts
Pidiop regions
Sceeec covere
Drop
Drop
Figure 14: Visualization of NavCraft under no-user profile vs profile setting.
00109-GTV2Y73SnSt
Role
Role
Role
Role
Role
200
00401-HBrQCavBgoo
20h
20hh
Role
Role
Role
00495-COWES! bawee
Role
Role
Role
200
400
DHT
Role
Role 2
Role
Role 4
2005
Role
2105
00386- B1136-33W-bPPPEES
Role
Role
Role
408
Role
Pertable Fumnitue
Lighting & Electrica
Decor Art
Textles Housshoodd
Hygiene
Dining
Stoage Origanization
Salety & Semoos
Penoonal Leiurr
Figure 15: Visualization task object demand categories with NavCraft under different user profile settings on five scenes.
20

---

Published as a conference paper at ICLR 2026
Path Planning: Forward
Plunsing::
Torget Object Locaion
I'm ltttle thirsty, get water?
warting boring no ane
Okay, I'm heading to the tna area get bottle of water. Please waft
(a) Single Agent
Feeting
I'm you much
You are welcaree, The exhibition hall quitte interesting. water has been deliveredi let get for you.
(b) Collaborative Agents
Figure 16: Visualization of real exhibition hall scene under single collaborative agents setting.
A.9 REAL ROBOT DEMO
We conducted the real robot collaboration case study in the exhibition hall. The process can be summarized as following: I) 3D Reconstruction of the Real Exhibition Hall and BEV View, we first capture multi-view images of the real exhibition hall and perform 3D scene reconstruction using a COLMAP with 3DGS pipeline. This yields a high-fidelity 3D model of the environment and top-down BEV (bird's-ey) view), which facilitates intuitive visualization and inspection of the exhibition space. II) Demand-Oriented Navigation for Single-Robot Water-Fetching Task. During the exhibition tour, the user reports feeling thirsty and requests water, triggering a demand-oriented navigation task. After receiving the 'fetch water' command, the single robot must navigate to the target object, a bottle of water, located far away on the opposite side of the hall and perform the fetching operation. III) User Waiting Problem Caused by Long Round-Trip Paths. After picking up the water, the robot has to traverse the long path back to the user's location. Because the overall round trip is time-consuming the user can only passively wait during this period, leading to poor user experience and boredom. IV) NavCraft-C High-Level Task Planner and Multi-Robot Relay Design. To address the low efficiency and unsatisfying user experience in ong-horizon single-robot tasks, propose the NavCraft-C high-level task planner. It introduces a second robot and defines a transfer region in the exhibition hall, enabling task relay and parallel execution, thereby improving overall
21

---

Published as a conference paper at ICLR 2026
task efficiency and user experience. V) Multi-Robot Task Relay and Improved User Interaction. While robot 2 is heading to fetch the water, robot stays with the user, continuously providing explanations and interaction to maintain engagement. When robot 2 approaches the transfer region, robot proactively moves to this region to receive the bottle and then hands the water to the user, achieving efficient multi-robot collaboration and enhanced human-rohot interaction experience. And we have update the corresponding real robot demo video section in the Anonymous Website: hups://navcraft githuu..o for better understanding.
22

---

Published as a conference paper at ICLR 2026
A.10
IMPLEMENTATION DETAILS OF NAVCRAFT-S
A.10.1
PROMPTS SETTING
PHASE 1: Single Long Horizion Navigation Task Generation:
System:
You are proficient in single-agent spatial planning and task design. Your goal is to generate meaningful single-robot task consisting of navigation and interaction subtasks, based on the provided scene graph (which contains spatial layout, room connections, and object distributions).
Rules:
You will receive two types of input to design a single-robot task:
scene graph:
"region": of region identifiers: RegionType RegionID (e.g.. "Bedroom 2").
"link": A list of bidirectional region connections indicating navigability (e.g., "Kitchen + Bed- room 2").
"item": A list of region-specific items, including: "region": Region identifier. "asset": Non-movable, fixed furniture such as tables, shelves, or counters. These serve reference locations delivery targets, "object": Movable, portable items that robots manipulate. Only objects may be picked up or released.
user profile:
"Age": Integer representing user's age (e-g.. 33).
"Gender": String specifying user's gender (e.g.. "Female").
"Marital Status": String indicating user's marital status (e.g.. "Married").
"Oecupation": String describing user's occupation (e.g., "Lawyer").
"Lifestyle Description": natural language sentence summarizing user's habits, environment, or values (c.g., "You work from home on various freelance projects, often on tight deadlines. You have flexible schedule but prefer a clean and quiet environment to focus.").
PHASE 1: Single-Robot Long-Range Task Planning (robot_I):
Objective:
Maximize travel distance and task complexity for robot_l.
Ensure all spatial constraints and planning rules are satisfied.
Planning constraints:
robot_1 must:
There is constraint that the start region must have RegionID=O any fixed ID.
Start in region far from the target object's region and end region.
Not start in region adjacent to the object
larget object's 's region and end region are not adjacent.
Move only along graph-connected regions.
Manipulate only portable objects.
12
The target object must exist in the "object" field of the target
region in the scene graph.
The end asset must exist in the "asset" field of the end regien in 4 the scene graph.
14
Output koys (Phase 1):
15
"Single robot start region": Starting region of robot_l.
"Single robot target object region": Region where the target
object is located.
17
"Target object": target object.
18
"Single robot end region": Region where the target object is delivered.
"Single robot travel path": Orderea. regionnto-region path followed
by robot_l. (From step Build the full travel path)
30
"rask instruction"; Natural language description of the task for robot_1.
You can call function help validate and reason:
23

---

Published as a conference paper at ICLR 2026
24
check_two_rdd har____o__att_an__aaaaaaaeee (start_rrgttttt target_region,
end_ region):
Purpose:
To validate whether the selected regions for single-robot task (start target end) satisfy connectivity, adjacency, and path length constraints.
26
INPUT:
start_region (string): Proposed starting region of robot_1 (Begionnyye__egionnD)
target_region (string): Region containing the portable object pick up SegrionnyyaRRegione
29
and end_region (string): Region to deliver and place the object (BegionnTyp__Rgionnll
OUIPUT:
start_?_tareet:
32
"connect"; true/false, "adjacency"; true/false, int,
"path": list of transitions like ["Kitchen_4 Living_room_5", ...]
36
target_2_endi
"connect"; true/false, "adjacency"; true/false, "path_length"" int, "path": 1ist of transitions like ("Living_room >> Hallway_2" 2", ...l
s2t_valid valid (bool): Whether start target path connected, net adjacent, and path_length length >= 2
s2t
t2e_valid (bool): whether target * end path is connected, net adjacent, and path_length >=
valid (bool): True only both path segments (s2t and t2e) are valid
46
Use the following step-by-step reasoning process to ensure the plan satisfies all constraints and is meaningful:
49
1. Randomly sample a portable object from all regions:
50
Random sample object listed under the object field of each region (these are portable). Do not select assets.
not weight sampling by the frequency of an object type, every portable object has equal probability.
4
Record the object's region in format: RegionType Regiont as target object region.
Ensure the selected object actually exists in the object list of the target region.
54
Example independence: examples in the prompt are edomonstrattiv only++. The sampling logic must not imitate or bias toward the specific objects used in those examples.
4
when multiple objects
equally eligible, prefer items that align with the user's "Occupation" and "Lifestyle Descriptien"
+ to boost contextual relevance, while still preserving overall randomress and diversity.
2. Randomly select start region for robot_l:
Must NOT be adjacent to the target object region.
58
Must be connected to the target object region. Must have a long path to the target object region (prefer lenghh >= 2).
59
Randomly select end region deliver the object:
Must NOT adjacent to the target object region.
62
Must be connected to the target object region.
24

---

Published as a conference paper at ICLR 2026
Must contain valid asset to place the object (e-g., table, shelf, counter).
+
64
Randomize among qualified candicates while maximizing path diversity.
Must have long path from the target object's region (prefer path_length 2)
66
4. Validate the region combination using the function haoos_tto__attaaaaaaacccoooo (start_region, target_region, end pod_regioo)";
If both path segmenta valid: The combination LOCK all three regions: start, target, and end. Proceed to generate path and output phase_1.
accepted.
69
If only the first segment (start target) is valid:
Keep the start and target region fixed (from Step and 2).
73
Retry sampling a new end region only (go back to Step 3).
74
Then call the function again to validate.
If only the second segment (target end) is valid:
Keep the target and end region fixed (from Step and Retry sampling a new start region only (go back to Step 2)
77
78
Then call the function again to validate.
If neither segment is valid:
All three regions are invalid.
Restart from Step 1 sample new target object.
5. Build the full travel path:
From the start region to the target object region;
Then from the target object region to the end region.
The travel path must be concatenation of these two segments,
4 maintaining correct directionality.
86
The last region in the path must be the end region.
This list becomes the "Single robot travel path". structured JSON in this format:
6. Output the result
90
"phase_1":
"Single robot start region": { ["robot_1"; "BegionType_RegiinnD""" "Single robot target object region": ("robot_1", Beeelontype_eeiinnee "Target object": "object",
94
"Single robot end region": ("robot_1": "RegiontTyp___egionI") "Single robot travel path": "rrobo_ii":
95
-> Ragiiontype_Hegionnn1
11,
99
"Task instruction"; "Take the [object] from Itarget object region] to the [asset] in [end region)."
101
102
103
GENERAL CONSTRAINTS:
Always respect scene graph connectivity ("link" field). Avoid adjacency robot start regions where specified.
106
107
You are not allowed to infer adjacency or connectivity from the text alone.
You MUST use the function "check hhhee___ath_and_aajccooo to verify: whether two regions are connected, whether they are adjacent,
110
111
and to obtain the path and its length.
Only return the JSON object. Do not explain your reasoning in the final
113
You may use internal reasoning and function calls during planning,
+ but your final output must contain only the JSON.
114
25

---

Published as a conference paper at ICLR 2026
Here is example of the INPUT and OUTPUT:
INPUT:
scene graph: i"Eioor 1": /"regicn"; fi"id": "Bedroom 1"1, ("id":
sathroom_2"), ("id"; "Kitchen_4"),, ("id"; rLiving_room__51) {"id"; "Hallway_6"), ("id"; "Bathroom_ 7"), ("id"; "Laundry_room_ 8 {"
id";
("id"; "Entryway_Poyer__2 "Bedroom_11"); 11"), ("id": "Bathroom_12") ("id": (Bedroom_13"),, link": ("Bedroom_] <-> Bathroom_2" "Bedroom_ <>> Kitchen_d" kitchen_4 4 <-> Living_room room_5,, "Kitchen_4 <-> hallway_5",
("id";
Kitchen_4 <-> Bathroom_?", "Kitchen_4 <-> Laundry_romm
Living_roame <-> Hallway_"", "Living room_5 <->
Lounge_ Roontin 9", sdiving_roommy
Eatryway_Poyer_
Hallway_6 <-> laundry_room room_8, "Hallway_6 <->
9", "Hallway_6 <>> Motrryay_Moyer_100 10", Hallway_6 <-> Hedroom_!! "Hallway_6 <-> Nathroon_
Bathroom <-> Bedroom 13"), "item": ("region": "Bedroom 1", asset": ("bed", "coffee table", "door"), "object": ("vase", ottoman", "lamp"!1, ("region": "Bathroom 2", "asset": [" bathroom_counte counter", "sink", "bathroom chower_cabin", "rug", "lamp"];, ("region"; "Kitchen_4", "asset"; ("dishwasher", "oven", "stove"], "object"; [ ("flower", "flower_vae vasc " "bowl"],, ("region"; "Living_room_5"" "asset": ["shelf", "couch ", "tv"], "object"; ("magazine", "box", "cushion"]), ("region": Hallway_6", 6", "asset": ["door"], "object": ["lamp", "vent", "rack "},, ("region"; "Bathroom_ "asset"; ("toilet", "toelett_paer", "sink"), "object": !"towel", "scap_aish", "dustbin"!!, ("region": "Zaundry_roae rocm__yyrro______ "asset": ("counter", "door", "bench"!, "object": ["basket", "coat_hanger" "lamp"]), ("region":
"object"; ["
"asset": ["chair", "table"], "object"; flower_vase", "rack", "flatware"],, ("region": "entryway "asset": ("door", "table"), "object": ("lamp"),, ("region": Bedroom_II" 11", "asset"; ["door", "bed", "dresser"), "object": [" plant", "lamp", "box"]), ("region": "Bathroom_ 12", "asset": [" bathroom_counterr" "toilet", "tollet_paper"), "object"; [" shower_handle", "rug", " ("region"; "Bedroom_ asset"; [ ("nightstand", "door", "bed"), "object"; ["rug", "vent", lamp"]]]}}
sounge__aiiting_ooome
user profile: ("Age": 33, "Gender": "Female", "Marital Status": Married", "Occupation
"Lawyer", "I "esiyye Description": "You maintain the good habit going to bed early and waking up early. Besides working in the study, you often do yoga and other exercises in the living room and enjoy cooking your own meals." "I
OUTPUT:
"phase_1" 1":
"Single robot start region": "robot_1"; "Bedroom_i"
},
"Single robot target object region": "robot_1": "Bedrocm_
1,
"Target object": "rug", "Single robot end region"; "robot_1"; "Bathreom_
b.
"Single robot travel path":
"robot_i":
"Bedroom_1 Kitchen_4", 4"
"Kitchen_e -> Living room 5", "Living room -> Hallway_66 6", "Hallway -> Bathroom 12",
26

---

Published as a conference paper at ICLR 2026
"Hathroom_ 12 Hedroom_13",
"Bedroom_ 13 -> Hathroom_12",
"Bathroom 12 -> Hallway_6" 6"
"Hallway -> Living room_
Kitchen_4* 4", "Kitchen_4 Bedroom_1",
"Living "Living_room, room_
"Bedroom_i -> Bathroom_2"
}
"Task instruction": "Take the rug in bedroom the bathroom counter in Bathroom,"
A.10.2 SKILL FUNCTION
def check two tww__ttth_______eeee_tt and and_aan__ddaa_ andjaadayyyyy (startrrrttttttttiiin target_region end_region, G, G_regicnid);
res =
"start_ : None, "target_?_end"" None, "s2t_valid"; False,
"tZe_valid"; False, "valid": False
10
s2t cchcchhettttllec chett_aaeaaanca.ccccooo/rrrrrrr targettrogionn, G, G_regionid)
res
s2t
if s2t ("conneett" and not s2t (*adjacency") and s2t ("path_
2:
res ["s2t__aaaa_ [==dd"" = True
t2e check Batckk_ptthhheee and adjacency (target tergee,ee,,,ttggeeeeeeoooo,,, end region, 4 regginndd
15
res ("target____een)
t2e
if ""eonncnet and not t2e (addjcccee)"" and t2e [2e[ppah_lengthh >- 2:
res "tt""ttaalld"" True
20
res "es("valid") = res "'s2t_validd" and res "tteddalid")
return res
def check Bheck__ptthaan_ddjjeee (regicn_a, region_b, G, G_regionid)
25
Simul simultanecusly determine whether two regions are connected and adjacent, and return the path Length and patn.
28
regionl num = aegion_a.splitti a.slitt"""" I-11 region2_num region__b.plii [-1]
start_nedes- [node for node nodes if node.splis ("_") [0] + regicni_num]
32
target_nodes nodes = [node for node in nodes if node oodetsplit. ("_") [0]
regicn2_num]
adjacency
35
adjacency any hG.has_edde (na, nb) for na in stdet_nodes for nb in
target_nodes)
#Search for the shortest path
27

---

Published as a conference paper at ICLR 2026
#Find the shortest path among all combinations shortest_path
40
shortest_length = float ('inf")
for in start_nodes:
for t in target_nodes:
try:
45
path = nx, shortest_path source=s, target=t)
it 1en (path) < shortest :engghh
shortest_Length shortest_path path except nx. NetworkkNoatthh: continue
1en (path)
if shortest_pate is None:
return
"conncet"; False, "adjaccncy"; adjaccncy, "paghh_ength"; 0,
"path": []
region_steps = [] prev_region id None for node in path:
region_id node. (pleet""tt"""") if region_id !- prev_regicn_id:
region_type G
", "_")
region_step f" (rrggiin_ttpe___reeeeeeee
region_steed apppnn (region_ste))
68
prev_region_id regicn_id
transiticns sf"Iregion_stcpslll -> sregion_steps (1+1))) for 1 in
range (len (region_steppp) 1)]
return
"connect"; True, jacency"; adjacency,
"path_length" length"; len (transitions),
76
"path": transitions
28

---

region. Published as a conference paper at ICLR 2026
A.11
IMPLEMENTATION DETAILS OF NAVCRAFT-C
A.11.1 PROMPTS SETTING
PHASE 2: Cooperative Multi-Robol Navigation Task Generation:
System:
You proficient in multi agent collaborative planning and task design. Your goal is generate prac- tical collahorative task consisting multiple navigation and interaction subtasks, based the provided scene graph (which contains spatial layout, room connections, and object distributions) single agent task.
Rules:
You will receive types of imput to design multi-robot collaborative task:
scene graph:
"region": A list of region identifiers: Region Reggioon
RegionID (c.g., "Bedroom
"link": A list of bidirectional region connections indicating navigability (e.g., "Kitchen_1 < Bed-
room 2").
"item": A list of region-specific items, including: "region": Region identifier. "asset": Non-movable, fixed furniture such tables, shelves, counters. These reference locations delivery
targets. "object": Movable, portable items that robots can manipulate. Only objects may be picked up or released.
single agent task:
"Single robot start region": Starting region robot_1.
"Single robot target object region": Region where the target object is located.
"Tageet object": target object.
"Single robot end region": Region where the target object is delivered.
"Single robot travel path": Ordered region-to-region path followed robot_1.
"Task instruction": Natural language description of the task for robot. I.
PHASE 2: Cooperative Multi-Robot Task Replanning (robot.1 and robot.2):
Ob Objective:
Divide robot_l's long-range task into subtasks shared between robot_1 (main agent) and robot_2 (collaborative agent). Optimize spatial and logical collaboration using scene graph
4 connectivity and task flow.
Determine whether collaboration is necessary, and choose best
suitable collaborative type based spatial and logical
+ conditions.
P Planning constraints:
- robot_2's start position must be:
Must randomly select valid start region.
Non-adjacent robot_l's
Connected via the scene graph to both the object region and the transfer zegion.
Collaborative type must be chosen from the following:
Type-Al: robot_2 helps deliver target object to transfer region, robot_1 completes delivery.
12
Type-A2: robot_1 brings target object to a transfer regicn, robot_2 completes delivery. The transfer region must:
accessible to both robots.
15
Contain a valid asset suitable for object handoff.
16
Not be **same as** the target object region.
The transfer asset must exist in the "asset" field of the
transfer region in the scene graph.
Subtasks
follow:
19
Type-A1 or A2: use a transfer region with valid assets.
20
For Type-A1:
robot must:
Move (transfer asset RegionID)
29

---

Published as a conference paper at ICLR 2026
Grab (object)
24
Move_to (end_assee Region ID)
25
Release (object)
robot 2 must:
Move tore_tofee (object RegionID)
Grab (object)
29
Move_to (traafffrrssssssttt RegionID)
30
Relcase (objoct)
For Type-A2:
robot_1
33
Move_to RegionID)
34
Grab (object)
Move_to (transier_ asset RegionID)
Release (object)
robot_2 must:
38
Move_to (transffrrassssee RegionIC) Grab (object)
39
Move_to (end__oeeed____ee asset RegionID)
Release (object)
Subtask instruction must follow these exact sentence templates
+ based on the collaborative type:
For Type-A1:
robot_l: "Take the [object] from the Itransfer asset] in [transfer region] to the [end asset] in [end region]. robot_2: "Take the [object] from [target region] to the - [transfer asset] in [transfer region]." For Type-A2:
robot_l: "Take the lobject] from Itarge region] the Itransfer regionl."
-
Itransfer asset
48
robot_ "Take the lobject] from the Itransfer asset] in [transfer region] to the [end asset] in [end region]." Strict constraints: You MUST NOT alter the sentence structure. You MUST NOT swap robot roles or change task flow logic.
-
The instrontion MUST clearly and unanbiguously describe where the object is taken from and where it is delivered. The instruction MUSI align exactly with the Subtask list in + logic and sequence.
54
Output keys (Phase 2):
55
"Collaborative robot start region": Starting region of robot_ and robot_?.
"gollaborative type": Collaborative type.
"Transfer region": Region where the object handoff occurs.
58
"Subtask instruction": Natural language instructions for robot
and robot 2.
"Subtask 1ist": Ordered action lists for robot_1 and robot_2, with primitives:
60
Move_to ("objoct_Rogionnil
Move_to ("asset_RegiionD))
Grab("object")
(alease("objecse
You can call function to help validate and reason:
(robot_ [robot_2_stattrregion
transfer_region,, collab_type)
68
Purpose: Check whether a given collaborative plan achieves better 4 execution efficiency than robot_1 executing the full task alone
INPUT:
robot start_region robot start region
(RegLonType_RegionD))
71
transfer_rogion: transfor region (Regiontyyo_RRgionnD))
30

---

Published as a conference paper at ICLR 2026
transfer_asset: valid asset suitable for handoff transfer region.
sype: collaborative type (Type-ID).
OUTPUT:
efficient: True/False
77
Use the following step-by-step reasoning process to ensure the plan satisfics all constraints and results in valid cooperative execution plan.
" "
79
Randomly select valid start region for robot_2.
90
Randomize among qualified candicates while maximizing path
diversity.
Must NOT be adjacent robot I'ss start region.
Must be connected
the scene graph to the target object region.
2. Determine whether collaboration is necessary, and choose the most
suitable collaborative type from the following, based on rebot_ and aabot_2's spatial distance and task logic:
transfer 4 region; robot_1 takes over and completes the task.
Type-Al: robot picks up the object and delivers it
85
Type-A2: robot_1 brings the object to transfer region; robot_2 takes over and completes the task.
to improve task diversity, Rased on the chosen collaborative type and robot_2's region, decide whether a transfer region
If multiple types
valid, sample
required. If required:
88
It must be reachable by both robot_1 and robot_2.
It must **not same as** the target object region.
It must contain valid asset suitable for handoff (e.g., shelf, + table, desk).
91
4. Validate all pairwise constraints using tool calls:
You MUST call
with
robot_2's proposed start region, the selected transfer region,
the selected transfer asset, and the chosen collaborative type.
%
If the returned "efficient" is True:
Must not re-call "check_collab htt.laabaathhefiiettttttteeeeeee siteeieeettsinnggpphhh you MUST remember the exact triplet of: robot_2_start_regie
4 transfer_region transfer_asset collab_type to finish the plar.
If the returned 'efficient" is False:
MUST restart the planning process:
102
Re-sample a new robot_ start region and/or a new transfer - region.
103
You MUST discard the previous inefficient regions.
Then, you MUST re-call the.k.oollbbpcttteffddoooo.iined on the new setup.
105
Repeat until a valid (efficient: Truc) combination is found.
106
5. Output the result in the following strict JSON format:
"phase_2":
109
"Collaborative robot start region": ( "robot_1* Reegiaatye__agiioiD"" "robot_2": BerrlonType_Regioninn },
110
111
"collaborative type"; "Type-10", "Transfer region": "RegionTyype_RegionnD! "Subtask instruction": "robot_i": "...",
114
115
"robot_2". "..."
118
}
119
"Subtask 1ist"; "robot_1: [
120
31

---

Published as a conference paper at ICLR 2026
"Move_to .e_.i"""........ .Dn
122
"Grab (" ('object_naaaae
123
"Move_to (". ... Reg.oonng "Release ('bjeect__oppo___cccccc name
126
" "robo__2"
127
128
"Grab (' ('ojoott___naaa
"Move_to("... .e..goon...))
"Release (release('objectt ('object_name")
131
132
133
136
GENERAL CONSTRAINTSS
137
Always respect scene graph connectivity ("link" field).
Use region function and assets to determine pickup and dropoff points.
140
Once a function call to
returns "efficient: true", you MUST remember the exact triplet cf: robot_i_start_rrogion transfer_regionn
143
traasfer_asset
144
collab_type
Your final output MUST use exactly the same triplet that was confirmed efficient.
146
You MUST NOT generate new combinations without validating them again.
+
147
Output JSON must include "phase_2" key with the described structure. Do not explain your reasoning in the final answer.
Additional strict naming rules (Move_to arguments) Format must be Move_to ('venttt"Kentttyy2__
149
**must not+* use
4 the RegionType (eg. Hallway, Bedroom, Tie) as <entity>. transfer region **must not** be same as target object regicn.
Here is an example of the INPUT and OUTPUT: INPUT:
scene graph: i"fioor_1": ("regicn"; [("id": "Bedroom_1"), ("id":
2athroom_2"), ("id"; "Kitchen_4"), ("id"; "Living__rom__5") ("id"; "Hallway_6",, ("id"; "Bathroom_ 7*), ("id"; "Laundry_room )"), {" id"; Baange_Waating_Roooe
("id": "Hedroom_11") ("id": "Hathroom_12"" 12"), ("id": "Hedroom_13" 13*]], link": ["Hedroom_] <-> Nathroom_2", "Bedroom_" <-> kitchen_d", 4", Kitchen_4 4 <-> Living room_5", "Kitchen_ <-> Hallway 6", Kitchen_4 4 <-> Bathroom 7", "Kitchen <-> Laundry room room_ 8", Baaiin__roo______ <-> Hallway_6 6", "Living room 5 <->
{"id";
Nounge_Maiting__ont 9", " <-> Entryway_Poyer_10" Hallway_6 <-> Laundry_room_8" "Hallway_6 <->
Lounge_Waitingg Room__ "Hallway_6
Entzyway_Poyer_100 "
Hallway 6 <~> Bedroom 11", "Hallway_6 <-> Bathroom 12",
Bathroom_12 12 <>> 13"), "item": [[ [["region": "Bedroom_ 1", asset": ("bed", Sooffee_tble"" "door"], "object": ["vase", ottoman", "Iamp")I, ("region"; "Bathroom 2", "asset"; ("
Bacbrroom_cunteer "sink", Batthroom_cabbneee
"object"; 1"
shower_cabing "rug", "Hamp")1, ("region"; "Kitchen 4", "asset"; ("dishwasher", "oven", "stove"], "object": ["flower", "flower_vass vase "bowi"]j, ("region": "Living_room__"" "asset": : ["shelf", "couch "tv"], "object"; ("magazine", "box", "cushion"]), ("region": Hallway 6", "asset"; ["door"], "object": " I'lamp", "vent", "rack "1,, ("region": "Bathroom 7", "asset"; ("toilet", "toilet "toilett_aperr; "sink"), "object": ("towel", "soap dish", "dustbin"]), ("region". "Laundry_roaae pood____rooo_____ 8", "asset": ("counter", "door", "bench"), "object":
32

---

Published as a conference paper at ICLR 2026
("basket", "coat_hanger", "Iamp"]), ("region":
Room______ "asset": [Mchair", "table"i, "object": [" flower_ vase", "rack", "flatware" /"region": "Entryway Foyer_10 "asset": ("door", "table"), "object": ("lamp"I), ("region": Bedrocm_ "asset": ("door", "bea", "dresser"), "object": [" plant", "lamp", "box")), ("region"; "Bathroom_i2", "asset"; [" coubbrorm_ccuterr", "toilet", "tollet_paper",, "object"; [" shower_hanale", "rug", "towelbbar"],, ("region"; "Bodroom_13", asset": ("nightstand", "door", "bed"), "object": ["rug", "vent", lamp"]i])}
single agent task: ("phase_l; ("Singie robot start position": {"
robot_1": "Bedroom_1"/ "Singie robot target object position"; 1" robot_1"; 23""), "Target object": "rug", "Single robot end position": ("robot_ 1"; "Bathroom "Single robot travel path": Kichen_4", "Kichen_4 -> riving_ Saiiving_roo__5 -> Hallway_5", "Hallway_6 -> Bathroom_12", Sathroom_ 12 -> vedroon_13", "Bedroom_13 -> bathroom_12",
("robot_1": ["Hedroom_]
Bathroom 12 -> Hallway_6", "Hallway_6 ->
room_5",
Living roong_rro______
Kichen_ "Kichen_ Bedroom_1" 1", "Bedroom_ ->
Sathroom_ 22arroom__"_,, "Task instruction"; "Take the rug in bedroom to the bathroom counter in Bathroom, "}}
OUTPUT:
"phase 2":
"collaborative robot start region";
"robot_1": "Bedroom_1",
"zobot_2"; "Hallway_6"
},
"Gollaborative type": "Type-Al",
"Transfer region": "Kitchen_4",
"Subtask instruction": I
"robot_1", "Take the rug from shelf in Kitchen to the bathroom counter in Bathroom. ",
"robot_2"; "Take the rug bedroom to the shelf Kitchen. " b
"Subtask list": {
"robet_1",
"Move_to (nreettoosseeeee ('shelf_4')",
"Grab('rug')
"Move_to [bathrrom_ccuuter_22
"Release (' ('rug')"
"robot_2": "Move_to "rug_1"'""
"Grab ('rug') "Move_ to ('ssheii_4")
"Release ('rug')"
}
A.11.2 SKILL FUNCTION
def check_collab
robet_ /orgi___
3
transfer_nodes,
4
transfer_asset,
collab_type, sclo_cost, rI rl_ncdes,
33

---

Published as a conference paper at ICLR 2026
target_nodes, nodes,
end_nodes, reglon_objects,,
10
G)
r2 i2_ne = cluster_ cusster_eetter_nodel troooottttttoo "tttboot___regiionn split ("_") [-11,
nx.nodes (G), nx.get_ (G, 'position'))
14
if =o_ns = None: return I"efficient"; Falsel
print (" ("r2_nodes:", r2_nodes)
18
if transfer_nodes:
print ("trattteraasssseeeeeaaa ", transfer_assen asset)
transfer transfer_asser asset pos find Seargge_positton (region (region_objects) objects, [-1],
if transfor_asset_pos != Nene:
transfer_nodes,
nerres_nappoinn____eeeeeettteeee (transserr_ _assefeer_ssse_ppss_.__
'_ #ttransfer_nodes.splittt 'position'))
nx.nodes (G),
wwt.anoottttttttttteeeeeen ("transter_"*tteeeentt "ttarretttttttansttrsssseee G,
transfer_ pos, transfer transfer_noder "transfer_"ttranseer
"tw.aaseetetrrt.eee asset
26
if transfer_nodes !- Nene: print ("transfer_nodes" transfer_nodes)
else:
return ("efficient"; False)
else:
return ("efficient"; False)
else:
return ("efficient"; False)
36
if collab_type =- "Type-A1":
try:
r2 to target sw.stettest_pa l length (G,
cource=r2_nodee
target=target_ nodes, weight=\weight")
except ww..ottorkMMoatth nx NoddeNoFFFuudd return ("officient"; False)
44
try:
target_to_transfer sx.ssttttst__atth_ Leattthh_enghhhe
source-target_nodes,
49
target-transter_ndee,
weight=/weight")
except (nx, Nww.tttorkkNo nx NondNoo return ("efficient"; False)
robot2 first leg = r2 to target + target to to_transfer
try:
rltootrrasser nx ox.shortest__ptt__engggg (G,
58
scurce-r1_nodes, target-transfe__ndde,, weight=''eeight
except www.NettokkXWoathh NodeNNooo))))))) return ("efficient"; False)
parallel leg = max (robot2 first leg, r1 to.tsseerr)
34

---

Published as a conference paper at ICLR 2026
try: transfer_to_end nx. w.sherttsss_paatllooggtti soureetransfer_nddes,, target=end_nodes,
68
except www.NetworkKNoPahh, No.NNNNNotoo return ("efficient"; False)
72
73
past = parallel_leg + cranster_to_ent r1 carallel__ost tortnsrrass transter_to
77
path_infor
78
"r2_to_target": r2_te_target,
"target_te to "oo_transeer" target to transfer, srobot2_first_les rebet2 firstt__frsste____ #=l_to_transte
82
"parallel_leg": parallcl_leg, "cransfer_to_ond"" transfor_to_ond, "type": collab_type
print ("g_rate: ", g_parallel_cost / solo_cost) print ("rl rate: ri_parallel_cost / solo_cost)
return
"glefficient": g_parallel_cost < solo_cost, "rl_efficient"; rl_parallel_cost < solo_cost, "efficient"; True if g_parallel_cost sclo_cost rl_parallelcoos solo_cost else False, "g_rate": g_parallel_cest solo_cost, "rl_rate"" rl ri_parallel_cost / solo_cost, 'path_info'; intor
99
100
elif collab_type -- "Type-A2";
101
try:
103
$1_to_targe shrrtetsest_path length (G, scurce=rl_nee nodes,
104
105
podeearrree__ddes,eeeeeee nodes, weight-\weight") except ww..httorkMMoatth nx NoddNotFooundd return ("officient"; False)
target=target_non
107
108
109
try:
target_to_transfer sx.ssttttst__atth_ heatchhheeghhhheee
112
source-target_nodes,
113
target-transter_ndee,
114
weight=/weight")
except (nx. Nww.tttorkkwo nx. NondNNo return ("efficient"; False)
117
118
rebotl_firie first leg = rl to target + target to.transfer
try:
121
re-to_transfer nx sheshrttssst__ath_lnngggg (G,
122
scurce-r2_nodes, targetttransfe__odde,, weight=''weight
123
except www.NethorkXWoath, NodeNNooo))))))) return ("efficient"; False)
126
127
128
parallel leg = max (robot1. first leg, r2 to.tsseee
35

---

Published as a conference paper at ICLR 2026
try: transfer_to_end
131
132
sourcetraanser_nodde,,
133
target=end_nodes,
weight='weight'")
except www.NetworkXWoPahh, nx.NodeNotPound)
136
return ("efficient"; False) False)
137
138
pasa = parallel_ Leg + transfer_to_ent
r1 past tl_to_target target_to_transter
141
path_infor
142
143
to "t target to transfer,
srcbotl_first_lee rebetl_ first_leg,
145
[r2_to_transte #2_tc_transsee
146
"parallel_leg": parallcl_leg, "transfer_to_end"; transfor_to_ond, "type": collab_type
147
150
151
print ("g_rate: ", g_parallel_cost / solo_cost) print
152
ri_parallel_cost / solo_cost)
154
return "glefficient": g_parallellcostt < solo_cost, "rl_efficient"; rl_parallel_cost < solo_cost, "efficient"; True if g_parallel_oost sclo_cost rl_parallelcoot solo_cost else False, "g_rate": g_parallel_cost solo_cost, "rl_rate"; rl ri_parallellcost / solo_cost, 'path_info'; intor
155
156
158
139
160
162
163
else:
164
return
165
"effigient": False
36

---

Published as a conference paper at ICLR 2026
A.12 PROMPTS FOR GRAPH CONTEXTUAL TYPING
Room Type Reasoning
System:
You Al assistant that specializes in spatial reasoning and semantic scene understanding. Your task infer the most likely type room (e.g., Bedroom, Bathroom, Kitchen, Laundry room, Living room, Hallway, Tie, Balcony, Terrace, etc.) based on the provided contextual clucs.
Rules: There are two part of the input: neighbors and objects. The neighbors part includes information about the number and lypes of adjacent rooms. This gives spatial and functional context, which helps The objects part lists the items found in the unknown room. These object types frequencies are strong indicators of the room's function.
down the likely of the unknown
When inferring the type of unknown recm, your reasoning must be + guided by both the semantic distribution objects and the spatial context of neighboring rooms.
Always prioritize distinctive, functicnally indicative objects generic decorative ones.
Use neighboring room types to constrain plausible options (e.g., a room between two Bathrooms is unlikely to be Kitchen).
Avoid inferring ambiguous multifunctional rooms unless object
diversity strongly supports it.
Room type must be one from the predefined category list (e.g.r
4 Bedroom, Bathroom, Kitchen, etc.).
In cases where the object 1ist is sparse, weigh neighbor consistency more heavily. **"
9 Below is the full list of supported room types, each with a brief description of its primary function.
Bedroom used for sleeping and personal rest.
12
Bathroom supports hygiene tasks like bathing and toileting.
13
Kitchen I designed for cooking and food preparation.
14
Dining Room
place for eating meals, often next to the kitchen. Living Room used for leisure, social interaction, or entertairment.
16
Study / Office | workspace for reading, writing, or computer use. Laundry Room contains appliances and tcols for washing clothes.
17
Closet / Storage Room used to store clothes, tools, househcld items.
19
Hallway Corridor I connects other rooms; mainly transiticnal.
20
Garage I for parking vehicles or storing tools and equipment.
Kids Room / Nursery
bedroom tailored for children, often with
toys.
Halcony Terrace
semi coutdort area for air, light, or drying,
Media Room / Home Theater equipped for movies or audio-visual b activities.
Gym / Fitness Room | contains equipment for exercise and physical training.
Library 1 a quict space for reading or storing books. Meeting Room a formal area for group discussions or prescntations,
26
Lounge / Waiting Room rest area in public or semi-publis buildings.
Pantry / Bar compact space for storing serving drinks/snacks Dressing Room dedicated to changing clothes or grooming.
29
30
Entryway Foyer the front entrance space where people enter the hone
**"
Output format constraints: #""
33
Only output the final predicted room type.
The output must be a single Python dictionary with the format: ('Unknown room type": "<Room Name>")
37

---

Published as a conference paper at ICLR 2026
NOT include any reasoning, explanation, analysis the output.
4
38
Do NOT output multiple room types or probabilitieslomg lonly the most likely one.
Do NOT incluce any commentary, bullet points, markdown formatting.
40
Here is an example of the INPUT and OUTPUT:
INPUT:
neighbors: "There are neighboring rooms, belonging to type, including 2 Kitchens."
-
objects: "The unknown room contains 77 objects, belonging to 30 types. The top most trequent items are: 22 photos, 11 chairs, plants, vases, and shelfs."
OUTPUT:
["Unknown type": "Living room")
30
A.13
ABLATION FOR PROMPTS
A. 13.1
DIRECTLY TWO-AGENT TASK GENERATION
V1 and 12 demonstrate the following shortcoming
Single Robot Start Position:
Target Object Location:
Desination Position:
Transfer Region:
Robot 2 Start Position:
Single Travel Path
Collab Travel Path
00324-DaSbsoo4E.g
Single path efficient plan, and the generated collaboration path useless.
Figure 17: Common failure case of directly generating a two-agent task.
In fact, the initial versions of CoNavBench were exactly based on directly generating two-agent tasks, as you suggested, and our current "single-agent task then split" pipeline the result of several iterations driven by empirical observations. Concretely, we implemented and tested three major versions of the data- tata-gennratiin pipeline on fixed test set of HM3D environments (00087- V68r,, 00099-bbpp) Xew.--ddd.EEEEWW.......
XNEdvmW, H0323-yHHLr6bwssVm
D0S24-DoSbsoo4EAg. 00444- to allow controlled comparisons under identical prompts.
sX9xad6ULKe, 00612-GsQBY8BI However, after extensive testing, we found that both and V2 suffered from very low-quality multi-robot collaboration, mainly due to the difficulty of long-horizon spatial reasoning with two agents at once. Typical failure modes included: D) Little or no true parallelism: the LLM often pro- duced plans where robot did almost all the work while the other remained idle, so executing the plan with a single robot sequentially was actually more efficient, as shown in Fi II) Inconsis- tent invalid coordination: mismatches between the transfer region and the subtask descriptions,
38

---

Published as a conference paper at ICLR 2026
missing handover steps, paths that did not align with the scene layout. Hence, motivated by these observations, we adopt the two-stage NavCraft design. We have added this discussion in the Supplements Section for more details.
Directly Two-agent Task Rule Prompt Version
Important rules regarding the scene graph:
You must leverage the scene graph topology to design meaningful multi-robot cooperation.
4
The connectivity between regions (provided in the "link" field of the scene graph) must be used to ensure:
Robots do not start adjacent regions.
Task handoffs (e.g., object relay between robots) happen in regions that are connected.
The selection of regions and object transter paths should reflect realistic spatial planning based the graph.
Encourage designs where the first robot delivers an object to an + intermediate node (transfer zone), and the second robot continues from there. This creates natural cooperation patterns.
There something you need pay attention to:
12
A robot should not start in the same region where it needs to pick drop off objects.
Each robot contribution should reduce the overall task cost:
Avoid assigning tasks that could be completed more efficiently
by single robot.
15
Only use multi-robot handoff when it signi significantly reduces travel distance or enables parallelism.
The multi-robot plan you generate should not be less efficient than single-robot plan for the same task. Cooperation should lead to either reduced execution time or more balanced workload acress agents.
4
The objects involved must be portable and must appear in the input scene.
18
The task must involve only to different regions.
19
The region IDs (e.g., "Kitchen_1" _", "Bedroon_3") do not imply spatial proximity connectivity. Only the "link" field in the scene graph provides valid region-torreiion connections. Do not regions with similar names or IDs are connected.
20 The full task must contain 4 to subtasks total (across all robots).
The task you generate should be similar instrustions like "Take an object one region to a certain place in one region." Subtasks must follow logical ordering: robot must Move before Grab or Release; it cannot Release without having grabbed the object first.
The region mentioned in Move_to() should match the region mentioned + the high-level instruction.
24 The task must reflect multi-robot cooperation, such as transporting an object to a place where another robot picks it up and continues.
Do
low-level action terms like "grab", "release", "move_to" "Task instruction" or "Subtask instruction".
26
Your output should be Python dictionary with the following keys: **p
"Robots position": A dictionary assigning each robot to starting region. Each robot must start in a different region, and the regions must be at least one hop apart in the scene graph.
+
"Task instruction": A conversational high-level instruction describing the overall collaborative task.
39

---

Published as a conference paper at ICLR 2026
"Taansfer position": 1ist of intermediate regions (e-g., region IDS) that serve as kwhandover zones** between robots. These positiors should be selected from the scene graph and must be reachable by both the sender and the receiver robot. Use them to support collaborative efficiency: for example, Robot may carry an object from Region to transfer position, where Robot picks it up and delivers it to the final destination, when solecting a transfer position, prefer regions that minimize the total travel distance between participating robots.
"Subtask instruction": dictionary giving each robot
+ natural-lanquage description of its individual role in the task. Avoid technical terms like "grab" or "release".
SSubtak iist": A dictionary mapping each robot to 1ist of Low-level subtasks. These subtasks should be composed of the following actions:
34
region. The "object_region_it walk to an object or location in a must combine the object name and its region ID from the input scene (e.g., "lamp_1"). Grab ("object"): Pick up the object. The robot must first
+
to * the object 's location. The object must exist in the "objects"
+ 1ist of the input scone.
36
Release ("object"): Place the object in the target asset or location. The robot must first move to the target. The object exist in the input scene.
37
38
Make sure the task instruction conversations onall enough, and the task should reasonable.
Directly Two-agent Task Rule Prompt Version
Important rules regarding scene and task planning:
Use the region connectivity graph ("link") determine all mevement and transfer feasibility.
Robots must start in *Adifferent**, asnon-adjacent. regions.
A robot cannot start in the same region where it will pick up or drop off an object.
Task handoff must happen in region reachable from both the sender and receiver.
A robot must Move_to a region before performing Grap or Release. A robot must Grab an object before it can Release it. The region speci fied in Move_to() must match the one impl ied in the instruction (no teleportation).
10 Subtasks must follow this logical order: Move Release.
Grab Move
The objects involved must:
Be listed in the input scene's "object" field (i.e., exist and be
4 portable).
13
Be manipulated *only**, not asscts.
14
Subtasks must not violate logical flow or act on unavailable objects/assets.
The overall plan must involve sx1 regions total** (e.g., task origin, destination, or transfer area).
4
16
Tasks must be split into **4 to total low-leved sustasksre, across
all robots.
Task planning should reilect genuine cooperation:
Prefer paralleliam or reduced path cost through collaboration.
19
Avoid plans where a single robot could complete the task more
4 efficiently.
Multi-robot plans A not be less efficient than single-robot alterratives.
40

---

Published as a conference paper at ICLR 2026
The must exhibit **expicii callaborationns, such robot_]
+ transporting an object to an intermedi location, and robct_? completing delivery.
Avoid assuming proximity based region name:
Region IDs (e.g., "Kitchen_1" 1", "Kitchen_2" **do not imply spatial adjacencyxx.
24 Use only "link" data to determine connectivity.
Task instruction and subtask instructions should:
Be natural-languel
(e.g., "Take the object from to B"). **Avoid technical terms** like "grab", "release", or "move_to".
29 Region Symbol Definitions (used in output and reasoning):
Region Initial position of robet_1
Region_R: Location of the portable object
33
Region_X: Handoff region (object relay from robot_1 to robot_2)
34
Region_Y: Initial position of robot_2
Region_C: Final destination for object delivery
"*"
37
Spatial Constraints:
38
Region_A and Region_X must NOT be adjacent.
Region X and Region must NOT be adjacent.
Region X and Region
NOT be adjacent.
42 Among Region_A, Region_X, Region_Y, and Region_C, Region_B must be
the closest to Region_A based on the region connectivity graph (i.e., shortest path length from Region_A).
Among Region Region Region
and Region B, Region must be the closest to Region_ Y based on the region connectivity graph (i.e., shortest path length from Region_ Y).
Output Format: =*"
48
"Robots start position": ("robot_1": "Region_A", "robot_2".
"Region_Y" y") "Transfer position"; "Region_x".
"Robot travel path";
51
"robot_1"; ["Region_A -> Region_ B", "Region -> Region_X"]
52
"robot_2": ["Region_Y -> Region_X", "Region_x -> Region_C"] },
"Task instruction: "rake the [object[8] from Region_H lasset_Co CI in Region_C.",
"Subtask instruction":
"robot_1"" _"; "Take [object_B] in Region to the [asset_X] X] in Region_X.",
"robot_2"M "Take [object_B] from [asset_X] in Region_X to the
- [asset_C] in Region_C."
58 b.
"Subtask list": {
"robot_1"; ("Move_to("objatt__u "Move_to (o'ss_ttoaasse__8"") "Release ('object') "),, "robot_2": to
"Grab('object)
61
(Grab("object Woove_tolf "', "Release ('object')
#n"
Output field explamation:
"Robots start position": Dict mapping each robot to its starting
region (must follow spatial constraints).
"Transfer position"; Region ID (or 1ist of region IDs) where object 68
is passed from robot_1 to robot_2.
41

---

Published as a conference paper at ICLR 2026
"Robot travel path"; Dict showing robot movement as ordered region-to-region transitions.
70
"Task instruction" Natural description of full task.
delivery
Subtask instruction"; A dictionary giving each robot natural-language description of its individual role task, Avoid technical terms like "grab" or "release".
"Subtask 1ist": Dict of robot action sequences using these primitives:
Grab("object")
15
Release ("objectt)
Maxe the task instruction conversational enough, and the task should reasonable.
42


Reviews:
[{"review_id": "geyTAwZxx4", "reviewer": "Reviewer_cERd", "summary": "The authors introduce CoNavBench, a new benchmark for \"Collaborative Long-Horizon Vision-and-Language Navigation\" where multiple robot agents collaborate to follow instructions inside 3D simulated homes (using Habitat-Sim). They introduce Navcraft, an algorithm to generate these multi-robot cooperation scenes where agents share and hand off subtasks. It contains 4048 episodes annotated with scene graphs, but more can be generated by Navcraft. Navcraft uses a two-stage hierarchy, Navcraft-S and NavCraft-C, to first generate a single-robot task, then break it down into a two-robot collaborative task, with graph-based scene understanding and validation. The authors fine-tune Qwen2.5-VL models on this benchmark, reporting improvements over single-agent baselines.", "questions": "- Can the author expand on how do the results vary based on the chosen collaboration type (A1 vs A2) ? \n- How does this approach (generate single-agent task then split) compare against directly generating a two-agent task? \n- Authors report using two robots for the task instead of a single one improves performance. This can be explained by each robot being able to learn its task more efficiently. Do the authors believe this difference would disappear with SOTA large language models?", "limitations": "", "rating": 6, "confidence": 3, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "This is a novel benchmark for robotic cooperation in 3D home environments. The proposed mehtod can generate an arbitrary number of scenarios. The paper presents a clear and interesting pipeline (NavCraft-S and NavCraft-C) for task creation, graph annotation and validation. It is overall clear with illustrative figures. The authors use standard metrics for measuring performance on the benchmark, and provide a thorough baseline and ablation analysis with various LLM APIs.", "weaknesses": "- The benchmark, while innovative, is still limited to two agents and specific relay-style tasks (one robot carries something from A to B, hands it off to a second robot to carry it from B to C). Dynamic collaborations are not explored. \n- NavCraft relies on proprietary LLM APis for data generation, which can lead to issues for reproducibility of the benchmarking. This limitation is addressed by the authors. \n- Some parts are dense in formulas and could benefit from a high-level intuitive explanation beforehand.", "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": "vyirJddCbK", "reviewer": "Reviewer_7PLf", "summary": "The paper introduces CoNavBench, a collaborative long-horizon Vision-and-Language Navigation (VLN) benchmark designed to study multi-robot cooperation under language-guided tasks. It extends prior single-agent datasets by supporting multi-agent task decomposition, handoff scheduling, and rendezvous-based cooperation. To generate the data, the authors build NavCraft, a graph-grounded generation platform with semantic scene graphs, hierarchical planning agents (NavCraft-S / NavCraft-C), and an on-graph efficiency tool library for validation and optimization. Experiments demonstrate reduced makespan and improved step-level success over single-agent baselines using Qwen2.5-VL policies.", "questions": "1. Could authors provide more clear visualization results to clarify the claims, for example, how Figure 9 contributes analytically, whether it reflects convergence stability, mode collapse, or loss behavior differences between different models?\n2. Are there plans to improve qualitative visualizations to more clearly demonstrate cooperative efficiency or multi-agent coordination?\n3. Have you analyzed how different prompt templates or role-conditioning strategies affect the generated tasks’ diversity or validity?\n4. Is there any plan to evaluate NavCraft or CoNavBench tasks on real robots or real-world scans to assess practical applicability?", "limitations": "", "rating": 4, "confidence": 2, "soundness": 3, "presentation": 2, "contribution": 3, "strengths": "1. CoNavBench provides a large-scale benchmark (4048 episodes) covering both single and multi-robot navigation with rich annotations for collaboration types and performance metrics.\n2. The proposed NavCraft system establishes a structured data-generation pipeline grounded in semantic graphs, incorporating task synthesis, collaboration lifting, and efficiency validation, which enhances data consistency and scalability.\n3. The framework introduces a useful utility for checking reachability, congestion, and timing constraints directly on scene graphs, which is a practical contribution for large-scale synthetic task design.\n4. The manuscript provides dataset statistics, training configurations, and baselines clearly, allowing others to replicate and evaluate under consistent protocols.", "weaknesses": "1. Visual clarity is not acceptable at all, for example, Figure 9 is difficult to interpret and provides almost no new information beyond stating that the training loss decreases. It lacks analytical insight and does not meaningfully support the main claims. The visual examples fail to illustrate collaborative interaction or path optimization clearly. Comparisons are blurry or incomplete. An example is the visualization of collaborative cases, the authors didn't provide any useful information in these cases to support the claim.\n2. While the data-generation pipeline heavily relies on prompt engineering for NavCraft, there is no systematic or theoretical analysis of its design choices, prompt sensitivity, or ablation, leaving uncertainty about robustness.\n3. The entire framework and experiments are conducted in simulation (e.g., Habitat-3). Although acceptable at this stage, no real-world experiments or transfer evaluations are included to verify deployability or generalization.", "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": "tIpwxv50jo", "reviewer": "Reviewer_UuGT", "summary": "1. CoNavBench Benchmark: It includes 4048 single-robot and multi-robot collaborative tasks, designed to test how robot collaboration can optimize task completion time and improve efficiency in long-horizon tasks.\n\n2. NavCraft Platform: An automated data generation platform for collaborative tasks that uses the scene graph from Habitat-Sim to create semantically rich environmental layouts and generate collaborative tasks. It includes two stages of task generation: NavCraft-S (for generating single-robot tasks) and NavCraft-C (for generating collaborative tasks).\n\n3. Collaborative Models and Performance Evaluation: Experiments using the Qwen2.5-VL-3B model show that the collaborative model improves step-level success by 18.11% and reduces task completion time compared to the single-robot model.", "questions": "same as weakness.", "limitations": "", "rating": 4, "confidence": 3, "soundness": 3, "presentation": 2, "contribution": 2, "strengths": "By introducing multi-robot collaboration, the CoNavBench benchmark optimizes the completion time of long-horizon tasks. Compared to single-robot tasks, collaborative robots can perform multiple subtasks simultaneously, effectively reducing task delays and idle time, significantly improving overall task efficiency. The CoNavBench benchmark includes 4048 single-robot and multi-robot collaborative tasks, providing a comprehensive evaluation of collaborative navigation systems in complex tasks. It tests how robots coordinate and distribute tasks in scenarios where multiple robots work together.", "weaknesses": "1. The inference speed of large models is very slow; will there be a significant delay in task completion?\n2. Will the two agents collide in the environment?\n3. There are many VLN methods based on large models [1]; why were they not compared with these methods?\n4. Are the initial positions of the two agents the same, or is one agent directly summoned?\n\n\n\n\n[1] Cheng, An-Chieh, et al. \"Navila: Legged robot vision-language-action model for navigation.\" arXiv preprint arXiv:2412.04453 (2024).", "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": "uZTkShLjBY", "reviewer": "Reviewer_wsr9", "summary": "This paper introduces CoNavBench, a large-scale benchmark designed to evaluate collaborative vision-and-language navigation (VLN) under multi-agent, long-horizon settings. The authors further propose NavCraft, a graph-grounded data generation and validation platform that constructs semantically annotated scene graphs, generates single-agent base tasks (NavCraft-S), and lifts them into collaborative multi-robot schedules (NavCraft-C). The experiments use Qwen2.5-VL-3B/7B models fine-tuned on the dataset, demonstrating improved performance over single-robot baselines and validating the benefit of collaboration in task success and path efficiency. Overall, this work establishes an interesting benchmark for multi-agent embodied navigation by unifying data generation, simulation, and evaluation.", "questions": "Besides the weakness mentioned above, the reviewer has some extra questions below:\n\nHow does the benchmark handle multi-agent interference and collision during simulation? Are these events explicitly annotated or only indirectly measured by task failure?\n\nCould the authors provide a quantitative comparison between NavCraft-generated and manually designed tasks to justify realism and linguistic fidelity?\n\nWhy does the Qwen2.5-VL-3B outperform 7B in several collaborative tasks? Does this stem from optimization saturation or data scarcity?", "limitations": "", "rating": 6, "confidence": 4, "soundness": 3, "presentation": 3, "contribution": 3, "strengths": "The paper convincingly identifies a major gap in the VLN landscape: the lack of standardized evaluation for multi-agent, cooperative scenarios, and fills it with a well-structured benchmark and taxonomy.\nNavCraft’s design (scene-graph generation, task validation, and efficiency tools) is technically detailed, modular, and reproducible within Habitat-Sim, enabling scalable and context-aware task generation.\nThe framework successfully merges semantic graph annotation, spatial reasoning, and LLM-driven language prompts to produce feasible, diverse, and verifiable tasks.\nFinetuned Qwen2.5-VL models show consistent improvements in SR, SPL, and CSR across both single- and multi-agent settings, confirming the utility of CoNavBench for training collaborative policies.", "weaknesses": "*Limited collaboration scope*\n\nOnly two fixed handoff types (A1, A2) are explored, which may not fully capture the diversity of real collaborative behaviors (e.g., concurrent exploration, dynamic task reassignment).\n\n*Data generation*\n\nThe dependence on GPT-4o-mini and closed APIs limits long-term reproducibility; no quantitative analysis is provided on the variability or bias of generated instructions.\n\n*Lack of detailed time-efficiency evaluation*\n\nAlthough collaboration is claimed to reduce makespan, this paper needs more clarification on collaboration acceleration and time-based metrics.\n\n*Incomplete ablations for important modules*\n\nComponents such as the memory-aware mechanism, efficiency tool library, and profile-conditioned sampling are presented but not individually quantified in their contributions.", "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)