PaperlayerView exact revision on arXiv

Source-linked AI summary

HEXIS: Compiling Skills into Extended Finite State Machines

Minghao LI

arXiv:2609.30123v1cs.AI

TL;DR

Agent skills provide reusable knowledge, but agents must still infer how to apply requirements and which operation should follow. HEXIS compiles skills and traces into extended finite state machines that retain knowledge for in-state reasoning and make control explicit. Across four benchmarks and four executors, it improves native execution in 15 of 16 settings and leads or ties in 11.

  • Problem

    Agents can omit or misapply skill requirements because they must infer operations and control decisions from instructions and interaction history.

    Source: §1 · pp. 1–2

  • Method

    HEXIS compiles skills and execution traces into extended finite state machines with state-local instructions, operations, data dependencies, and explicit transition conditions.

    Source: §1 · p. 2

  • Results

    Across four benchmarks and four executors, HEXIS improves native execution in 15 of 16 settings and leads or ties in 11.

    Source: §1 · p. 2, §6 · p. 9

  • Takeaways & Limitations

    Source-model compilation supports cross-model reuse without target-model recompilation while retaining the selected executor’s reasoning within each state.

    Source: §6 · p. 9

    HEXIS depends on the quality and coverage of skill documents and development traces, and validation of recorded paths does not guarantee correct in-state reasoning or coverage of unseen situations.

    Source: §6 · p. 9

Abstract

from arXiv · show

Agent skills provide reusable knowledge and instructions, yet agents must repeatedly infer how to apply them and which operation should follow. This couples task reasoning with control decisions, allowing prescribed steps to be omitted or applied incorrectly. We introduce HEXIS, which compiles agent skills into extended finite state machines that separate knowledge from control flow. Skill knowledge is incorporated into local instructions that guide reasoning and generation within states. The machine records execution progress and intermediate results, while explicit transition conditions determine subsequent operations. Our incremental compiler first maps skill clauses and tool interfaces to state operations, local instructions, data bindings, and transitions. It then aligns development traces with existing states to identify missing operations and dependencies. These are incorporated by adding or reusing states and refining their connections. Updates are accepted only after static checks and replay of the current and all previously accepted traces. Across four benchmarks and four executors, HEXIS improves success over Skill + ReAct by 16.1 percentage points on average. Qwen3.8-27B reduces execution tokens by 38.4-88.9% across benchmarks.

1 INTRODUCTION

Agent skills make specialized knowledge available during execution, but agents may still omit or misapply required operations because they must infer control decisions from instructions and history. HEXIS compiles skills into state machines that retain knowledge for in-state reasoning while making execution progress and transitions explicit.

1 INTRODUCTION

  • Curated skills raise average pass rate from 33.9% to 50.5% across 87 tasks in eight domains, illustrating the value of reusable specialized knowledge.Skills package domain knowledge, instructions, and resources such as scripts, references, and templates.Source: §1 · p. 1
  • Because agents infer actions from skill text and interaction history, they can omit or incorrectly apply clearly stated requirements, including complex conditional and tool-use instructions.Reported difficulties include failing to carry out a required revision after a failed check and weaker procedural compliance among smaller models.Source: §1 · p. 1
  • Skill optimization, reflection and memory, and executable workflows address different parts of execution, but a skill compiler must distinguish model-needed knowledge from procedural relations such as dependencies and branching.The related-work overview names SkillOpt, Reflexion, Agent Workflow Memory, StateFlow, Formal Skill, AFlow, TraceCompiler, and Compile Then Page.Source: §1 · pp. 1–2
  • HEXIS compiles skill documents and execution traces into machines that specify operations, data dependencies, and conditions for branching, repetition, and termination while retaining skill knowledge in prompts.The machine records the current stage, executes its assigned operation, and uses transition conditions to select the next stage.Source: §1 · p. 2
  • HEXIS improves on native skill execution in 15 of 16 settings and achieves the best or tied-best success in 11.The evaluation covers four benchmarks and four execution models; the compilation procedure and reported transfer results are summarized with the contributions.Source: §1 · p. 2

2 RELATED WORK

Prior approaches improve skill text, add experience, or organize execution with programs and predefined state machines. HEXIS instead derives reusable state machines from skills and traces, keeping operation prompts and data dependencies while models continue reasoning within states.

2 RELATED WORK

  • Unlike predefined task-domain state machines, HEXIS automatically derives reusable state machines from skills and execution traces.Prior approaches also revise skill text, supply reflections or workflows, or compile procedural requirements into programs.Source: §2 · pp. 2–3
  • Figure 2 contrasts context-based skill or memory approaches and an AFlow program with HEXIS, where orange states retain task knowledge and local operations and green transitions define workflow.Panels (a) and (b) provide context for the LLM to select tools and control execution; panel (c) sketches an AFlow program composing LLM calls.Source: Figure 2 · p. 3
  • HEXIS keeps operation prompts and data dependencies in its compiled machines, aligns traces, and validates updates while leaving in-state reasoning to models.SkillOpt can also improve the text supplied to the compiler, as demonstrated in combination with state-machine execution.Source: §2 · p. 3

3 MOTIVATION AND PROBLEM FORMULATION

Native skill execution asks the model to apply task knowledge while recovering progress and choosing the next operation, so supplying control requirements as context does not enforce them. HEXIS separates state-local knowledge and operations from explicit transitions, and the formulation evaluates how well machine configurations represent skill-permitted continuations.

3.1 MOTIVATION

  • Native execution makes each model decision combine task-knowledge application with recovering progress, identifying applicable control requirements, and choosing an operation; context influences but does not enforce that choice.The skill document may interleave knowledge with requirements for operation order, dependencies, branching, repetition, and termination.Source: §3.1 · p. 3
  • A_t denotes the operations and inputs permitted by the applicable skill requirements, but serves as a semantic reference rather than an executor action filter.The permitted set depends on task input and history.Source: §3.1 · p. 3
  • Even after correctly identifying a failed check, a model may report it instead of performing the required revision, and this deviation remains possible with deterministic decoding.Correct evidence alone does not ensure zero local deviation probability.Source: §3.1 · p. 3
  • The formulation defines full-horizon compliance as avoiding any deviation across K decisions and represents the cumulative probability of deviation over that horizon.It treats permitted termination as an absorbing compliant outcome and defines conditional deviation probabilities over histories that remain compliant.Source: §3.1 · pp. 3–4
  • HEXIS retains relevant skill knowledge in state-specific prompts and resources, while compiling control requirements into states, guarded transitions, and termination rules; typed variables store operation inputs and results.Models and tools perform local operations, and the runtime selects the first enabled outgoing edge after a successful nonterminal operation.Source: §3.1 · p. 4
  • When a skill check fails, the runtime can route the verdict to revision; if the requirement and condition are correctly encoded, that continuation needs no further model decision.This targets an opportunity for control deviation at that boundary.Source: §3.1 · p. 4

3.2 PROBLEM FORMULATION

  • Given a skill, tool specifications, an input schema, and development traces, compilation constructs a machine whose configuration is the current state plus variable values and represents permitted continuations.A continuation includes operations, inputs and outputs, and termination; the mapping from task input and history to configuration is fixed before evaluation.Source: §3.2 · p. 4
  • The representational objective minimizes information loss, measured as the conditional entropy of skill-permitted continuations given the machine configuration under a context distribution.A smaller loss means the configuration better distinguishes execution semantics; static checks and trace replay determine whether an update is accepted.Source: §3.2 · p. 4

4 METHOD

HEXIS represents skill execution as a state machine, keeping skill knowledge in state-local instructions and tracking intermediate data while transitions direct progress. Its compiler initializes machines from skill documents and incrementally updates them using development traces and validation.

4 METHOD

  • The method separates local skill-guided reasoning from execution control: states retain instructions and data, while the runtime selects transitions using variable values.Initial machines are built from skill documents, then development traces are used to add missing operations and dependencies.Source: §4 · p. 4, §4.1 · p. 4

4.1 STATE MACHINE REPRESENTATION

  • States bind configured operations to typed variables; after execution, the runtime selects the first satisfied ordered edge, while terminal states record outcome categories.Operations specify invocation interfaces, instructions, and read/write declarations; tool states store returned results.Source: §4.1 · pp. 4–5

4.2 INITIAL COMPILATION

  • Initialization numbers and retains skill clauses, maps each to a state or instruction, defines data bindings and guarded branches, then validates structure, dependencies, constraints, and terminal evidence.Invalid candidates can be revised within a fixed retry limit; initialization fails if retries or final checks fail.Source: §4.2 · p. 5

4.3 TRAJECTORY UPDATES

  • Trace updates align recorded operations with existing states, reuse compatible reachable states where possible, and add unmatched operations as states with missing bindings and transitions.When a condition has different successors, a judge state supplies a branch label; loops receive counter limits and exits.Source: §4.3 · pp. 5–6
  • An update is accepted only when static checks pass and replay succeeds for the current and all previously accepted trace records.Replay uses recorded tool outputs and abstract model outputs while following the machine’s transition rules; failed attempts leave the machine and archive unchanged.Source: §4.3 · p. 6

5 EXPERIMENTS

Across four benchmarks and four executors, HEXIS generally improves success over native skill execution. Token costs vary by executor, while combining compilation with skill-text optimization yields further gains on SpreadsheetBench.

5.1 BENCHMARKS AND SKILLS

  • The evaluation pairs one skill with four held-out benchmarks: spreadsheet manipulation, mathematician-level problems, code-based data analysis, and long-context webpage question answering.The tasks are scored as success or failure, with success rates reported on held-out test tasks.Source: §5.1 · pp. 6–7

5.2 BASELINES

  • The five baselines supply skills as documents, induced experience, revised text, or searched workflows, while methods share executors and tools.The reported full-compliance measure is the fraction of executions satisfying every applicable mechanically verifiable request requirement, including delivery, format, and tool-use checks.Source: §5.2 · p. 7

5.3 MAIN RESULTS

  • 15 of 16 settings improve over native skill execution, and HEXIS is best or tied-best in 11 across four task domains.The comparison covers mathematical reasoning, spreadsheet editing, data analysis, and long-context question answering.Source: §5.3 · p. 7, Table 1 · p. 8
  • 31.4–38.0 points are gained on LiveMath across four executors, where HEXIS outperforms every baseline.HEXIS also improves 11 of 12 target-model settings using machines compiled from qwen3.6-flash traces and transferred without target-model adaptation.Source: §5.3 · p. 8
  • 38.4–88.9% fewer tokens than Skill + ReAct are used by Qwen3.8-27B with HEXIS across all four benchmarks.Token savings depend on executor: qwen3.6-flash uses more tokens on SpreadsheetBench and LiveMath, while additional reasoning and checking affect efficiency by task and model.Source: §5.3 · pp. 8–9, Figure 5 · p. 9
  • 84.2% success at 69k tokens per task is reached by SkillOpt with HEXIS on SpreadsheetBench, a 24.6-point gain and 73.2% token reduction over native execution of the optimized skill.This combination adds 8.8 points over HEXIS compiled from the original skill.Source: §5.3 · p. 9

6 CONCLUSION

HEXIS separates skill knowledge and in-state reasoning from execution control, using recorded results and explicit transitions to organize prescribed operations. Its appendix explains how this division represents and adapts skills, when models remain necessary, and how construction and refinement proceed.

6 CONCLUSION

  • HEXIS depends on skill-document and trace coverage: unexpressed requirements or branches may be absent, and replay does not guarantee correct in-state reasoning or coverage of unseen situations.The conclusion identifies targeted trace collection and stronger in-state verification as future directions.Source: §6 · p. 9
  • HEXIS improves native execution in 15 of 16 settings and leads or ties in 11 across four benchmarks and four executors.Source-model compilation supports cross-model reuse without target-model recompilation, while retaining the selected executor’s reasoning within each state.Source: §6 · p. 9

A.1 HOW A STATE MACHINE REPRESENTS A SKILL

  • A state machine represents a skill through both state-local knowledge and instructions and connections that organize when operations run, with variables holding inputs and intermediate results.The same state can use different variable values across tasks, enabling task-specific results.Source: §A.1 · p. 13

A.2 WHY IS A MODEL NEEDED ONCE THE NEXT OPERATION IS DETERMINED?

  • The model reads local skill content and relevant data to perform task-dependent planning, interpretation, judgment, or generation within the operation selected by the machine.Tool states invoke tools with bound parameters and pass results to later states.Source: §A.2 · p. 13
  • For workbook edits, tools inspect structure and execute plans, while model operations identify fields and output regions, apply skill rules, and interpret audit evidence.Figure A.1 depicts this staged collaboration; one apply-edits state can serve different workbooks using their stored regions and plans.Source: §A.2 · p. 13, Figure A.1 · p. 14

A.3 HOW THIS DIVISION OF WORK REDUCES SKILL DEVIATION

  • Compiled transition conditions connect stored results to prescribed next operations, reducing repeated inference of those relationships from skill instructions and interaction history.The model can still provide a judgment label whose correctness depends on its understanding of the task and evidence.Source: §A.3 · p. 14

A.4 WHEN ORDINARY CODE IS SUFFICIENT

  • Ordinary code can complete a task when it reliably performs every operation, generates necessary parameters, and evaluates all relevant conditions.Spreadsheet tasks with fixed input formats and complete transformation rules are one stated example.Source: §A.4 · p. 14

B HOW SKILL STATE MACHINES ARE CONSTRUCTED, UPDATED, AND EXECUTED

  • The appendix describes initialization from skill content, trace-based machine refinement, checks and replay before committing changes, and execution on new tasks.The construction, update, and execution stages share the state machine defined in the appendix.Source: B HOW SKILL STATE MACHINES ARE… · pp. 14–15

B.1 SKILL CONTENT, DATA, AND EXECUTION RULES IN THE STATE MACHINE

The appendix defines a state machine whose operations use local prompts, typed variables, and ordered transitions. It then describes initialization and trace-guided updates, which are checked and replayed against both new and archived executions before acceptance.

B.1 SKILL CONTENT, DATA, AND EXECUTION RULES IN THE STATE MACHINE

  • Each state operation declares its type, local prompt, resource references, read/write variables, and bindings; transitions use guards and optional counters to determine subsequent execution.Variables begin from constants or task inputs, and the current state together with variable values forms the machine configuration.Source: §B.1 · p. 15
  • Model operations write generated results to declared variables, while tool operations use argument templates and output bindings; branch decisions use a fixed label set that includes abstention.The runtime stores operation results before selecting the first enabled outgoing edge in declared order, and terminal states return an outcome identifier and category directly.Source: §B.1 · p. 15

B.2 INITIALIZATION: GENERATING AND CHECKING A MACHINE FROM THE SKILL DOCUMENT

  • Initialization drafts a machine from the skill document, tool specifications, and task-input schema, regenerating drafts with feedback on format, structure, guards, interfaces, and clause references.Final checks cover variable dependencies, terminal evidence, and declared workflow constraints; failure to pass returns no initial machine.Source: §B.2 · pp. 15–16

B.3.1 STEP 1: EXTRACT OBSERVABLE EVENTS AND EXECUTION EVIDENCE

  • Each development trajectory is extracted into observable events and evidence, then filtered for supported event types, requirements, prohibitions, and evidence for conditional terminal identifiers.Event records retain relevant inputs, outputs, roles, and observability; framework-management calls are removed and consecutive same-tool, same-phase attempts are merged.Source: §B.3.1 · p. 16

B.3.2 STEP 2: ALIGN EVENTS WITH EXISTING STATES

  • Alignment prioritizes compatible reachable states, then considers compatible states elsewhere unless connecting them would bypass a required state.Tool compatibility requires matching tool names and phases, while terminal compatibility requires matching exact outcome identifiers; the compiler can match, add, ignore, or exclude events.Source: §B.3.2 · pp. 16–17

B.3.3 STEP 3: SUPPLEMENT THE REPRESENTATION IN A COPY OF THE MACHINE

  • The compiler modifies a copy by inserting states, transitions, and variable bindings; new model states combine event purpose, tool definitions, and relevant skill passages in local instructions.It can derive transitions from tool-success predicates, insert decision states for conflicting guards, and represent repeated execution with bounded loops and configured exits.Source: §B.3.3 · p. 17

B.3.4 STEP 4: CHECK THE CANDIDATE AND REPLAY NEW AND ARCHIVED TRAJECTORIES

  • A candidate is committed only after static checks and replay pass for the current and every archived trajectory, preserving replayability of those checked event paths.Replay uses recorded tool outputs and placeholder model and user results, without live model or tool calls; each trajectory receives at most two update attempts.Source: §B.3 · p. 16, §B.3.4 · pp. 17–18

B.4 EXECUTION: OPERATIONS, ERROR HANDLING, AND FALLBACK

The final machine executes model and tool operations from its initial state, storing results and following transitions until it returns a terminal result and category. Runtime configuration bounds retries; errors can stop execution, while configured interpretive fallback hands execution back to a model.

B.4 EXECUTION: OPERATIONS, ERROR HANDLING, AND FALLBACK

  • Execution initializes variables with task input, runs model states using local skill content and tool states through actual calls, then stores results and selects the next state.A terminal state returns its result and corresponding category.Source: §B.4 · p. 18
  • Retries are bounded by runtime configuration and selected by error type; a retry may restart at a preceding tool-input state.If no outgoing edge is enabled or guard evaluation fails, execution ends with a stuck or state-error outcome.Source: §B.4 · p. 18
  • When enabled, interpretive fallback passes the skill, history, and current variables to a model at a configured handoff state; unattended execution does not perform live user interactions.Fallback is recorded with the fallback category.Source: §B.4 · p. 18

B.5 EVALUATING SKILL REPRESENTATION AND TASK EXECUTION SEPARATELY

The appendix distinguishes how much skill execution semantics a machine represents from whether execution conforms to the skill. Its information-theoretic analysis relates incremental trace evidence to representation loss and gives convergence conditions.

B.5 EVALUATING SKILL REPRESENTATION AND TASK EXECUTION SEPARATELY

  • Representation loss measures uncertainty about skill-permitted continuations given the machine configuration, whereas execution loss concerns whether models, tools, and transitions use that information correctly on particular tasks.Execution-loss probability includes model and environment randomness and termination modes disallowed by the skill.Source: §B.5 · p. 18

C INCREMENTAL REPRESENTATION OF SKILL INFORMATION FROM EXECUTION TRACES

  • When new traces continue to distinguish unresolved skill semantics and the compiler incorporates and retains that information, the machine’s represented skill information progressively increases toward the original semantics.Each round aligns trace operations and results with the machine and adds missing states, instructions, bindings, or transitions after checks and archived replay pass.Source: C INCREMENTAL REPRESENTATION OF SKILL… · p. 18, §C.1 · p. 19

C.2 THE INFORMATION GAINED IN EACH UPDATE

  • Under semantic-preservation assumptions, information gained in an update equals the decrease in expected representation loss; a trace that adds no new distinctions can yield zero gain.The implemented checks and replay maintain replayability of accepted event paths, while semantic preservation is an assumption of the analysis.Source: §C.2 · p. 19

C.3 WHY MORE TRACES APPROACH A COMPLETE REPRESENTATION

  • Convergence analysis assumes finitely many faithfully representable skill interpretations, trace evidence consistent with the original, and a fixed positive chance of eliminating each differing interpretation.The distinguishing condition must continue to hold after trace filtering.Source: §C.3 · p. 19
  • Under those conditions, expected representation loss approaches zero as distinguishing evidence is accumulated, reaching within any ε of the optimum after sufficiently many update rounds.Once incorrect interpretations are eliminated, the selected interpretation agrees with the original almost everywhere under µ and faithful compilation has zero representation loss.Source: §C.3 · pp. 19–20

D EFFECT OF THE COMPILATION MODEL

Sonnet-compiled machines outperform Skill + ReAct across four benchmarks, with scores close to those of Fable-compiled machines. The comparison tests whether the gains depend on the compiler.

D EFFECT OF THE COMPILATION MODEL

  • The comparison compiles machines with Sonnet 5 using the low setting and compares them with Skill + ReAct and Fable-compiled machines.The Fable results are reported in Table 1.Source: D EFFECT OF THE COMPILATION MODEL · p. 20
  • 2.0–4.0 percentage points below Fable-compiled machines, Sonnet-compiled machines still outperform Skill + ReAct on all four benchmarks.The comparison uses qwen3.6-flash for execution.Source: Table 3 · p. 20, D EFFECT OF THE COMPILATION MODEL · p. 20
  • The gains persist across compilers, consistent with explicit state transitions carrying out prescribed operations and reducing repeated inference of the next step.The result does not require Fable 5.1 as the compiler.Source: D EFFECT OF THE COMPILATION MODEL · p. 20

E MACHINE SIZE AND EXECUTION DIAGNOSTICS

Compiled machines are compact, but trajectories can revisit states; runtime retries and interpretive fallback are distinct recovery behaviors. The diagnostics cover 279 task trajectories across four benchmarks.

E MACHINE SIZE AND EXECUTION DIAGNOSTICS

  • The analysis uses one trajectory per task across 57 SpreadsheetBench, 120 LiveMath, 51 DABench, and 51 LongSeal tasks.Machine steps exclude retry records and interpretive fallback steps.Source: E MACHINE SIZE AND EXECUTION DIAGNOSTICS · p. 20
  • 27/57 SpreadsheetBench trajectories revisit a state, averaging 10.60 repeated visits and reaching up to 67 machine steps, despite no logged hub retry.Revisits can include re-analysis, tool execution, and output checking, rather than error retries alone.Source: Table 4 · p. 20, E MACHINE SIZE AND EXECUTION DIAGNOSTICS · pp. 20–21
  • 12–17 states and 19–35 transitions support repeated execution, with state revisits in 12/120 LiveMath, 22/51 DABench, and 44/51 LongSeal trajectories.A state revisit is a non-fallback state visited after its first occurrence.Source: Table 4 · p. 20, E MACHINE SIZE AND EXECUTION DIAGNOSTICS · p. 20
  • LiveMath records 3 runtime retries across 3 tasks, while LongSeal records 1 across 1 task; only one task in each benchmark enters interpretive fallback.SpreadsheetBench and DABench record no interpretive fallback.Source: E MACHINE SIZE AND EXECUTION DIAGNOSTICS · p. 21
  • Both LiveMath and LongSeal recovery tasks use at most one runtime retry, though one task in each benchmark proceeds to interpretive steps.The LongSeal hub resets the calculation counter before retrying from s6; retry counts exclude uninstrumented transport retries and repetitions inside generated tool code.Source: E MACHINE SIZE AND EXECUTION DIAGNOSTICS · p. 21

F AN EXECUTED STATE-MACHINE EXAMPLE

The LiveMath example shows how the machine tracks state, variables, and guarded transitions through a held-out execution. A separate comparison tests program-controlled execution against prompt-only control.

F AN EXECUTED STATE-MACHINE EXAMPLE

  • The LiveMath v11 machine has 12 stored states, 19 explicit transitions, 18 typed variables, and a declared 40-step execution limit.Its states include five model actions, two judge actions, two tool actions, two ordinary terminal states, and one fallback state.Source: F AN EXECUTED STATE-MACHINE EXAMPLE · p. 21
  • The machine uses counters for selection, state-3 visits, and repairs, while c stores the most recent tool return code and n and v store verification information.The counters begin at zero; request and output_path are the two task inputs.Source: F AN EXECUTED STATE-MACHINE EXAMPLE · p. 21
  • The verified terminal state means the delivered file agrees with the machine’s selected letter, not that the mathematical answer is correct.The writing path includes a read and consistency check before reaching the verified terminal.Source: F AN EXECUTED STATE-MACHINE EXAMPLE · p. 21
  • For held-out task lm_202511_026, the trace records 10 state records, seven model calls, two tool calls, 25,894 tokens, and 89.41 seconds, with no runtime retry or interpretive fallback.The second s2 visit receives stored incomplete feedback and proceeds to s3 because m = 1; the read-back judge returns pass.Source: F AN EXECUTED STATE-MACHINE EXAMPLE · p. 21

G EXECUTING COMPILED SKILLS AS PROMPTS OR STATE MACHINES

  • Prompt-only renders local instructions, tool templates, bindings, transition conditions, and termination rules as a skill document, but leaves progress tracking and transition selection to the model.HEXIS instead executes the machine through its runtime.Source: G EXECUTING COMPILED SKILLS AS PROMPTS… · pp. 21–23
  • 16.7 and 28.0 percentage points on average, HEXIS improves success and request-level full compliance over Prompt-only, respectively.Prompt-only scores 33.9% success on LiveMath versus 45.0% for Skill + ReAct.Source: G EXECUTING COMPILED SKILLS AS PROMPTS… · p. 23

H INCREMENTAL COMPILATION ON LIVEMATH

Incremental compilation incorporates execution feedback into machine instructions and control flow, then reuses the refined machine across later LiveMath groups. The following section lists resource licenses and URLs.

H INCREMENTAL COMPILATION ON LIVEMATH

  • The LiveMath development follows 487 tasks across 49 groups, with the initial machine M0 used for the first group and later groups using the machine available after earlier processing.Groups contain ten tasks except the final group of seven; group success rates use actual group sizes.Source: H INCREMENTAL COMPILATION ON LIVEMATH · p. 23
  • Success rises from 40% in the initial group to 90% on group 4 and 100% on group 9 as feedback adds option support, conclusion coverage, completeness checks, and a return to option selection.The added checks and revision steps are encoded in state instructions and control flow.Source: H INCREMENTAL COMPILATION ON LIVEMATH · p. 23, Figure H.1 · p. 23
  • 227/287 tasks (79.1%) succeed across the 29 groups that reuse the machine retained after the update following group 20.The retained machine is used for the remaining groups without further machine updates.Source: H INCREMENTAL COMPILATION ON LIVEMATH · p. 23

I LICENSES

  • Table 7 lists resource licenses and URLs for benchmarks, skills, baselines, models, and serving software; SigLeak skills use an anonymous repository and hosted models follow provider terms.The table covers licenses and URLs.Source: I LICENSES · p. 24, Table 7 · p. 24
Loading 2609.30123v1…