Reviewed by Pith at T0; open to challenge.

Referee: §3.2 and Abstract: The central claim that the architecture is a 'viable, cost-efficient alternative to cloud-dependent deployments' with 'strong potential for real-world transfer' is not supported by the evidence presented. The only quantitative result is the fine-tuning improvement for box-condition annotation (F1 0.755 to 0.915), which evaluates a single sub-component. No task-level success rates, latency benchmarks, or failure analysis are reported for any of the five task categories (T1-T5). The authors should either (a) provide quantitative task-level performance metrics across the task categories, or (b) substantially soften the claims to match the evidence.

Authors: The referee is correct. The current manuscript does not present end-to-end quantitative task-level metrics, and the headline claims in the Abstract and Conclusion are stronger than the evidence supports. We will adopt option (b): revising the Abstract, §3.2, and Conclusion to frame the work as a feasibility demonstration rather than a validated system. Specifically, we will replace 'Results demonstrate that a fully onboard MAS architecture is a viable, cost-efficient alternative to cloud-dependent deployments' with language such as 'Results provide a feasibility demonstration of a fully onboard MAS architecture on edge hardware, with component-level evaluation of the fine-tuned inspection VLM.' We will also revise the Conclusion's claim that 'Success across all five task categories justifies real-robot trials' to accurately reflect that the system was exercised across all five categories in hardware-in-the-loop simulation, but was not subjected to systematic quantitative evaluation at the task level. We will add a candid limitations paragraph stating that task-level success rates, latency benchmarks, and failure analysis are not reported and constitute necessary future work before real-robot deployment. We note that the fine-tuning result (F1 0.755 to 0.915) and the open-source release remain genuine contributions, but we agree they do not substitute for end-to-end evaluation. revision: yes

Referee: §1, paragraph 2: The paper claims the system is 'capable of real-time response.' No latency or timing measurements are provided anywhere in the manuscript. For an edge deployment with a 3B-parameter VLM, inference latency is a critical feasibility concern. The authors should report end-to-end latency and per-agent inference times, or remove the 'real-time' claim.

Authors: The referee is correct that no latency measurements are reported and that the 'real-time response' claim is unsupported as written. We will remove the phrase 'capable of real-time response' from §1. We can provide approximate per-agent inference times from our development logs (e.g., VLM inference on the AMD Ryzen AI mini PC for the Inspection and Safety agents), but we have not conducted systematic end-to-end perception-to-action latency measurements across all agents and task categories. Rather than report informal timing figures that could be misleading, we will remove the real-time claim and note in the limitations that systematic latency benchmarking is needed and is planned as part of the quantitative evaluation in future work. If the referee considers approximate per-agent inference times useful even with the caveat that they are not systematic, we can include them as a supplementary note. revision: yes

Referee: §3.1, Inspection Agent: The agent 'obtains the 3D pose from simulation ground truth.' This creates an unstated dependency on information that will not be available in real-world deployment. The claim of 'strong potential for real-world transfer' is undermined by this dependency. The authors should explicitly acknowledge this gap and its implications for the transfer claim.

Authors: We agree. The Inspection agent's reliance on simulation ground truth for 6-DoF pose estimation is a genuine limitation that should be stated explicitly. In a real deployment, a perception pipeline (e.g., depth-based pose estimation or foundation-model-based 6-DoF pose estimation) would be required, and its performance would affect the overall system behavior. We will add an explicit acknowledgment of this dependency in §3.1 and note in the Abstract and Conclusion that the 'strong potential for real-world transfer' claim is qualified by the fact that pose estimation currently depends on simulation ground truth. We will also soften the transfer claim itself to 'potential for real-world transfer, contingent on replacing simulation-derived pose estimation with a real perception pipeline.' revision: yes

Referee: §3.2: The demonstration section is written in future tense ('attendees will be able to interact,' 'the demonstration will run'), suggesting the system has not yet been demonstrated at the time of writing. If the system has been tested, the authors should report what was observed. If it has not, the framing should be clarified as a proposed demonstration rather than a validated system.

Authors: The referee correctly identifies an inconsistency in framing. The system has been developed and exercised in hardware-in-the-loop simulation during development, but the §3.2 text is written as a demonstration proposal (future tense) because it describes what will be shown at the conference venue. We will clarify this: we will reframe §3.2 to distinguish between (a) what has been observed during development and testing of the HIL system, and (b) what attendees will experience at the live demonstration. We will add a brief qualitative summary of what was observed during development (e.g., the system successfully executed navigation, manipulation, inspection, and safety-monitoring workflows across the task categories), while being explicit that these observations are qualitative and that systematic quantitative evaluation has not yet been conducted. This is consistent with the revised framing as a feasibility demonstration. revision: yes