Skip to content
#edge computing Open access

Agentic Mission Orchestration for Agricultural Robots: Source Code and Support Data

Sep 2026 · Zenodo (CERN European Organization for Nuclear Research)

Abstract

The following material supports the article Agentic Mission Orchestration for Agricultural Robots: Coupling Agronomic Validity, Edge AI Reliability, and Data Governance, submitted to Precision Agriculture (Springer Nature). This deposit corresponds to the first revision (R1) of the manuscript and supersedes the material deposited for the original submission. The archive holds 487 files. Contents agents/: 10 modules, comprising the orchestrator, the five specialist agents, the monolithic single-prompt baseline, the deterministic rule engine, and the resource-matched baseline conditions. prompts/: the 11 system prompts used by the agents and by every baseline condition. data/missions/: 23 mission specifications, covering M1 to M6, the held-out missions H1 to H4, and the test missions T1 to T10; earlier variants of T1 to T3 are retained under a .v1 suffix. data/agronomic_kb.yaml and data/capability_registry.yaml: the agronomic knowledge base and the capability registry. eval/: the scoring code, the ground truth, and the per-run records, aggregated scores, and summaries for every reported condition. Five entry points at the archive root: run_orchestration.py, run_monolithic.py, run_rule_engine.py, run_baseline.py, and run_b1_matched_pilot.py. Where each reported result comes from Section 5.1, conditions and models → agents/, prompts/, run_orchestration.py, run_monolithic.py Section 5.2, mission scenarios → data/missions/ Sections 5.3 and 5.4, metrics and component-wise scoring → eval/score_v3.py, which contains the rule-based semantic-equivalence table Table 4 → eval/results/v2/eval_summary_v3_component_M1M4.md Section 5.5, deterministic and hybrid baseline → agents/rule_engine.py, eval/results/rule_engine/, eval/results/rule_engine_t/ Section 5.6 and Table 5, agent-order sensitivity → eval/results/b5_permutation/records/, 10 run records Section 5.7 and Table 6, held-out evaluation → data/missions/H1 to H4, eval/results/held_out/, 32 run records Section 5.8 and Table 7, compute-matched baselines → agents/baseline_conditions.py, eval/results/b1_same_model/, eval/results/b1_baselines/ Section 6, Tables 8 to 11, and Figure 3 → eval/results/v2/, eval/results/frontier/, eval/results/smaller/ Ground-truth audit → eval/ground_truth.yaml Each run record carries a _meta block naming the model identifier used for that run and the observed client-side latency. What is not included Raw provider-response bodies and separately persisted retry and parsing-failure events are not part of this deposit, because the original runs did not record them. Observed latency includes API time and YAML-parse retry time, but individual retry events, provider queue time, and monetary cost were not persisted separately. These limits are stated explicitly in the manuscript rather than implied here. Files are under restricted access during peer review.

View source

Similar papers

#computer vision Review Sep 2017

Agile Software Development Methods: Review and Analysis

This publication proposes a definition and a classification of agile software development approaches and analyses ten software development methods that can be characterized as being "agile" against the defined criterion.

P. Abrahamsson, O. Salo, Jussi Ronkainen et al. · 727 citations · ⚡54
#computer vision Jun 2008

The impact of agile practices on communication in software development

The study shows that agile practices improve both informal and formal communication, but indicates that, in larger development situations involving multiple external stakeholders, a mismatch of adequate communication mechanisms can sometimes even hinder the communication.

M. Pikkarainen, Jukka Haikara, O. Salo et al. · 401 citations · ⚡48
#machine learning Review Open access Oct 2014

Software development in startup companies: A systematic mapping study

The results indicate that software engineering work practices are chosen opportunistically, adapted and configured to provide value under the constrains imposed by the startup context.

Nicolò Paternoster, Carmine Giardino, M. Unterkalmsteiner et al. · 394 citations · ⚡54

Related blog posts

Microsoft Research Blog Oct 6, 2026

What AI gets wrong and what failure teaches us

Jennifer Neville did not want to go into computer science—but that’s exactly where she landed. Neville discusses the starts and stops that led to her professional sweet spot and her work identifying “surprising failures” making it hard for AI to handle complexity.  The post What AI gets wrong and what failure teaches us appeared first on Microsoft Research.

We use cookies to run the site and, with your consent, for analytics and to show ads. See our Cookie Policy.