PaperlayerView exact revision on arXiv

Source-linked AI summary

APEX: An Extensible Model for Agent-Assisted Production Scheduling

Felix J. Grumbach, Stefan Görlitz

arXiv:2609.33430v1cs.AIcs.NE

TL;DR

Production scheduling needs models that reflect operational constraints and methods that balance competing goals, while deployment also requires data integration and specialist expertise. APEX combines an extensible production model and hybrid multiobjective search with agent support for scheduling and model refinement. Its hybrid configurations achieve the strongest aggregate benchmark quality, while the separate workflow and coding studies report successful checked changes within their tested scope.

  • Problem

    Production scheduling deployment requires operationally adequate models and optimization, as well as data integration, model adaptation, and specialist expertise.

    Source: §1 · p. 1

  • Method

    APEX couples a reusable production model and hybrid multiobjective search with agent-assisted data preparation, scenario work, and implementation and testing of new constraints or objectives.

    Source: §1 · p. 2, §4.1 · p. 7

  • Results

    Across 69 instances, XHTE and XHE achieve closely matched aggregate trade-off quality with class-specific leaders; all 24 workflow sessions and six extension implementations passed independent checks.

    Source: §9 · pp. 17–18

  • Takeaways & Limitations

    APEX connects evolving production models and agent-assisted refinement to shared construction, evaluation, and validation across complementary search methods.

    Source: §1 · p. 2

    Classical-subset benchmarks do not establish search completeness or industrial outcomes; extended-model performance and industrial validation require separately scoped evidence.

    Source: §8 · p. 17

Abstract

from arXiv · show

Production scheduling requires realistic models that reflect operational constraints and efficient methods that balance competing goals. Putting these methods into use also requires data integration, model adaptation and specialist expertise. We present APEX, an extensible production scheduling framework built around a general model and hybrid multiobjective search. Agent assistance supports both scheduling and model refinement: agents prepare data and explore scenarios in natural language, while coding agents help implement and test new constraints and objectives. Shared construction and checking procedures connect these adaptations to the scheduling core. We benchmark eight APEX configurations against NSGA-II, SPEA2, MOEA/D and SMS-EMOA on 69 public job-shop, flexible job-shop and permutation flow-shop instances, assessing workload completion time (makespan), total job flowtime and computation time. Hybrid configurations achieve the best aggregate solution quality, although the leading method depends on the problem class and objective. A separate synthetic workflow study uses OpenAI's GPT-6-astra as an interaction layer between the human planner and the algorithmic core, testing rule additions, plan and objective changes, and what-if comparisons. All 24 sessions completed the requested changes and passed independent checks of saved models and schedules. A separate coding evaluation produced six native implementations of an additional objective or hard constraint through predefined extension hooks. All passed independent checks without modifying the core.

1 Introduction

Production scheduling combines changing operational constraints with data integration, model adaptation, and specialist expertise. APEX couples an extensible production model and hybrid search with agent support for scheduling and model refinement, then evaluates its search and agent-assisted workflows.

1 Introduction

  • Production planners must reconcile competing jobs, scarce resources, disruptions, and already released work; model or information mismatches can turn intervention into routine firefighting.A usable schedule also depends on current information, such as technician availability and inspection release.Source: §1 · p. 1
  • Production scheduling systems require more than an optimization engine: deployment also entails data integration, model customization, continuing specialist support, and operational validity checks.Prior manufacturing cases documented consultant dependence and substantial operating effort.Source: §1 · p. 1
  • APEX represents workplans, resources, calendars, materials, and commitments in a reusable model, with agents supporting data preparation, scenario comparison, search, and model refinement.Coding agents can help implement and test constraints or objectives beyond existing capabilities, with shared construction, evaluation, and validation procedures connecting changes to search.Source: §1 · p. 2
  • The paper compares eight APEX configurations with four external algorithms on 69 public JSP, FJSP, and PFSP instances using makespan and total job flowtime.A separate synthetic study tests rule, plan, and objective changes, what-if comparisons, and coding-agent extensions through independent checks.Source: §1 · p. 2

2 Production scheduling models, solution methods and agent assistance

The review considers production-model coverage, search methods, and agent assistance as connected but distinct aspects of scheduling systems. It positions APEX around joint model representation, search, and operationally relevant evaluation.

2.1 Production models and operational realism

  • Production models range from common-sequence flow shops to job shops with job-specific routes, while richer models add interacting resources, buffers, blocking, or staged resource use.The review also notes that represented conditions and evaluation settings differ, and that setups and due-date compliance can restrict attainable energy improvements.Source: §2.1 · p. 2

2.2 Solution methods and computational trade-offs

  • Hybrid search methods combine modelling machinery with targeted moves or decompositions, whose usefulness depends on the represented constraints.Solver rankings can vary by problem family, size, and formulation, so a method name alone is insufficient for choosing a solver.Source: §2.2 · p. 3

2.3 Agent-assisted modelling and operation

  • Agent-assisted scheduling spans coordinating existing schedulers, generating or critiquing rules, operating tools, exploring scenarios, and explaining alternatives.These studies address different tasks and evidence settings; successful tool operation, simulated-schedule improvement, and industrial support are distinct outcomes.Source: §2.3 · pp. 3–4

2.4 Research gap and positioning of APEX

  • The research gap is keeping relevant constraints, data, and assumptions aligned with production while evaluating decisions alongside timely state updates and organisational use.APEX addresses this agenda with a shared extensible model and search under common checking semantics, with agents supporting data preparation, scenarios, and model extension.Source: §2.4 · p. 4
  • The paper benchmarks search on classical JSP, FJSP, and PFSP instances, while its agent studies examine configuration and native extension on a small synthetic factory.Model realism, search performance, and agent-assisted use are treated as complementary parts of the research programme.Source: §2.4 · p. 4

3 The APEX production-scheduling model

APEX extends the flexible job-shop model to represent detailed production plans, alternatives, resources, and existing commitments. Its semantics cover work, timing, capacity, materials, execution state, and construction policies.

3 The APEX production-scheduling model

  • APEX represents alternative workplans, machines and personnel, shifts, preparation, material availability, and commitments; classical job shops and flow shops are special cases.The model supports competing objectives and weighted or scaled objectives arranged in lexicographic priority levels.Source: §3 · p. 4

3.1 Orders, workplans and execution alternatives

  • Workplans expand orders into operations and dependencies, while route choices select which operations are present and execution modes specify resources, phases, and simultaneous requirements.Lot quantities are inputs after expansion, not an economic lot-sizing decision; phase work may combine fixed and per-unit amounts, and work can differ from elapsed time.Source: §3.1 · pp. 4–5

3.2 Resource capacity, calendars and activity timing

  • Resource feasibility accounts for productive work and retained capacity, calendars, phase breaks, preparation, follow-up, and sequence-dependent activities.Product readiness can differ from resource release: inspection may delay product release while a machine processes another operation, whereas cleanup may continue after readiness.Source: §3.2 · pp. 5–6

3.3 Material availability, execution state and planning commitments

  • Material balances distinguish supplied stock and receipts from operation outputs; deterministic allocation can add availability dependencies but does not create missing production or purchase orders.Started operations' inputs are not deducted again.Source: §3.3 · p. 6
  • Replanning preserves recorded execution and resource reservations, while continuation schedules remaining work and required restart activities before resumption.Future output becomes available only after remaining work and release-gating follow-up finish.Source: §3.3 · pp. 6–7
  • Commitments can fix selected starts, modes, resources, workplans, or resource order; freeze horizons protect specified dimensions without necessarily fixing every decision.Mandatory construction policies restrict eligible next choices before heuristic ranking, and extensions can add sequence effects, measures, or hard checks.Source: §3.3 · p. 7

4 Construction and search

APEX search components propose different decisions but share a path for construction, evaluation, and validation. They include policy, tree, and direct schedule search, which can be combined under a shared candidate allowance.

4.1 One evaluation path, different search objects

  • Search components XG, XH, XT, and XE use a shared path from candidate choices through readiness, placement, objective evaluation, and validation.Predefined hooks let application modules filter construction choices, calculate objectives, and check added rules through that common path.Source: §4.1 · p. 7, Figure 1 · p. 8
  • Construction may fail to reach a feasible plan because the decoder appends work behind existing primary-resource occupancy; failed construction or exhausted search does not prove infeasibility.Accepted output is checked against the model and commitments, with mandatory policies verified against construction evidence.Source: §4.1 · p. 7

4.2 Direct schedule evolution

  • XE evolves operation-priority permutations alongside mode, route, and conditional-activity choices, using problem-filtered operators and a discounted upper-confidence bandit to allocate operator attempts.Its permutation is a priority list rather than an unconstrained sequence of start times; offspring receive one operator, and its Pareto reward does not directly maximize archive hypervolume.Source: §4.2 · p. 8

4.3 Combinations and budget accounting

  • Combined configurations apply components in the order named and divide one total candidate allowance across phases, carrying unused allowance forward.XE receives one best-so-far validated incumbent, while the observational Pareto archive does not seed later phases; candidate counts do not capture all timed work.Source: §4.3 · p. 8

5 Experimental design

The experiment compares APEX and external optimisers on three classical scheduling classes using a fixed instance set and evaluation budget. It defines the measured objectives, validation procedures, and aggregation rules that govern the comparison.

5.1 Classical problem classes and the tested core

  • The tested core represents operations as noninterruptible phases with one mode per eligible machine, then applies the defining JSP, FJSP and PFSP restrictions.All operations are mandatory; additional activities, materials and industrial operating policies are absent, and the PFSP common-permutation condition is independently checked.Source: §5.1 · p. 9

5.2 Comparison set and public instances

  • 69 instances—19 JSP, 32 FJSP and 18 PFSP—form the comparison set, selected for valid observations across all 12 methods and three seeds.The included instances span 6–50 jobs for JSP, 10–50 for FJSP and 20–100 for PFSP; the analysis is conditional on this set.Source: §5.2 · p. 9

5.3 External algorithms and discrete adapters

  • Four external algorithms use shared discrete adapters, but the comparison includes decoder behavior and implementation overhead rather than isolating outer search methods.NSGA-II, SPEA2, MOEA/D and SMS-EMOA are compared with population size 100; external JSP/FJSP decoding inserts operations into earliest feasible machine gaps, while APEX uses its own placement decoder.Source: §5.3 · pp. 9–10

5.4 Budgets, validation and runtime

  • Each configuration receives 1,000 complete-candidate evaluations, and exported nondominated schedules are independently audited for feasibility and recomputed makespan and flowtime.Runtime is single-worker internal wall time, including search setup, construction, observation and online validation, with eight runs concurrent on the same host.Source: §5.4 · p. 10

5.5 Objective normalisation and descriptive summaries

  • Makespan and total job flowtime are minimized; with zero releases, flowtime sums job completion times, and tardiness is excluded because instances lack due dates.Makespan is when the workload finishes; product readiness and main completion coincide, with no additional activities extending makespan.Source: §5.5 · p. 10
  • Across instances, results average each instance’s three-seed median; hypervolume deficit is relative to the best observed run, not a known Pareto front.Hypervolume summarizes archive quality and trade-off coverage; distribution plots show instance heterogeneity, not confidence intervals, and no significance tests are used.Source: §5.5 · p. 10

6 Computational results

Across 69 instances, XHTE and XHE lead in aggregate archive quality, but the strongest configuration varies by problem class and quality–time trade-offs. Progress traces also differ across classes and search components.

6.1 Overall quality and computation

  • 0.457% and 0.466% are XHTE’s and XHE’s mean relative hypervolume deficits; MOEA/D leads external methods at 2.248%.XHTE has the smallest makespan gap (1.717%) and XHE the smallest flowtime gap (3.053%); exported archive schedules pass independent feasibility and objective checks.Source: §6.1 · pp. 10–11, Table 3 · p. 11

6.2 Different problem classes favour different components

  • On JSP, XHT has the lowest mean deficit (0.192%); on FJSP, XH leads (0.171%), and added search phases do not improve every class average.The aggregate comparison conceals class-level differences in relative hypervolume deficit distributions.Source: §6.2 · p. 11, Figure 2 · p. 12
  • On PFSP, MOEA/D leads at 0.276%, while XE is the strongest APEX configuration at 0.343% and outperforms APEX combinations on all three class-mean quality measures.Their respective makespan gaps are 0.957% and 1.718%, and flowtime gaps are 1.529% and 1.776%.Source: §6.2 · p. 11, Figure 2 · p. 12

6.3 Quality and runtime are separate choices

  • XHT uses 39.819 s on average versus 33.129 s for XHTE because sequential combinations divide a fixed allowance between phases.Adding XE can replace evaluations in earlier phases, so the lower total time is not an unchanged search with additional work.Source: §6.3 · p. 11

6.4 Progress within the evaluation allowance

  • Policy-based configurations improve early on JSP and FJSP, while XE and MOEA/D make substantial late progress on PFSP.The observed class dependence supports selecting configurations according to production structure and available computation; Figure 4 tracks archive deficits at evaluation checkpoints against the final best observed archive.Source: §6.4 · pp. 11, 13, Figure 4 · p. 13

6.3 Quality and runtime are separate choices

  • At the common search allowance, external methods take 0.542–0.715 s on average, versus 30.068 s for XHE and 33.129 s for XHTE.On PFSP, XE takes 63.810 s versus MOEA/D’s 0.535 s, while on JSP and FJSP APEX’s better class-mean archive quality comes with greater measured computation.Source: §6.3 · p. 11, Figure 3 · p. 12

7 Agent-assisted operation and model extension

APEX separates agent operation of existing planning features from coding new semantics, with the core constructing and validating schedules. Synthetic studies tested these workflows and proposed a broader digital-twin integration.

7 Agent-assisted operation and model extension

  • The workflow agent translates planner requests into model changes and tool calls, while APEX constructs, evaluates, and validates schedules.The agent operates existing features; a separate coding study addresses new semantics.Source: §7 · p. 13
  • All 24 planning sessions passed independent checks, and all six submitted native objective or constraint implementations passed acceptance suites.Seven coding attempts produced six submissions; one constraint session timed out without submitting code.Source: §7 · p. 13, §7.5 · p. 15, Table 5 · p. 16

7.1 Adding planning rules

  • An M1 outage ban and a hard start/completion window for J3-2 were encoded as enforced rules, producing makespans of 6,300 s and 9,300 s.The checks covered both saved restrictions and their enforcement in schedules.Source: §7.1 · p. 13

7.2 Changing plan commitments

  • Fixing J2-1 to M2 at 3,600 s yielded an 8,400 s makespan, while freezing baseline operations starting before 1,800 s preserved the 4,800 s makespan.The checker verified the commitments, and the original plan remained available for comparison.Source: §7.2 · p. 14

7.3 Changing objectives

  • Prioritizing total mode cost reduced it from 30 to 12 while increasing makespan to 9,000 s; tardiness-first retained zero tardiness and baseline makespan.The requests changed the ranking hierarchy among existing measures.Source: §7.3 · p. 14

7.4 Comparing what-if scenarios

  • An M3 outage increased makespan by 900 s, while advancing J6-2’s soft due time and raising its priority changed makespan by zero and yielded 12,000 s weighted operation tardiness.The soft due-date change did not impose a hard deadline or replace the makespan objective.Source: §7.4 · p. 15

7.5 Implementing new objectives and constraints

  • Six submitted Rust implementations passed independent checks: three added priority-weighted squared tardiness and three added a hard workplace-balance rule.The objective reduced the public example’s squared penalty from 13 to 7 as makespan rose from 6 to 7 s; the balance rule reduced exposure difference from four to zero as makespan rose from 3 to 4 s. The scheduling core and manifests were unchanged.Source: §7.5 · p. 15

7.6 Towards a digital twin for production decisions

  • The proposed digital-twin loop refreshes observed state, keeps hypothetical alternatives separate, and releases a reviewed plan version through a deployment-specific return path.The writeback and dispatch path is not implemented in the current planning workflow.Source: §7.6 · p. 15, Figure 6 · p. 16

8 Limitations and next evidence steps

The reported evidence is conditional on selected public instances, a particular comparison setup, and synthetic agent studies. The authors identify limits in statistical inference, runtime comparability, model reach, and deployment evidence.

Comparison set and descriptive evidence

  • The 69 public instances are not a representative random sample, and requiring completion by every method and seed means the comparison does not measure completion reliability.The three classes have unequal counts, so the overall mean gives greater weight to FJSP; equal-class aggregation is supplementary, not independent confirmation.Source: §8 · p. 16
  • Three seeds provide limited evidence on stochastic variation, and the rankings establish neither statistically reliable differences nor consistent superiority on unseen instances.This is especially relevant to the small aggregate difference between XHTE and XHE.Source: §8 · p. 17

Comparison scope and time

  • The comparison omits several scheduling baselines, and equal candidate counts do not equalize all search work or runtime; measurements reflect a shared, heterogeneous host.The 1,000-evaluation allowance is modest for larger instances, and sequential combinations do not isolate component effects. Matched-time experiments on an idle host are needed for fixed-deadline quality comparisons.Source: §8 · p. 17

Metrics and references; Model and deployment reach

  • Hypervolume depends on scaling and reference point, observed best values are not optima, and the classical benchmark supports no inference about tardiness.The model and deployment evidence also has bounded reach: arbitrary preemption and stochastic simulation are unsupported, extended-model performance is unvalidated, and the snapshot studies establish neither a deployed feedback loop nor digital-twin conformity.Source: §8 · p. 17

Synthetic agent-study scope

  • The agent studies cover familiar, precisely specified synthetic tasks rather than broad production conditions, and do not establish general extension reliability or industrial productivity.They exclude clarification and conflict handling, use an isolated library host, and do not test live ERP/MES integration or human-time comparisons.Source: §8 · p. 17

9 Conclusion

APEX combines a production model with hybrid search and agent-assisted refinement. On the benchmark, leading configurations vary by problem class and objective; separate workflow and coding studies report successful independently checked changes.

Benchmark results

  • XHTE has the smallest mean hypervolume deficit and makespan gap, while XHE has the smallest flowtime gap and lower measured runtime across the 69-instance comparison set.Class-specific hypervolume leaders are XHT for JSP, XH for FJSP and MOEA/D for PFSP; standalone XE is the strongest APEX configuration on PFSP.Source: §9 · p. 17

Agent-assisted workflow

  • All 24 sessions completed the requested rule, plan, objective or what-if task while preserving the baseline, with evidence limited to supported operations on a small synthetic factory.Source: §9 · p. 17

Native extensions

  • All six submitted implementations of a new squared-tardiness objective or hard exposure-balance rule passed independent checks and changed schedule ranking or admissibility without changing the core.Source: §9 · p. 18

Framework contribution

  • APEX shares a general production representation across search methods and agent-assisted configuration, scenario work and implementation of new constraints or objectives.The representation includes workplans, resources, materials and commitments.Source: §9 · p. 18

Future work

  • Monte Carlo production simulation is proposed as a next application, with XG constructing or repairing schedules at simulated decision points using priorities prepared by XH.Evaluation would need to consider expected performance, adverse outcomes and disruption to existing commitments, while using only information available at each decision time.Source: §9 · p. 18
  • An industrial field study with planners, live data and execution feedback is proposed to examine model fit, approval effort, planner workload and production outcomes.The proposed study distinguishes approval to release a plan from approval to change the model, objectives, decision logic or agent permissions.Source: §9 · p. 18

A.1 Problem-class summaries and aggregate weighting

The appendix reports quality and time summaries by problem class and a supplementary aggregate that weights JSP, FJSP and PFSP equally. Both summaries use lower values as better, with XG excluded from the runtime minimum.

Class summaries

  • Table 6 reports class-level means of instance-level seed medians, marks minima within each class, and excludes XG from the runtime minimum.Source: Table 6 · p. 20

Aggregate weighting

  • Table 7 averages the three class-level values with equal weights, making the aggregate less influenced by differences in class sample sizes.Source: §A.1 · p. 20, Table 7 · p. 21

Comparison conventions

  • Both tables use lower-is-better comparisons, and Table 7 marks column minima while excluding the one-construction XG reference from the runtime minimum.Source: Table 6 · p. 20, Table 7 · p. 21

A.2 Separate objective distributions

Figures 7 and 8 show per-instance gaps from the lowest observed value for makespan and total job flowtime, respectively. Their display conventions match, but the horizontal scales differ between Figure 7 panels.

Makespan

  • Figure 7 plots makespan gaps from each instance’s lowest observed makespan, with each point representing a median over three seeds and all observations retained.Boxes and whiskers follow Figure 2’s convention, and horizontal scales differ between panels.Source: Figure 7 · p. 21

Total job flowtime

  • Figure 8 plots total job-flowtime gaps from each instance’s lowest observed value using Figure 7’s aggregation and display conventions.A method’s best makespan and best flowtime may occur in different schedules.Source: Figure 8 · p. 22

A.3 Instance inventory and per-instance results

The appendices document the benchmark inventory and search settings, reproducibility materials, and protocols and measurements for synthetic workflow and native-extension studies.

A.3 Instance inventory and per-instance results

  • The benchmark inventory covers 69 instances, and per-instance tables report medians over three seeds for each instance and method.Bold entries use unrounded values; individual seeds, objective values, archives and evaluation traces are retained in machine-readable results.Source: Table 8 · p. 22, §A.3 · p. 22, Table 9 · p. 24

A.4 Search settings

  • APEX search configurations specify algorithm-specific operators and parameters, while all searches receive 1,000 complete-candidate evaluations, divided across phases in combined configurations.External methods use population size 100; seeds are 19, 42 and 73, with one worker per method.Source: §A.4 · p. 26

A.5 Code and reproducibility

  • Run records preserve provenance, seeds, settings, timings and solutions, and the independent audit checks schedule feasibility, objectives and archive hypervolume.Tables and figures are regenerated from records without new solver runs.Source: §A.5 · p. 26

A.6 Synthetic workflow protocol and measured effort

  • The synthetic workflow study used fresh contexts and independently checked model changes, schedules and scenario actions; its 24 sessions accumulated 17.6 minutes of session time.The sessions used a six-job fixture, fixed request order and constrained tool and search budgets.Source: §A.6 · pp. 26–27, Table 12 · p. 27

A.7 Native-extension implementation protocol

  • The native-extension evaluation tested new objective and constraint modules through a compiled submission interface and independent checks, with six sessions producing final submissions.Among submitting sessions, median time was 198.0 s for the objective and 249.6 s for the constraint; final acceptance demonstrates completion with feedback, not first-attempt correctness.Source: §A.7 · pp. 27–28
Loading 2609.33430v1…