Source-linked AI summary
AstronOS: A Unified Execution Model and Runtime for Long-Horizon Agentic Systems
Zhenhang Nie, Gui Zheng, Xudong Sun, Tailong Zhu, Bin Zhang
TL;DR
Long-horizon agents need persistent, versioned work state across sessions rather than execution organized around a single conversation or invocation. This paper introduces AstronOS and finds higher pass rates for its runtime-mediated handoff on a three-stage benchmark, at a measurable time cost.
Problem
Long-horizon work outlasts conversations, creating a need to carry current, authoritative task state across changing steps and executors.
Method
The paper defines a persistent, versioned execution model and implements it in AstronOS through Cases, Tasks, and Scenario Packs with validated state commits.
Results
AstronOS passed 14/15 three-stage executions in the primary batch, versus 0/15 for rereading and 2/15 for full-history replay, with lower tokens per pass but longer execution windows.
Takeaways & Limitations
The tested AstronOS strategy is associated with higher scorer pass rates across fresh sessions on this staged decision-continuity benchmark, at a measurable time cost.
Takeaways & Limitations
Because the single-stage and three-stage families were not matched, the observed contrast does not estimate a causal interaction with task structure.
Abstract
from arXiv · showhide
Agentic systems often organize execution and state around a single conversation, model invocation, or agent instance, even when real work spans many calls and stages. We introduce a unified execution model that maintains a work item's persistent identity and versioned authoritative state across calls. Each step receives input scoped to a specific state version and new material; a result advances state only after validation and recording. We implement selected paths of this model in AstronOS using Cases, Tasks, and Scenario Packs across central and local execution. We compare five complete strategies for carrying an established software-version update plan into a fresh model session: rereading original materials, replaying full history, deterministic text summary, deterministic JSON, and the AstronOS runtime-mediated handoff. Ten controlled tasks are run under all five strategies with three repetitions, yielding 150 included executions. On the single-stage reference family, strategies perform similarly. In the primary three-stage A-C batch, AstronOS passes the frozen scorer in 14 of 15 executions, compared with 0 of 15 for rereading and 2 of 15 for full-history replay; later non-interleaved summary and JSON batches each pass 0 of 15. AstronOS has lower attempt-accounted model-token cost per passing execution, while requiring more execution-window time per attempt. These results associate the complete AstronOS condition with higher end-to-end pass rates across fresh sessions in this benchmark, at a measurable time cost.
1 Introduction · 2 Related Work
AstronOS introduces a unified execution model for long-horizon work that preserves versioned authoritative state across sessions and executors, then implements it through Cases, Tasks, and Scenario Packs. The related-work comparison distinguishes this continuity model from agent frameworks, durable workflows, memory systems, and existing benchmarks.
- 2.1 Agent runtimes and multi-agent frameworks: Existing agent frameworks organize execution around conversations, messages, roles, or event streams, which are convenient for short interactions but poorly represent multi-stage work.The paper positions AstronOS around persistent work-item continuity rather than an immediate interaction unit.
- 1 Introduction: Long-horizon tasks depend on state across steps, sessions, models, people, tools, and execution environments rather than merely long prompts or many model turns.The next executor must continue from the current task state instead of starting over.
- 1 Introduction: AstronOS gives each work item a persistent identity and versioned authoritative state, accepting candidate results only after runtime checks and formal recording.Each step receives scoped information, produces a candidate result, and can advance state only after validation.
- 1 Introduction: Cases retain confirmed work state, Tasks define bounded execution units, and Scenario Packs specify how work families are decomposed and advanced.These units support execution by models, people, or tools.
- 2.1 Agent runtimes and multi-agent frameworks: AstronOS differs from AIOS, StateFlow, and Agent Workflow Memory by treating one work item’s versioned accepted state across fresh sessions and heterogeneous executors as the continuity unit.AIOS centers an OS-style kernel interface, while StateFlow models states and transitions and Agent Workflow Memory retrieves reusable workflows.
- 2.2 Durable workflows and case-centered processes: The model composes versioning, compare-and-set, and validation through an auditable Prepare–Execute–Check–Commit sequence before candidate output changes official state.This composition draws on optimistic concurrency control while making preparation versions and candidate-to-commit relations explicit.
- 2.3 Long context, summaries, and agent memory: Unlike memory and summarization systems focused on retaining or retrieving history, AstronOS prepares each next step from checked and recorded Case content treated as official state.The later executor receives currently confirmed state rather than only fragments of the work’s history.
- 2.4 Long-horizon agent evaluation: Existing benchmarks emphasize executable environments, final-state checks, or long-session memory, whereas this benchmark scores end-to-end completion under five strategies for carrying structured decisions across fresh sessions.The comparison uses the same task material, model, reasoning effort, tools, and scoring rules, with fixed reference answers.
3 A Unified Execution Model
The unified execution model treats long-horizon work as persistent, versioned state that advances through scoped, validated steps rather than transient execution contexts. AstronOS composes this model around Cases and Tasks, using version binding and gated commit to preserve state integrity while reducing repeated reconstruction.
- Scope and entities: Long-horizon work spans multiple dependent steps, with later steps relying on state committed by earlier ones rather than duration alone.A three-step item completed in five minutes qualifies, while an hour-long batch of independent questions does not.
- Scope and entities: A work item is the enduring state unit identified by c, while steps and attempts represent state-dependent work and individual executor invocations.In AstronOS, work items and steps are instantiated as Cases and Tasks, respectively.
- Model boundaries: The model separates enduring work from executors, accepted state from history and candidates, step-visible views from full records, and outputs from committed transitions.Its contribution is the model-facing composition of persistent workflow, case-centered state, artifact lifecycles, and optimistic concurrency.
- Step execution: Each step binds a goal and newly available material to a base state version, with policy π_t governing preparation, acceptance, and updates.The step identity remains distinct from c, allowing many steps to contribute transitions to one work item.
- Step execution: Prepare–Execute–Check–Commit advances authoritative state only after validation and successful atomic commit; stale candidates, rejected checks, and version races do not commit.A valid rebase must reconstruct the proposed change against the current version and rerun every acceptance predicate.
4 The AstronOS Runtime
AstronOS is a distributed runtime that coordinates persistent Cases, staged Scenarios, model runs, and local Tasks while carrying authoritative state through validated, version-bound execution. Its implementation provides explicit snapshot binding and fencing on the central-analysis path, but has narrower guarantees for edge Tasks and cross-system transactions.
- Runtime architecture: AstronOS places central services, a runtime manager, and a local workbench between model executors and recorded or performed work.Central services retain Cases and advance Scenario-defined stages; the runtime manager invokes model executors, while the workbench executes Tasks requiring local files, repositories, or tools.
- State and validation: The latest Case Snapshot uses optimistic compare-and-set updates, but the repository retry merges newer rows without rerunning every task-level acceptance predicate.The audited correspondence therefore covers the observed no-conflict commit path and atomic latest-row advancement, not full semantic rebase behavior.
- State and validation: The central-analysis path sends a full input snapshot and revision, stores that revision on the Analysis Run, and interprets results only when the latest Case revision still matches.A stale result is ignored; otherwise the accepted patch is merged into a new snapshot revision.
- Measured handoff: Condition C uses the AstronOS runtime-mediated state handoff to carry committed stage results and progress the same Case across stages.Each stage receives hash-pinned synthetic evidence, runtime-admitted prior results, structured dispatch or decision artifacts, and archived content-hashed links to successive Tasks; product Context Bundle and long-term-memory paths are outside this measured condition.
- Runtime architecture: Scenario Packs define reusable stages, expected outputs, and progression conditions that the Workflow Worker uses to create workflow-specific analysis or edge Tasks.The bound pack supplies semantics to shared Case, snapshot, Task, and result-handling machinery while keeping the generic runtime domain-independent.
- Implementation boundaries: Implementation correspondence is qualified because edge Tasks lack mandatory base-version fields and result persistence, workflow signaling, and external actions lack a cross-system transaction.Only the Analysis Run path has explicit snapshot binding; snapshot merge is atomic at the Case row, while the remaining pipeline is fenced and recoverable.
5 Evaluation Methodology
The evaluation compares five complete prior-state provision conditions on fixed software-version planning tasks, measuring deterministic pass rate, token efficiency, and time trade-offs. Ten tasks, three repetitions, and five conditions yield 150 valid executions, with inference limited to condition-level differences within the frozen suite.
- Research questions: The experiment compares complete conditions using three endpoints: deterministic scorer pass rate, provider-reported tokens per passing execution, and execution-window or harness time.The comparison is explicitly at the complete-condition level, so inference is limited to condition-level differences.
- Task suite: 10 parameterized tasks from two templates test software-version update planning with dependencies, test-status evidence, selection, and ordering.The single-stage S family supplies all facts at once, whereas GAR distributes material across three stages requiring state carry-forward and revision.
- Controls and conditions: All conditions share generated instances, current-stage material, model settings, tools, schema, and scorer, while each stage starts a fresh provider session.Condition C additionally varies stage packaging, checkpoint propagation, runtime progression, and immediate information coverage together with its prompt-and-orchestration stack.
- Execution design: 150 valid executions result from 10 instances × 5 conditions × 3 repetitions, with A–C collected in a primary batch and D–E subsequently.Provider-capacity attempts were invalidated before inclusion and excluded from token and time accounting.
- Scoring: Passing is binary and requires every deterministic check, including correct state progression, evidence, ordering, required fields, and final simulator events.The separate 100-point score diagnoses partial failures but does not relax the binary pass rule.
- Scope and limitations: The frozen suite contains only 10 instance clusters and two generating templates, so reported intervals describe within-suite sensitivity rather than population-level significance.Both-passing efficiency comparisons are descriptive because they condition on instance–repetition pairs where C and baseline b both pass.
6 Results
Condition C achieved the strongest aggregate and three-stage GAR-family outcomes, while matching alternatives on the single-stage S family. Its observed pass-rate advantage coincided with lower attempt-accounted tokens per pass but greater per-attempt execution time, and the family contrast does not establish causality.
- Aggregate outcomes: 28/30 (93.3%) A–C executions passed under C, versus 15/30 for A and 16/30 for B; later-batch D and E passed 15/30 and 14/30.Every task instance passed at least once under C, compared with only five to seven instances under alternatives.
- Family-level outcomes: 14/15 GAR executions passed under C, versus 2/15 for B and none for A, D, or E, while every condition passed 14 or 15 of 15 S executions.The observed divergence is specific to the three-stage GAR template; later D/E comparisons are descriptive because they were collected after A–C.
- Token use: 70,303 accounted model tokens per observed pass under C were 40.7%, 44.6%, 42.2%, and 45.4% lower than A, B, D, and E, respectively.C averaged 65,616 tokens per attempt, versus 59,268 for A, 67,726 for B, 60,763 for D, and 60,083 for E; the lower per-pass ratio coincided with higher GAR yield.
- Time use: 73.8 s execution-window time and 78.5 s archived harness time per attempt under C exceeded every alternative.Pooling attempt time by observed passes yielded 79.1/84.1 s per pass for C; the measurements compare bundled conditions and do not isolate AstronOS runtime overhead.
- Failure analysis: C’s two failures preserved state continuity but violated canonical dependency ordering, receiving diagnostic scores of 90 and 85 despite failing the binary criterion.All 15 C runs received full credit for GAR classification, evidence, progression, checkpoint handling, and output completeness, while 14 received full ordering credit.
- Interpretation: C provided no pass-rate benefit on S, but showed a large observed association with passing outcomes on GAR alongside more per-attempt work and higher both-passing time.Because S and GAR are not matched, this contrast is not an estimate of a causal interaction.
7 Discussion
The complete AstronOS strategy is associated with higher pass rates and lower attempt-accounted token cost per passing execution on the cross-stage template, but with longer execution-window time. The findings are descriptive because strategies and task families were not fully isolated or matched, motivating equal-information controls and factorial ablations.
- RQ1: scorer pass rate: 14/15 GAR executions pass under C, versus 2/15 under B and 0/15 under A, while later D and E also pass 0/15.On the single-stage S family, all conditions pass at least 14/15, so the observed advantage is specific to the cross-stage template.
- RQ2: accounted token efficiency: C has the lowest total accounted model tokens per observed pass across the whole matrix.On S, C uses fewer tokens per attempt at a similar pass rate; on GAR, it uses more tokens per attempt but converts nearly every attempt into a pass.
- RQ3: time: C has longer median execution-window time across all both-passing comparisons, yet lower attempt-accounted time per observed pass than A and B.The tradeoff reflects longer per-attempt execution for higher outcome yield and lower attempt-accounted token cost.
- Interpretation and limitations: The experiment evaluates complete prior-state handoff strategies, not isolated runtime components, and the S–GAR comparison is descriptive because the families differ in generators, task sizes, and evidence structures.GAR additionally includes multiple stages, state revision, exact intermediate scope, and a final decision based on runtime-admitted scope after earlier guesses are superseded.
- Future work: Equal-information controls and factorial ablations are the highest-value extensions, varying product Context Bundle, structured versus prose results, explicit state binding, and Scenario-mediated versus direct progression.Further work should also vary stage count and superseded-history volume to locate the break-even point.
8 Threats to Validity, Reproducibility, and Ethics
The evaluation uses a deterministic synthetic benchmark with constrained task diversity, while its cost accounting and cross-batch comparisons have stated limitations. Reproducibility is partial because the public artifact supports ledger recomputation but not independent task reconstruction or full reruns, and the study uses no human or real-world data.
- Validity: The frozen deterministic scorer measures exact executable staged decision continuity, not maintainability, user satisfaction, or employee productivity.High-scoring but non-canonical outputs are intentionally classified as failures.
- Cost limitations: 70,303 tokens/pass for C remains below A’s 120,837, D’s at least 121,526, and E’s 131,224 in the lower-bound sensitivity check.The comparison charges observable token use from three capacity-invalidated attempts to their intended conditions; D has incomplete token telemetry.
- Validity: Ten instances from two synthetic templates, one model configuration, and correlated repetitions limit generalization to real-world software-development workflows.The shared S and GAR generators further reduce effective diversity, so the paper reports effect sizes and descriptive intervals.
- Validity: GAR concentrates cross-stage dependencies and exact state reuse, potentially favoring AstronOS; broader generalization requires task families with different state revision, tool use, and outcome semantics.The single-stage reference family provides only a descriptive counterpoint under unmatched task content.
- Reproducibility: The public artifact supports arithmetic recomputation of the 150-row ledger but not independent task reconstruction, scorer execution, model-visible-information comparison, or narrated raw-trace verification.Full rerun reproducibility additionally depends on a public code artifact and continued access to the named external model.
- Ethics: The evaluation uses no human subjects or real customer, employee, source-repository, or business-system data, and all entities and tool effects are synthetic.The isolated environment did not write to the shared integration environment; credentials and internal network details are excluded from public artifacts.
9 Conclusion
AstronOS defines a unified execution model for long-horizon agentic work around enduring work items, accepted state, identified state bases, and validated commits. In 150 valid benchmark executions, its runtime-mediated handoff passed 14/15 primary three-stage executions, outperforming the cited comparison conditions while passing similarly on single-stage references.
- Unified execution model: AstronOS makes an enduring work item and its accepted state the execution boundary for long-horizon agentic work.Each step is constructed from an identified state basis, while candidate output is separated from the commit that advances authoritative state.
- AstronOS implementation: The implementation realizes these abstractions through audited Cases, Tasks, Scenario Packs, central orchestration, and local execution.Source and trace audits identify the concrete mechanisms and their current boundaries.
- Benchmark results: 14/15 primary three-stage executions passed with AstronOS runtime-mediated state handoff, versus 0/15 for A and 2/15 for B.The benchmark included 150 valid executions over two templates of a synthetic staged decision-continuity benchmark.
- Benchmark results: 0/15 executions passed in later batches D and E, while every condition passed 14/15 or 15/15 single-stage reference executions.These results contrast later-batch performance with the strong single-stage reference results.
- Cost and time: C had the lowest attempt-accounted model tokens per observed pass across the full matrix, but used more time within its condition.The passage reports this as a cross-matrix cost and time tradeoff.
A Task and outcome detail
Table 10 reports passing repetitions out of three for every task instance.
- Table 10 reports passing repetitions (out of three) for every task instance.
B Workbench-turn and prompt diagnostics
This section reports mean workbench-turn and prompt diagnostics per valid attempt, defining the ledger and provider measures used. It also notes that strategy-specific execution differences reflect bundled comparisons rather than state representation alone.
- Measurement definitions: Table 11 reports family-level means over all 15 attempts in each cell for workbench turns and prompt diagnostics per valid attempt.A turn is one agent turn recorded by the workbench ledger.
- Measurement definitions: Provider model-call counts were not exposed, while prompt characters were counted before provider tokenization and input/output columns used provider-reported tokens.These definitions distinguish workbench-ledger turns from provider-level measurements.
- Strategy bundling: On the three-stage GAR family, C uses three synthetic decision-stage Tasks and one additional model-using checkpoint-propagation Task.These execution differences are part of the bundled strategies being compared.
- Strategy bundling: The bundled execution differences are not evidence about state representation alone.The passage frames these differences as part of the strategies under comparison.
C GAR scorer diagnostics
The GAR scorer diagnoses performance across six distinct requirements, awarding category credit only when every check within that category passes. Table 12 reports these full-credit counts out of 15 to locate failures, not identify their runtime causes.
- Diagnostic categories: Six diagnostic categories cover classification, dependency-valid order, test-status evidence, stage progression, checkpoint/control handling, and complete structured output.The scorer separates these requirements into distinct categories.
- Scoring rule: Full credit requires all checks in a category to pass.Partial satisfaction within a category does not receive full credit.
- Interpretation: Category counts locate observed failures but do not isolate which runtime component caused them.The diagnostics describe where requirements failed, not the responsible implementation component.
- Reported counts: 15 runs form the denominator for each Table 12 category count.The table counts executions receiving full credit in each diagnostic category.
D Latency detail
This section reports family-level execution times and distinguishes correct-run averages from per-pass calculations. For GAR, reported times vary across families and columns, with values shown for families B and C.
- D Latency detail: Table 13 reports family-level time in seconds, with correct-run averages limited to passing runs and per-pass columns including all valid attempts.The table defines how the two time summaries are calculated.
- D Latency detail: 69.97, 641.47, and 641.47 seconds are reported for GAR family B, while family C reports 124.73, 132.49, and 137.80 seconds.Families A, D, and E show dashes in all three reported columns.
E Implementation evidence anchors
The conformance audit is anchored to a pinned source revision and implementation files covering contracts, snapshot merging, revision binding, outcome fencing, and context-memory lineage. Its compact manifest identifies each run and verifies archived inputs with byte counts and SHA-256 digests.
- Implementation anchors cover Case and Task contracts, snapshot compare-and-set merging, analysis revision binding, outcome fencing, and Product Context Bundle lineage.
- The compact manifest records each run’s task, condition, repetition index, archive path, byte count, and SHA-256 digest alongside the pinned source revision.Source paths are revision-relative, and the manifest omits source line numbers and test anchors.