Paper deep dive
Agentic AI-Assisted Modeling for Production Scheduling: Assessment in Constraint Programming
Ăngel SĂĄnchez-FernĂĄndez, Javier Pernas-Ălvarez, Diego Crespo-Pereira
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 96%
Last extracted: 10/11/2026, 3:56:16 AM
Summary
This study assesses the capability of general-purpose Large Language Models (LLMs) to formulate and implement Constraint Programming (CP) models for production scheduling problems using agentic architectures. It compares single-agent and multi-agent workflows, integrated with a Model Context Protocol (MCP) server for context-aware documentation retrieval, against a direct LLM baseline. The multi-agent approach significantly improved execution success rates from 14.8% to 59.3% (80.6% on simpler problems), demonstrating that while formulation is feasible, implementation remains a barrier, particularly for complex intralogistics models.
Entities (11)
Relation Signals (7)
Constraint Programming â usedfor â Production Scheduling
confidence 98% · Agentic AI-Assisted Modeling for Production Scheduling: Assessment in Constraint Programming
Agentic AI â uses â Large Language Models
confidence 98% · This study bridges both directions by assessing whether general-purpose LLMs, orchestrated as agents... can formulate and implement constraint programming models
Agentic AI â appliedto â Constraint Programming
confidence 97% · assessing whether general-purpose LLMs... can formulate and implement constraint programming models
Multi-agent workflow â improves â execution success rate
confidence 96% · The multi-agent workflow raises the share of scripts that run correctly as generated from 14.8% with a direct LLM call to 59.3%
Multi-agent workflow â outperforms â Direct LLM baseline
confidence 96% · The multi-agent workflow raises the share of scripts that run correctly as generated from 14.8% with a direct LLM call to 59.3%
Model Context Protocol â supports â Agentic AI
confidence 95% · Single-agent and multi-agent architectures are integrated with a Model Context Protocol server that provides context-aware retrieval of solver documentation
Agentic AI â addresses â Hallucination
confidence 93% · integrated with a Model Context Protocol server... to mitigate hallucinations during implementation
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Developing optimization models for production scheduling requires substantial expert effort. Research on large language models (LLMs) has followed two directions: specialized approaches for automated modeling, mostly for mixed-integer linear programming, which often rely on dedicated training or problem-specific architectures that limit industrial deployment; and agentic artificial intelligence for operational decision support, which generally assumes that the optimization model already exists. This study bridges both directions by assessing whether general-purpose LLMs, orchestrated as agents without task-specific training, can formulate and implement constraint programming models from natural-language problem descriptions. Singleagent and multi-agent architectures are integrated with a Model Context Protocol server that provides context-aware retrieval of solver documentation to mitigate hallucinations during implementation. Both are compared with a direct LLM baseline on six industry-oriented problems covering flow-shop, job-shop, flexible job-shop and resource-constrained warehouse scheduling, using three LLMs and assessing modeling accuracy, execution success, latency and token consumption. Formulation proves largely within reach of current LLMs, whereas implementation is the main barrier. The multi-agent workflow raises the share of scripts that run correctly as generated from 14.8% with a direct LLM call to 59.3%, reaching 80.6% on the four less complex problems, while tightly coupled intralogistics models remain an open challenge.
Tags
Links
- Source: https://arxiv.org/abs/2610.10184v1
- Canonical: https://arxiv.org/abs/2610.10184v1
Trouble viewing inline? Open PDF directly â
Full Text
93,135 characters extracted from source content.
Expand or collapse full text
Agentic AI-Assisted Modeling for Production Scheduling: Assessment in Constraint Programming Ăngel SĂĄnchez-FernĂĄndeza*, Javier Pernas-Ălvareza ORCID: 0000-0001-9185-3583 and Diego Crespo-Pereiraa ORCID: 0000-0002-0797-249X â thanks: * Ăngel SĂĄnchez-FernĂĄndez. Email: angel.sanchez1@udc.es. ORCID: 0009-0008-7139-4736 Abstract Developing optimization models for production scheduling requires substantial expert effort. Research on large language models (LLMs) has followed two directions: specialized approaches for automated modeling, mostly for mixed-integer linear programming, which often rely on dedicated training or problem-specific architectures that limit industrial deployment; and agentic artificial intelligence for operational decision support, which generally assumes that the optimization model already exists. This study bridges both directions by assessing whether general-purpose LLMs, orchestrated as agents without task-specific training, can formulate and implement constraint programming models from natural-language problem descriptions. Single-agent and multi-agent architectures are integrated with a Model Context Protocol server that provides context-aware retrieval of solver documentation to mitigate hallucinations during implementation. Both are compared with a direct LLM baseline on six industry-oriented problems covering flow-shop, job-shop, flexible job-shop and resource-constrained warehouse scheduling, using three LLMs and assessing modeling accuracy, execution success, latency and token consumption. Formulation proves largely within reach of current LLMs, whereas implementation is the main barrier. The multi-agent workflow raises the share of scripts that run correctly as generated from 14.8% with a direct LLM call to 59.3%, reaching 80.6% on the four less complex problems, while tightly coupled intralogistics models remain an open challenge. keywords LLM; Agent; Production Planning; Constraint Programming; Scheduling â articletype: Research Articleâ affiliation: aUniversidade da Coruña, Campus Industrial de Ferrol, CITENI, Grupo Integrado de IngenierĂa, Esteiro s/n, Ferrol, 15403. 1 Introduction In recent years, society has undergone a profound transformation driven by the rapid adoption of artificial intelligence (AI) based solutions. At the same time, the benefits of these technologies have become commonplace in academic research and discussions among industry experts in nearly every sector, with Operations Research (OR) emerging as a particularly promising application domain for Large Language Models (LLMs). Despite the maturity of simulation and optimization techniques, a significant gap remains between industrial practitioners and OR experts, since developing optimization models demands specialized expertise in mathematical formulation, problem understanding, requirements definition, coding, and data management, all of which make the modeling process time-consuming, costly, and often inaccessible to non-experts. This challenge has led to the concept of optimization democratization, in which AI serves as a bridge between both stakeholders by reducing technical barriers and enabling non-experts to develop and use optimization models more effectively (Ivanov, 2026; Simchi-Levi et al., 2025). A growing stream of recent OR are centered on the emerging concept of Agentic AI, which leverages LLMs as cognitive engines capable of integrating task planning, tool invocation, and reflective reasoning (Jannelli et al., 2025a; Rossi and Prestwich, 2026). Through these capabilities, agentic systems can iteratively decompose and execute complex goals without relying on fully predefined workflows. In the OR domain, most current applications are oriented toward intelligent manufacturing and supply chain management, where AI agents can access relevant system information and augment the capabilities of digital twins and previously formulated mathematical models (Chen et al., 2026b; Schmitt et al., 2026; Ye and Li, 2026). Building on these resources, agentic systems can translate operational requirements into optimization scenarios, execute optimization solvers, extract and configure model parameters, and interpret results through natural language. This type of agentic integration closely aligns with the Industry 5.0 paradigm, where autonomy is oriented toward supporting human-centric decision making, human-AI collaboration, and intuitive interaction rather than replacing human responsibility (Ivanov, 2026; Leng et al., 2026; Ye and Li, 2026). Nevertheless, most functionalities of current agent-based solutions still rely on optimization models that have already been developed. This raises several open research questions concerning the distribution of tasks between LLMs and human experts, the extent to which modeling activities can be delegated to autonomous agents, and the mechanisms through which human users can validate, supervise, and effectively exploit their outputs. In this context, a particularly relevant question is whether LLM-based frameworks can construct the optimization model itself from scratch and support the complete modeling workflow, from mathematical formulation to results reporting, including model coding, execution, and interpretation, based solely on problem data and a natural-language problem description. Several recent studies have begun to explore this direction, from which the following research gaps (RG) can be identified: âą RG1 - Knowledge engineering bottlenecks: Many high-performing framework architectures, such as SMILO, SyntAGM or OptiMind, require domain experts to construct the inputs and modeling knowledge used to guide the LLM. This dependence on expert-defined knowledge limits their scalability and transferability across different application domains (Li et al., 2026b; Rossi and Prestwich, 2026; Zhang et al., 2025). âą RG2 - Limited Benchmarking: Current evaluation is often hindered by benchmarks that contain ambiguous problem data, incorrect reference answers, or missing parameters. In addition, many benchmarks reported in the literature remain relatively general, relying on small-scale instances and conventional OR problems that have already been extensively studied. Therefore, new benchmarking efforts are needed to assess LLM-based frameworks on more complex, realistic, and demanding optimization problems. âą RG3 - Token Consumption and latency: The execution of high-dependency, multi-agent systems, such as Chain-of-Experts architectures, and complex reasoning-based LLM workflows is often constrained by token limits and finite context windows (Rossi and Prestwich, 2026). Moreover, these frameworks typically involve substantial token consumption and high latency, which are frequently overlooked despite their direct impact on practical applicability. Therefore, token efficiency should be explicitly considered when developing LLM-based solutions and discussed in relation to the requirements of the target application. From the authorsâ perspective, this performance indicators are still insufficiently incorporated into robust benchmarking metrics. âą RG4 - Hallucination: Since LLMs are probabilistic next-token predictors, they may hallucinate across multiple stages of the optimization process. During mathematical formulation, this can lead to the generation of nonexistent constraints, decision variables, or incorrectly specified objective functions. Similarly, during coding tasks involving specific optimization programming APIs, hallucinations may result in syntactically incorrect code, physically impossible models, or mathematically infeasible formulations. âą RG5 - Limited exploration of LLM-optimization interactions: In the context of LLM-assisted frameworks for optimization, significant progress has been made in certain optimization methods, particularly mixed-integer linear programming (MILP). However, the use of LLMs to support the formulation, coding, and execution of CP models remains underexplored. This represents a relevant research gap, as CP has emerged as a strong alternative to MILP and has proven particularly effective for solving large-scale combinatorial problems in industrial settings. This work addresses the identified research gaps by advancing the development of AI-assisted frameworks for solving OR problems through human-machine interaction based on natural language. The proposed approach aims to assess how autonomous agents can perform formulation and modeling tasks by delegating complex reasoning and coding to LLMs, while supporting human decision-making through more accessible optimization modeling. To this end, we propose several agentic approaches: First, a multi-agent framework is structured around two key stages of the optimization modeling process: (i) natural-language information processing and model formulation, where the problem description is translated into a set of decision variables, constraints, and an objective function; and (i) model encoding according to the solver specifications, where the agent can retrieve and validate the required functions, handle parameter formats, and assemble the resulting model in accordance with the formulated problem. Second, a single-agent architecture is developed to assess whether assigning both stages to a single agent provides any benefits compared with the multi-agent approach. Nevertheless, in both approaches, the encoding architecture incorporates an MCP server hosting the solver API documentation. Through a context-retrieval toolset, the agent can identify and retrieve the relevant functions and specifications required for model encoding, with the aim of reducing hallucinations during this second stage. The experiments conducted in this work aim to assess the extent to which these agentic approaches improve model generation compared with direct LLM-based modeling, while broadening the empirical evaluation of the field through six industry-based problems of varying complexity and a set of relevant performance indicators. Specifically, this work makes the following contributions in response to the identified research gaps: âą Scalable multi-agent modeling framework: An AI-agentic framework has been developed for the formulation and modeling of mathematical optimization problems using CP. The proposed framework reduces the degree of expert-in-the-loop involvement through a structured workflow composed of three main stages: preprocessing of the problem description and input data, mathematical model formulation, and encoding for direct implementation. The framework is organized into clearly differentiated modules, enabling its scalability to other optimization techniques (RG1 and RG5). âą MCP-based tool orchestration for CP: We developed an MCP server with a modular architecture in which the tools exposed to the LLM correspond to predefined methods of the CP API. This enables the LLM to translate the mathematical formulation into a CP model through structured tool selection and invocation. The toolset developed in this work allows the agent to search relevant documentation and modeling examples, and to identify and validate the functions required for model implementation without loading the entire API documentation into the context. This reduces unnecessary contextual information and token usage while helping to mitigate hallucinations during the model encoding and execution stages (RG4 and RG5). âą LLMs benchmarking across industrial scheduling problems: The proposed framework is tested across six different scheduling problems, including flow-shop, job-shop, flexible job-shop, and three variants of resource-constrained scheduling involving transport and picking tasks in automated warehouses. These problems were selected to represent different problem structures and levels of complexity in terms of the number and type of decision variables, constraints, resources, and operational parameters, thereby challenging the evaluated LLMs under diverse and demanding conditions. The objective is to assess their performance in terms of effectiveness, measured through modeling accuracy, and efficiency, measured through token usage and latency, for both formulation and model execution tasks (RG2 and RG3). The remainder of this paper is organized as follows. Section 2 reviews the literature on constraint programming models for production scheduling, LLM-based approaches to mathematical optimization, and agentic AI applications in scheduling and manufacturing. Section 3 presents the proposed agentic workflows and MCP architecture. Section 4 describes the experimental procedure and presents the experimental results. Section 5 discusses the main findings and their implications. Finally, Section 6 concludes the paper and outlines directions for future research. 2 Literature Review 2.1 Large Language Models for mathematical optimisation In recent years, multiple contributions have addressed the generation of mathematical models from natural-language descriptions, with the potential to facilitate the adoption and transfer of mathematical optimization methods to organizations lacking dedicated expertise in this field. In fact, models such as GPT, Claude, DeepSeek, and Gemini have been evaluated on mathematical reasoning benchmarks, showing strong performance in tasks requiring complex reasoning (Wang et al., 2025). Regarding the use of LLMs and recent advances in the automation of mathematical modeling, different methodological strategies can be distinguished, together with the optimization techniques adopted in each development. In particular, recent contributions on LLM-assisted modeling for mixed-integer linear programming (MILP) problems have demonstrated promising results in the automatic generation of mathematical formulations. OptiMind is a Small Language Model (SLM) specifically developed for this purpose through expert-supervised fine-tuning using training data derived from representative OR problem classes. The reported results show that this domain-specific training substantially improves the accuracy of the generated formulations, outperforming its base model, local models such as Qwen3-32B, and even frontier models (Zhang et al., 2025). In OptiMUS-0.3, the authors adopt a training-free approach and design a multi-agent workflow compatible with general-purpose LLMs, incorporating retrieval-augmented generation (RAG) capabilities to retrieve domain-specific context and relevant examples that support the formulation process and improve modeling accuracy. Subsequently, SMILO (Li et al., 2026c) introduces a graph-based approach for model construction and deterministic formulation assembly, guided by expert-defined modeling knowledge, and substantially outperforms OptiMUS on shift and days-off scheduling problems. However, these developments suggest a clear trade-off between scalability and accuracy when comparing general-purpose solutions for MILP model generation with ad hoc approaches designed for problems of manageable complexity and a specific problem structure. Further relevant studies have proposed integrated frameworks in which agents, RAG mechanisms, LLMs, and domain-specific tools are combined to support the generation of MILP models in industrial settings (Chen et al., 2026c; El Baz et al., 2026; Jiang et al., 2026; Hu and Li, 2026). Regarding the generation of CP models from natural-language descriptions, the literature remains comparatively limited. Nevertheless, ConstraintLLM (Shi et al., 2025) has emerged as a fine-tuned model for addressing industrially relevant problems through the PyCSP3 solver, incorporating a tree-of-thought reasoning mechanism and iterative self-correction. The reported results show improved performance compared with general-purpose LLMs such as GPT-4o and DeepSeek-V3. Regarding its broader industrial applicability and scalability, some limitations persist, including its reliance on a specific solver and a training strategy restricted to the Qwen2.5 model family. Other approaches rely on domain-specific languages (DSLs) to constrain LLM outputs and ensure that the generated models are fully executable by the target solver. However, this comes with inherent limitations, particularly due to the need to define problem- and solver-specific semantic rules (Shi et al., 2026). Table 1 summarizes the main contributions to the automatic generation of mathematical optimization models using LLMs. The reviewed studies show that approaches for CP model generation remain comparatively limited with respect to techniques such as MILP. They also reveal a clear tendency to trade modeling generality for accuracy, as architectures become increasingly tailored to specific solvers and problem classes in order to mitigate hallucinations. In this context, agentic AI appears to be a promising alternative due to its flexibility in knowledge retrieval, modular architectural design, and iterative reasoning capabilities. Table 1: Recent contributions for automated mathematical modelling with LLMs. Work Approach Summary Method Train Scalability (Sol ⣠Prob ⣠LLM) OptiMind SLM fine-tuned and hint injection MILP â â ⣠â ⣠â OptiMUS-0.3 Modular agent with constraint graph & reflective correction MILP Ă â ⣠â ⣠â SMILO Modelling graph-guided tasks & template assembly MILP Ă â ⣠â ⣠â Chen et al. Domain specialization via knowledge-augmented fine-tuning MILP â â ⣠â ⣠â El Baz et al. Agentic model with human-in-the-loop OR expert MILP Ă â ⣠â ⣠â RideAgent Small-sample guided heuristic agent for variable fixing MILP Ă â ⣠â ⣠â Hu and Li GAR/GPVSS with Feasibility-Aware Constrained Decoding (FACD) MILP â â ⣠â ⣠â ConstraintLLM LLM fine-tuned with Constraint-Aware Retrieval Module CP â â ⣠â ⣠â Shi et al. Domain-Specific Language with dual program views for JSP CP/MILP Ă â ⣠â ⣠â Legend: Train: â = Uses base LLM training/SFT; Ă = No training required. Scalability: Sol = Solver, Prob = Problem class, LLM = LLM generalization. Symbols: â = Highly scalable (Directly adaptable); â = Medium (Reasonable work needed); â = Low scalability (Completely ad-hoc/difficult to scale). 2.2 Constraint Programming for Production Scheduling Given the substantial body of recent work focused on MILP-based approaches, it is also relevant to explore alternative optimization paradigms such as CP, which has demonstrated strong applicability to NP-hard and combinatorial optimization problems arising across a wide range of scheduling domains. In many of these settings, CP has shown competitive performance with respect to mixed-integer programming (MIP) and MILP approaches, particularly for highly constrained and large-scale problem instances. Existing contributions can be grouped according to several problem classes of industrial relevance, for which CP-based procedures have been evaluated on instances whose scale considerably exceeds that of traditional OR formulations and benchmark settings. In the context of the job-shop scheduling problem (JSSP), common CP formulations rely on arrays of interval variables combined with precedence and non-overlap constraints. Both commercial and open-source CP engines have been evaluated, including IBM ILOG CP Optimizer (CPO) (Laborie et al., 2018) and the CP-SAT solver from OR-Tools (Perron et al., 2023), together with hybrid platforms such as Hexaly, formerly LocalSolver, which combines local search with constraint propagation and linear relaxations behind a single modelling interface (Benoist et al., 2011; Hexaly, 2026). Reported results highlight the scalability of these solvers, with CPO being able to address instances involving up to approximately one million operations, thereby illustrating the potential of CP for large-scale industrial applications such as semiconductor manufacturing (Da Col and Teppan, 2022). A recent controlled benchmark of CPO, CP-SAT, Hexaly and OptalCP on 332 JSSP instances of up to 1000Ă10001000Ă 1000 operations confirms this scalability and shows that no single engine dominates: OptalCP and CPO certify the largest number of optima, whereas Hexaly returns the best schedules on industrial-scale instances with tens of thousands of operations, which supports an instance-aware choice of solver (Yuraszeck et al., 2026b), an idea also exploited through machine-learning-based solver selection for the flexible job shop (MĂŒller et al., 2022). When the same job-shop models are formulated for MILP and CP solvers, CP consistently attains the smallest deviations from the best-known solutions on medium and large instances, whereas MILP solvers remain competitive only on small ones (Naderi et al., 2023). Within the JSSP family, other variants also incorporate transportation between workstations by explicitly integrating task allocation to multiple robots. For benchmark instances from the literature, CP-based formulations have been reported to achieve strong computational performance, outperforming previous MIP formulations (Ham, 2021). On the other hand, relevant applications can also be found within the Flexible Job Shop Scheduling Problem (FJSP) family. One study addresses an FJSP variant with compatible job families, in which the number of jobs that can be processed simultaneously is constrained by equipment capacity (Ham and Cakici, 2016). In this case, MIP formulations were compared with CPO on medium- and large-scale instances, with CPO showing clearly superior computational performance and reaching optimal solutions within relatively short solution times. This problem class has also been investigated in distributed manufacturing networks, where CP-based approaches have been reported to outperform four different MILP formulations and metaheuristic methods (Meng et al., 2020). Hybrid platforms have likewise been adopted where exact MILP models cease to be viable: in the lot-sizing and scheduling of metal parts for car seats, a Hexaly model complements a MIP formulation and GRASP and VNS metaheuristics to minimise changeovers on the largest instances (Colmenar et al., 2024). Beyond manufacturing, CP has also demonstrated relevant applications in warehouse scheduling and allocation problems arising in intralogistics optimization, where operational decisions must be coordinated under strict time-window constraints. The literature includes CP formulations incorporating integer assignment variables that outperform previous MIP formulations and achieve optimal solutions within fractions of a second (Telha and GonzĂĄlez-RamĂrez, 2025). Within the same application domain, CP has also been integrated with complementary optimization tools to jointly address order-line batching, batch scheduling under deadlines, and picker routing within a unified framework (Haouassi et al., 2022). This integration of multiple optimization tools with CP for highly demanding real-world problems has been successfully applied in several settings. In the context of FJSP in the shipbuilding industry, a two-stage CP-based decomposition has been proposed. In the first stage, the temporal scheduling of operations is addressed according to due-date requirements while minimizing the makespan. In the second stage, the spatial allocation of resources and working areas is optimized, with the proposed approach outperforming corresponding MILP formulations (Pernas-Ălvarez et al., 2025). Decomposition strategies have also been proposed for the JSSP, including approaches in which an initial phase generates a warm start for a subsequent stage, where relaxations are introduced on temporal constraints (Yuraszeck et al., 2026a). Overall, the reviewed literature highlights the strong capability of CP-based solvers to address NP-hard problems, together with their flexibility in model formulation and their suitability for decomposition-based solution strategies. These characteristics make CP particularly attractive for computationally demanding industrial environments. 2.3 Agentic AI in scheduling Within this context, it is useful to distinguish the main roles currently assigned to agentic AI in industrial scheduling applications. On the one hand, some workflows employ agents as active generators of optimization models, where they contribute directly to problem formulation, model construction, and solver integration. On the other hand, several approaches assume that the underlying optimization or simulation model has already been developed. In these cases, agents operate around the existing model by supporting tasks such as data interpretation and contextualization, experiment execution, result analysis, or decision support at the operational level. This distinction helps clarify whether agentic AI is being used to automate the modeling process itself or to enhance the interaction with and exploitation of previously established optimization and simulation models. Regarding the first category, apart from the LLM-based approaches discussed in Section 2.1, most of which are not agentic, only one of the reviewed studies focuses on an agent capable of generating MILP models in Python from natural-language specifications, incorporating a human-in-the-loop mechanism between the optimization and simulation stages (El Baz et al., 2026). Beyond this contribution, another agentic approach has been proposed for constraint programming, in which an MCP-based architecture connects the LLM with symbolic solvers to enable autonomous CP model generation, reporting 100% accuracy across 101 benchmark problems (Szeider, 2025). Despite the clear advantages of these agentic approaches for automated model generation, their validation remains largely limited to benchmark settings, with limited evidence of industrial applicability. In contrast, multi-agent frameworks have also been evaluated directly in smart manufacturing environments by implementing sequential workflows and combining RAG mechanisms with chain-of-thought reasoning to retrieve relevant knowledge from software libraries and support model generation under dynamic production requirements (Li et al., 2026a). Regarding the second category, a broader range of agentic AI applications and use cases can be identified (Chen et al., 2026a). In these approaches, agents are typically employed either to contextualize operational data and physical system requirements in order to support decision-making and trigger actions on pre-existing models (Ye and Li, 2026; Xiang et al., 2026), or as conversational assistants capable of connecting to databases and internal tools to provide decision support at the shop-floor level (Jannelli et al., 2025b; Yuan et al., 2025). Taken together, the reviewed literature shows that LLM-based agentic tools have been applied mainly to operational and shop-floor tasks, while their use for mathematical formulation and optimization modeling remains largely unexplored. This gap motivates the investigation of modular agentic architectures that can be adapted to different optimization paradigms and solvers while streamlining the modeling process. 3 Methodology The methodology adopted in this work is structured around two main sections: Section 3.1 presents the evaluated agentic framework, while Section 3.2 describes the MCP-based tool architecture. 3.1 Agentic Framework The proposed framework is implemented in three workflows (Figure 1) that differ only in how the modelling task is distributed: (a) a multi-agent pipeline in which formulation and coding are assigned to two specialised agents, (b) a single agent that performs both tasks, and (c) a baseline in which the LLM completes the whole task in a single call without tool access. Workflows (a) and (b) are connected to an MCP server that exposes the documentation of docplex.cp, the Python modelling interface of IBM ILOG CP Optimizer. All workflows receive the same problem prompt and return a standalone Python script that reads the instance data from an SQLite database, builds and solves the CP model, and reports the solution. The workflows were built in Langflow Desktop (version 1.11.6), and was chosen because it is built on LangChain and LangGraph, the de facto open-source for constructing LLM agents, and thus keeps the workflows independent of any single provider. Table 2 summarises the components of each workflow and their key settings. To isolate the effect of the architecture, the sampling parameters are identical in all workflows, the same LLM is assigned to every component within a run, and each component uses the same system prompt for every LLM. All prompts, output contracts and instance data are publicly available in the project repository (SĂĄnchez-FernĂĄndez et al., 2026). Table 2: Langflow components of each workflow. All components share the same LLM settings: temperature 0.15 and a limit of 15 000 output tokens per call. Workflow Component Task MCP tools Max. iterationsa (a) Multi-agent Formulator Agent Formulation and implementation plan â 10 Executor Agent Coding of the given formulation 6 50 (b) Single agent Executor Agent Formulation and coding 6 50 (c) Direct LLM LLM call Formulation and coding â 1 tabnote a Maximum number of LLM calls in the agent loop; each call either requests tool calls or returns the final answer. The components of the framework are described below. Figure 1: Three workflows compared in this study. (a) Two-stage multi-agent pipeline: a tool-free Formulator Agent hands a formulation to an Executor Agent connected to the MCP documentation server. (b) Single Executor Agent connected to the same MCP server. (c) Direct LLM baseline without tool access. Figure 2: Structure of the prompts. The task message that enters every workflow, shown for problem PC1: four sections in a fixed order, with the process described in natural language only, the identity of the SQLite instance, the schema of every table generated from the database file, and the conventions left open by the description. The complete prompts and the task messages of PC1âPC6 are provided as supplementary material and in the project repository (SĂĄnchez-FernĂĄndez et al., 2026). âą Prompt: Figure 2 shows how the prompts are designed. The input to every workflow is a task message with four sections, identical for all workflows and LLMs. The problem description states in natural language the process to be scheduled, its operational requirements and its objective, without any formulation guidance: sets, decision variables, constraints and the type of model must be identified entirely by the LLM. The data source gives the file name and path of the SQLite database that holds the instance, and the data schema describes each of its tables with the exact CREATE TABLE statement, the row count, an ordered load query and three sample rows, all generated from the database file; the instance values themselves are never placed in the prompt, so the LLM must write the code that retrieves them at execution time, which keeps the context small and independent of the instance size. The system prompts used by the agents (workflows (a) and (b) in Figure 1) and by the single LLM (workflow (c)) are available in the repository (ref_repo_AgenticPScheduling). These system prompts are designed to define the role of each component. âą Formulator Agent: Used only in workflow (a), this agent translates the problem description into a structured specification for the Executor Agent. It has no tool access and works under a system prompt that defines its role, its input and a three-part output contract: (i) the mathematical formulation, with sets, parameters, decision variables, labeled constraints and objective; (i) a data contract with the SQL queries needed to load each parameter; and (i) an execution plan for implementing the model. âą Executor Agent: This agent produces the final script. In workflow (a) it implements the formulation received from the Formulator Agent, whereas in workflow (b) it also formulates the problem. Its system prompt defines the input, the available MCP tools, a four-step protocol for their use and the structure of the script, which consists of three blocks: data acquisition, CP model, and results report. Before writing any code, the agent must use the tools to verify every docplex.cp function it intends to call. Owing to the tool calls and the documentation added to its context, this is the most expensive component of the framework. âą Direct LLM: In workflow (c), in addition to the user prompt, the LLM receives a system prompt that asks for the formulation and the script, with the same three-block structure, in a single response. âą MCP Server: The server gives the agents in workflows (a) and (b) access to the docplex.cp documentation through six tools organised in two levels. Three discovery tools locate relevant content: keyword search, the symbol index of a module, and a catalogue of solved modelling examples. Three precision tools then return the full reference of the selected items: function signatures and parameters, complete example models, and module references. Checking the API before coding reduces hallucinated function calls, at the cost of additional tokens. The server is described in Section 3.2. âą SQLite database: Each of the six problems is stored in its own SQLite database, whose schema matches the one described in the prompt. The generated script is required to open the database in read-only mode and to load all instance data through SQL queries, with no hard-coded values. 3.2 MCP architecture The Executor Agent is designed to generate a script that runs successfully on the first attempt, since the objective of this work is to assess whether agentic approaches can directly produce a valid optimization model without relying on iterative correction procedures. Two main failure modes are considered. The first is formulation error, which is particularly critical because an incorrect mathematical representation of the problem may lead to invalid or misleading decision-support outcomes. The second concerns hallucinations in the use of the solver API, including plausible but non-existent functions, incorrectly named or ordered arguments, and constructs borrowed from related libraries such as docplex.cp. These errors were frequently observed during the preliminary experimentation. The documentation server described in this subsection is, therefore, designed to make verification of the docplex.cp API more accessible and less costly for the agent than relying on unsupported assumptions. Table 3 defines the terms used in the rest of this subsection. Table 3: Nomenclature of the documentation corpus, illustrated with the method solve of class CpoModel. Term Definition Example Module A docplex.cp sub-package, documented in one reference file (four in the corpus) docplex.cp.model Symbol A documented function, class or method (186, 15 and 132 in the corpus) method solve of class CpoModel Qualified name Unique path of a symbol: module, class (if any) and name. Short names may be ambiguous docplex.cp.model.CpoModel.solve short name solve; add matches two classes Chunk Retrieval unit: the complete entry of one symbol, or one whole example script, stored under a deterministic identifier api:docplex.cp.model: docplex.cp.model.CpoModel.solve (â 535 tokens) example:flow_shop_permutation The architecture follows one principle: the agent loads only the documentation it needs, when it needs it. Context windows vary widely across providers, from a few thousand tokens in some locally served models to about one million in the largest commercial ones, and a tool-calling loop re-sends the whole context at every turn. Loading the whole corpus (77k tokens), or even a plain symbol index (9k), would penalise smaller models and inflate every call, although a typical formulation uses about twenty of the 333 documented symbols. Retrieval thus works in two stages: discovery maps modelling concepts to candidate names across all modules, so the agent never guesses where a symbol lives, and precision returns complete entries for the selected symbols. Both stages are built automatically from the documentation, without embeddings or an expert-curated taxonomy, so the same design can be applied to another solverâs API by parsing its reference documentation. Retrieval is also deterministic: identical queries always return identical results, so differences between runs reflect the LLM rather than the retriever. The resulting server comprises of Python in three modules and is built on the FastMCP interface of the official MCP Python SDK (version 1.27.0) (Model Context Protocol, 2026). It runs locally and is exposed to Langflow through the Server-Sent Events (SSE) transport. The corpus is parsed into memory at the first tool call and cached, and the only state kept is a set of call counters used for logging and steering. Figure 3: Layered architecture of the documentation MCP server. Token counts are estimated at four characters per token. Every tool response ends with a footer stating the next required step of the retrieval protocol. The server is organised in four layers (Figure 3). âą The source layer (L0) comprises the four Markdown files of the docplex.cp reference, derived from IBMâs official documentation, and 23 solved example models, all read in place from the repository. âą The chunking layer (L1) applies one structural parser per source type. Reference files are split at symbol headers, so that each of the 333 API chunks keeps a class, function or method together with its signature, parameters, return value and usage example; methods are qualified with their class (e.g. CpoModel.add), which is how the agent refers to them. Example scripts are kept whole, because their value lies in the complete model structure. âą The retrieval layer (L2) offers two complementary mechanisms: ExactIndex returns the complete entry for a qualified or short name and never approximates, so a name is either found or reported as missing, whereas keyword_search ranks chunks by weighted token matches, favouring hits on symbol names over tags, summaries and body text. âą The tool layer (L3) exposes the six tools described in Table 4. Table 4: Tools exposed by the MCP server. Discovery responses are non-authoritative and capped at 400 characters per summary line and 40 candidates per call; precision responses are authoritative and never truncated. Family Tool Input â Outputa Key features Discovery capped search_docs [concepts] â candidate names Merges all queries and groups hits by module; ends with the ready-made get_signature call list_functions module â symbol index Browsing fallback when keyword search finds nothing list_examples problem text â ranked examples Ranked by similarity to the description; alphabetical without one Precision complete get_signature [names] â complete entries Order kept; unknown names form a gap list, never approximated get_example [ids] â full source Complete working models, up to â 5k tokens each get_module_reference module (+ [names]) â reference For many symbols of one module; â 28k tokens for modeler tabnote a Square brackets denote an array argument, so one call resolves several items. The server also accepts JSON arrays inside a string, Python-style lists, comma-separated lists and single names; names are split on commas and spaces, whereas queries keep their internal spaces. The six tools form two families with explicitly declared authority. Discovery tools map concepts to candidate names; their responses are capped and labeled DISCOVERY ONLY, and the agent is instructed not to write a call from them. Precision tools return complete API entries or example models and are never truncated. Three tools accept arrays, so that every concept or symbol of a formulation can be resolved in a single call. This follows from the cost structure of a tool-calling loop: the whole conversation is re-sent at every turn, so N calls cost roughly N times the base context, however short each response is. Fewer calls therefore save far more tokens than shorter responses. The way the agent is expected to combine these tools is fixed by a four-step retrieval protocol, shown in the upper part of Figure 4. Before writing any code, the Executor Agent (1) searches all the concepts of the formulation in one search_docs call, (2) confirms every symbol it intends to use in one get_signature call, (3) describes its problem to list_examples and loads the one or two structurally closest models with get_example, and (4) checks that no symbol remains unresolved before writing the script. Since compliance with system-prompt instructions may vary across LLMs, the protocol is also enforced at the server level. Accordingly, each tool response concludes with a PROTOCOL -- NEXT REQUIRED STEP section, dynamically generated from the executed call and its output. For example, after a get_signature call returns unresolved function names, the server reports them as a gap list and instructs the agent to resolve them through an additional batched retrieval call. Figure 4: Retrieval protocol of the Executor Agent. Top: the four steps, the tools used at each step and the in-server enforcement. Bottom: example of the tool-call trace; calls 3â4 form a repair cycle triggered by the gap list returned in call 2. The lower part of Figure 4 illustrates the protocol in practice through a specific example executed under workflow (a), showing the sequence of calls issued by the Executor Agent. The agent first translated the mathematical formulation into nine CP concepts and then validated 15 API symbols in a single batched call. Three did not resolve: two because the agent had assigned them to the wrong module, and one because docplex.cp.solution is not part of the corpus. The gap list induced a short repair cycle (calls 3â4) that corrected the module errors and made the remaining gaps explicit instead of leaving them as silent guesses. Finally, the agent ranked the examples with a plain-language description of its problem and loaded the two models that together cover the flow-shop structure and the sequence-dependent setups. Finally, the script was written after six calls. 4 Experimental evaluation 4.1 Design of Experiments One of the primary aims of this work is to assess the capability of current LLMs and the previously defined agentic approaches to autonomously generate CP models for real-world industrial scheduling problems. To evaluate and challenge the proposed agentic workflows together with the MCP toolkit, the experimental setup considers the following factors and parameter variations: Table 5: Full-factorial experimental design and run nomenclature. Factor Levels Codesa n Workflow (a) multi-agent + MCP; (b) single agent + MCP; (c) direct LLM (Figure 1) WA, WB, WC 3 LLMb Gemini 2.5 Pro; GPT-5; DeepSeek V4 Pro Gem, GPT, DS 3 Problem PC1âPC6 (Table 6) PC1, âŠ, PC6 6 Replicate Independent generations r1, r2, r3 3 Runs (3Ă3Ă6Ă33Ă 3Ă 6Ă 3) 162 tabnote a Each run is identified as workflow_LLM_problem_replicate; An asterisk aggregates over a field: WB_*_PC3_* denotes all single-agent runs on PC3. b All three LLMs are accessed through the OpenRouter API (google/gemini-2.5-pro, openai/gpt-5, deepseek/deepseek-v4-pro). The LLMs were selected to cover the model families that recur in the literature reviewed in Section 2.1, including both proprietary and open-weight models. GPT, Gemini and DeepSeek models are the usual reference points in evaluations of mathematical reasoning and optimisation modelling (Wang et al., 2025), and earlier versions such as GPT-4o and DeepSeek-V3 serve as baselines for CP model generation (Shi et al., 2025). The design therefore includes their current-generation successors: two proprietary frontier models, Gemini 2.5 Pro and GPT-5, and DeepSeek V4 Pro (open-weight). All three are general-purpose models that support native tool calling and are used without fine-tuning, which is consistent with the training-free and solver-agnostic scope of the framework. The six problems (Table 6) span the main structures of production and intralogistics scheduling with increasing modelling difficulty. PC1âPC3 cover the three classical shop configurations, each extended with features that are common in practice but absent from textbook instances. PC1 represents a beverage bottling line as a five-stage flow shop with release dates, sequence-dependent cleaning changeovers on the filling machine and a no-wait coupling between filling and capping. PC2 represents a precision machining workshop as a job shop with individual routings, release dates and due dates, and is the only problem that minimises total weighted tardiness instead of the makespan. PC3 is a flexible job shop in an injection moulding plant: each operation can only run on the presses that hold its mould, processing times depend on the machine, and a shared pool of three operators acts as a cumulative resource across all machines. These three instances are synthetic, generated with fixed seeds and sized so that CP Optimizer proves optimality within the 60 s limit. PC4âPC6 reproduce, with their synthetic data, three increasingly detailed CP models of an automated order-picking cell developed in previous work: a basic configuration with one AGV and one picking station (PC4), a variant with limited pallet stock in which the model also decides the integer quantity of each kit type taken from each pallet (PC5), and an extended cell with two AGVs, a capacitated buffer and two picking robots (PC6). Across the benchmark, the reference model grows from a few dozen variables and constraints in PC1âPC3 to more than 3 000 of each in PC6, and its variables evolve from mandatory intervals only to optional intervals combined with integer and binary assignment decisions. Each problem comes with a reference model written by the authors in docplex.cp and solved with CP Optimizer under the same 60 s limit imposed on the generated scripts. The reference objectives of PC1âPC4 are proven optimal. Those of PC5 and PC6 are best-known values that did not improve in longer runs of 250â300 s. The schedules returned by the reference models were also checked against every constraint of their problem independently of the solver, including machine overlaps, no-wait couplings, demand satisfaction and buffer capacity. Table 6: Benchmark problems: structure, size of the reference CP model and ground-truth result. PC1 PC2 PC3 PC4 PC5 PC6 Problem Typea FSP JSP FJSP RCS RCS RCS Sets Jobs / orders 11 lots 10 orders 6 batches 29 orders 29 orders 20 orders Activities 55 operations 44 operations 18 operations 139 transports 348 transportsb 360 transportsb Resources 5 machines 6 work centres 8 machines, 3 operators 1 AGV, 1 station 1 AGV, 1 station 2 AGVs, 2 robots, buffer of 5 Other 4 product families â 38 eligible pairs 5 pallets, 5 kit types 12 pallets, 5 kit types 18 pallets, 5 kit types Variables Interval 55 44 18 168 29 20 Optional interval â â 38 â 348 1 480 Sequence 1 â â â â â Integer â 10 â â 1 338 1 502 Binary â â â â 348 380 Total 56 54 56 168 2 063 3 382 Constraintsc Families 5 4 4 3 9 17 Total 60 60 39 141 2 281 3 920 Structure R, P, NW, NO, SD R, P, NO, L P, AL, NO, CU P, NO P, NO, PR, L P, NO, NW, AL, CU, PR, L Objective minâĄCmax C_ minâjwjTj _jw_jT_j minâĄCmax C_ minâĄCmax C_ minâĄCmax C_ minâĄCmax C_ Reference Value 1155 min 5120 315 min 41 955 s 13 815 s 7 435 s Status Optimal Optimal Optimal Optimal Feasible Feasible Gap (%) 0.00 0.00 0.00 0.01 2.17 84.13 tabnote a FSP: flow shop; JSP: job shop; FJSP: flexible job shop; RCS: resource-constrained scheduling of AGV transports and order picking. b Candidate (pallet, order) transports, modelled as optional intervals that exist only if the pallet is assigned to the order. c Counted on the reference models, excluding the objective. R: release dates; P: precedence; NW: no-wait or synchronisation; NO: no-overlap; SD: sequence-dependent setups; AL: alternative resources; CU: cumulative resource; PR: presence (assignment) links; L: linear (demand, capacity, tardiness). Three replicates are run for each combination because LLM output is stochastic: even at the low temperature used here, two generations from the same prompt can differ in their formulation, their tool calls and the resulting script. Each replicate is therefore a fresh generation rather than a repeated execution of the same script. All runs are evaluated following the same procedure and on the first attempt. The generated script is executed only once, exactly as produced, against the SQLite database associated with the corresponding problem and subject to the 60 s time limit used for the reference models; no run is re-prompted, repaired, or re-solved. Both choices are deliberate. The 60 s budget is the same as that used to establish the reference results: CP Optimizer proves the optimum for PC1âPC4 within this limit, with solution times ranging from 0.1 to 20 s, and the best-known values for PC5 and PC6 did not improve when their reference models were re-run with a longer time budget. Therefore, a 60-second limit facilitates the execution and comparison of the generated models. In this way, the comparison remains focused on the model rather than on the solver. The single-attempt evaluation, in turn, makes it possible to isolate the capability under study. Iterative repair loops guided by execution feedback can be an effective complement (Szeider, 2025); Evaluating only the first attempt makes it possible to assess what each configuration can produce independently, under a fixed and comparable cost, while iterative refinement and reformulation capabilities remain outside the scope of this study. The metrics derived from this comparison, together with token consumption, number of tool calls, and generation time recorded for each run, are defined in Section 4.2. 4.2 Evaluation metrics Each run is evaluated along the three dimensions of Table 7. Effectiveness is measured at two levels against the reference objective zrefz_ref. The formulation + coding accuracy, AccF+CAcc_F+C, evaluates the script exactly as generated: it is executed once, without modification, with the database of its problem and the 60 s time limit of the reference models, and counts as correct only if it completes without errors and reports z=zrefz=z_ref. A script that prints zrefz_ref and then fails, for instance while printing the schedule, is therefore incorrect. The formulation accuracy, AccFAcc_F, isolates the model from its implementation. Every run that misses zrefz_ref and has assessable code is reviewed against the reference model, and only its implementation errors are corrected: misuse of the docplex.cp API, including the semantics of optional interval variables, Python and syntax errors, data access and output format. Sets, parameters, variables, constraints and objective are never modified, and the corrected script is re-run under the same conditions. Both accuracies are the mean of the per-run outcome (100% if correct, 0 otherwise) over the three replicates of a setup, or over all the runs of a group for aggregated values. Table 7: Evaluation metrics reported for each run. Dimension Metric Definition Effectiveness AccF+CAcc_F+C (%) Percentage of replications of the same experimental setting for which the generated script executes successfully without modification and returns an objective value satisfying z=zrefz=z_ref AccFAcc_F (%) Percentage of replications of the same experimental setting that reach zrefz_ref after implementation errors are corrected, without modifying the underlying mathematical formulation Efficiency Tokens Input and output tokens of all LLM calls of the run Time (s) Wall-clock time of the complete workflow Tool calls Number of calls to the MCP documentation server (workflows (a) and (b)) Diagnostics Model outcome Result of the generated model, as generated and after correction: reaches zrefz_ref; feasible but worse than zrefz_ref; invalid (objective below a proven bound); no solution within 60 s or proven infeasible; no objective reported; execution error; no complete script First failure point Stage of the script at which an incorrect run first fails: output format or syntax, import, model building, data loading or Python runtime, result reporting, or solve without a valid solution Implementation errors Number of distinct coding errors in the script, each classified by nature as a hallucinated symbol (a name that does not exist in docplex.cp), the misuse of an existing API element, a silent semantic error (the script runs but encodes different semantics) or a format or environment defect tabnote The per-run diagnoses, with the individual errors of each script, are given in the complementary tables. Efficiency is measured by (i) the input and output tokens of all LLM calls of a run, (i) by the inference time, that is, the wall-clock time of the complete workflow from the reception of the prompt to the final answer and, (i) by the number of calls to the MCP documentation server. All three are taken from the execution records of Langflow and summarised by their mean and sample standard deviation; five runs of workflow (a) with incomplete token records are excluded from the token statistics. Finally, every run that is incorrect as generated is diagnosed by the class of its formulation error and by the number and type of its distinct coding errors (Table 7). 4.3 Results and Discussion All experiments were run on a laptop (MSI Alpha 17 C7VG) with an AMD Ryzen 9 7945HX processor (16 cores, 32 threads) and 32 GB of DDR5 memory, running Windows 11 (64-bit). The LLMs were queried remotely through the OpenRouter API, so inference times include network latency and provider-side processing. The workflows were orchestrated in Langflow Desktop 1.11.6. The MCP documentation server (MCP Python SDK 1.27.1), the generated scripts and the reference models ran locally with Python 3.14.4, docplex 2.32.264 and IBM ILOG CP Optimizer 20.1.0. 4.3.1 Overall results Table 8 summarises the results of the 54 experimental setups (3 replications per experimental setup). Its most general finding concerns the formulation. Once implementation errors are corrected, the three LLMs formulate the three classical shop problems and the basic AGV problem correctly in practically every run, whatever the workflow: on PC1âPC4, the 91,7% of the setups are correct in all three replicates. Features that are absent from textbook instances, such as sequence-dependent changeovers, no-wait couplings, machine eligibility and a cumulative pool of operators, are thus translated into correct CP formulations with high reliability. The formulation becomes the limiting factor only in the two extended warehouse problems, PC5 and PC6, whose reference models couple optional transport intervals with integer allocation decisions and more than 2 000 constraints: there, the formulation accuracy falls below one half in PC5 and to a few isolated runs in PC6. Table 8: Summary of results per experimental setup (workflow, problem and LLM): accuracy at both levels, token consumption, inference time and MCP tool calls. Accuracy (%) Tokens (k) Time Tool Workflow Problem LLM F F+C Input Output (s) calls WA PC1 (FSP) Gem 100.0 100.0 152.1 ± 3.1 21.8 ± 1.5 202 ± 16 6.0 ± 0.0 GPT 100.0 66.7 414.2 ± 173.7 24.4 ± 6.2 333 ± 84 10.3 ± 3.1 DS 100.0 66.7 1108.6 ± 179.7 19.6 ± 3.2 516 ± 135 21.7 ± 2.5 PC2 (JSP) Gem 100.0 100.0 140.3 ± 25.0 20.1 ± 5.0 178 ± 42 6.3 ± 1.2 GPT 100.0 100.0 606.7 ± 121.8 26.6 ± 4.0 372 ± 72 13.7 ± 2.3 DS 100.0 100.0 1533.2 ± 706.3 17.9 ± 2.5 442 ± 42 24.3 ± 5.5 PC3 (FJSP) Gem 100.0 66.7 149.3 ± 2.6 19.4 ± 3.7 206 ± 117 4.3 ± 3.8 GPT 100.0 66.7 536.6 ± 147.4 31.9 ± 4.4 382 ± 109 13.0 ± 2.0 DS 100.0 66.7 1239.6 ± 646.4 17.2 ± 3.1 404 ± 78 21.0 ± 7.2 PC4 (RCS) Gem 100.0 100.0 218.5 ± 54.4 22.9 ± 5.7 242 ± 42 9.0 ± 1.7 GPT 100.0 66.7 471.8 ± 15.5 22.7 ± 1.7 319 ± 159 12.0 ± 1.0 DS 100.0 66.7 1416.7 ± 149.6 17.4 ± 1.3 435 ± 73 26.3 ± 2.3 PC5 (RCS) Gem 33.3 33.3 147.8 ± 1.6 22.5 ± 0.4 257 ± 97 5.3 ± 1.2 GPT 100.0 66.7 432.6 ± 52.4 28.8 ± 1.1 349 ± 120 11.0 ± 1.0 DS 33.3 0.0 1158.3 ± 272.2 30.7 ± 8.2 442 ± 96 21.3 ± 3.2 PC6 (RCS) Gem 33.3 0.0 113.8 ± 1.0 31.0 ± 12.3 320 ± 97 3.7 ± 3.2 GPT 0.0 0.0 587.0 ± 273.3 48.3 ± 12.5 572 ± 186 13.0 ± 4.6 DS 0.0 0.0 1240.4 ± 524.5 34.1 ± 4.4 679 ± 90 20.3 ± 5.7 WB PC1 (FSP) Gem 66.7 0.0 99.4 ± 27.3 9.2 ± 2.9 149 ± 75 5.7 ± 0.6 GPT 100.0 33.3 406.6 ± 114.0 22.6 ± 0.6 322 ± 34 11.3 ± 1.5 DS 100.0 66.7 724.8 ± 121.4 9.7 ± 1.8 233 ± 26 17.0 ± 1.7 PC2 (JSP) Gem 100.0 66.7 109.9 ± 26.6 15.6 ± 2.6 179 ± 73 6.3 ± 1.2 GPT 100.0 66.7 313.3 ± 71.5 16.9 ± 2.6 236 ± 27 10.0 ± 1.7 DS 100.0 66.7 760.8 ± 239.6 7.7 ± 0.7 203 ± 22 17.7 ± 3.8 PC3 (FJSP) Gem 100.0 66.7 95.1 ± 20.2 11.9 ± 1.7 124 ± 18 5.7 ± 0.6 GPT 100.0 33.3 363.6 ± 137.5 19.0 ± 2.0 271 ± 25 11.0 ± 2.6 DS 100.0 33.3 900.8 ± 79.8 10.4 ± 2.0 240 ± 26 19.3 ± 1.5 PC4 (RCS) Gem 100.0 33.3 89.3 ± 11.2 11.7 ± 2.3 192 ± 48 5.0 ± 1.0 GPT 100.0 66.7 335.7 ± 40.2 15.6 ± 1.2 217 ± 37 10.7 ± 1.2 DS 100.0 33.3 667.0 ± 155.9 8.9 ± 2.0 225 ± 20 17.3 ± 2.1 PC5 (RCS) Gem 33.3 0.0 136.4 ± 21.5 16.4 ± 3.2 169 ± 28 6.3 ± 0.6 GPT 33.3 0.0 332.4 ± 43.7 25.5 ± 5.0 327 ± 105 10.3 ± 0.6 DS 100.0 33.3 1019.7 ± 300.0 14.8 ± 1.5 331 ± 26 20.0 ± 3.0 PC6 (RCS) Gem 33.3 0.0 73.9 ± 49.7 18.0 ± 4.1 228 ± 75 3.3 ± 2.1 GPT 33.3 0.0 382.6 ± 64.5 36.6 ± 7.6 498 ± 116 11.0 ± 2.0 DS 0.0 0.0 745.9 ± 315.5 26.8 ± 9.2 501 ± 149 16.3 ± 5.0 WC PC1 (FSP) Gem 100.0 33.3 2.4 ± 0.0 9.9 ± 1.2 82 ± 13 â GPT 100.0 0.0 2.2 ± 0.0 9.4 ± 0.2 135 ± 21 â DS 100.0 0.0 2.3 ± 0.0 7.6 ± 2.6 129 ± 30 â PC2 (JSP) Gem 100.0 0.0 1.9 ± 0.0 9.0 ± 3.2 75 ± 27 â GPT 100.0 0.0 1.8 ± 0.0 7.2 ± 0.9 91 ± 16 â DS 100.0 0.0 1.8 ± 0.0 6.9 ± 6.9 142 ± 160 â PC3 (FJSP) Gem 100.0 33.3 2.0 ± 0.0 9.0 ± 2.3 76 ± 17 â GPT 100.0 0.0 1.9 ± 0.0 7.2 ± 0.3 99 ± 20 â DS 66.7 33.3 2.0 ± 0.0 7.9 ± 6.6 195 ± 191 â PC4 (RCS) Gem 100.0 33.3 1.9 ± 0.0 9.4 ± 2.7 110 ± 78 â GPT 100.0 66.7 1.8 ± 0.0 7.1 ± 0.7 107 ± 25 â DS 66.7 33.3 1.9 ± 0.0 6.6 ± 7.3 167 ± 219 â PC5 (RCS) Gem 66.7 33.3 2.4 ± 0.0 13.7 ± 1.3 116 ± 9 â GPT 0.0 0.0 2.2 ± 0.0 11.2 ± 0.2 163 ± 19 â DS 0.0 0.0 2.3 ± 0.0 11.0 ± 3.2 241 ± 224 â PC6 (RCS) Gem 0.0 0.0 2.9 ± 0.0 15.0 ± 0.0 161 ± 65 â GPT 0.0 0.0 2.7 ± 0.0 13.3 ± 1.1 191 ± 15 â DS 33.3 0.0 2.8 ± 0.0 11.1 ± 6.6 272 ± 197 â tabnote Accuracy: percentage of the three replicates of each setup that are correct (100% for a correct replicate, 0 otherwise); F: formulation accuracy; F+C: formulation + coding accuracy (script as generated). Bold: best LLM for each workflow and problem. Tokens (in thousands), inference time of the complete workflow and MCP tool calls: mean ± sample standard deviation over the three replicates. WA: multi-agent + MCP; WB: single agent + MCP; WC: direct LLM (no tool calls). The formulation plus coding accuracy stays below the formulation accuracy in almost every workflow and problem, so the first barrier to a correct result is the implementation of the model rather than the model itself: even on PC1âPC4, about half of the correct formulations are lost in the generated code. The two levels also differ in reproducibility. A correct formulation is usually obtained in all three replicates of a setup, whereas a correct script is not: 84.8% setups with at least one correct script produce it in only one or two replicates, so a single generation is a weak indicator of the capability of a configuration. The only setups in which the three generated scripts are correct belong to the multi-agent workflow, which reaches up to 67.7% of formulation + coding accuracy in PC1-PC4 tests, outperforming the rest of architectures mainly in the coding task. The LLM has a smaller and less systematic effect on accuracy: the best model changes from one workflow and problem to another, and each of the three LLMs is the most accurate in some setups. Its effect on cost is, in contrast, systematic. Token consumption differs by more than an order of magnitude between the direct LLM and the agentic workflows and, within each agentic workflow, depends mainly on the LLM, whose tool-calling behaviour determines how often the context is re-sent, and only marginally on the problem. Section 4.3.2 analyses these effects in detail. 4.3.2 Workflow and LLM analysis Figure 5 compares the three workflows at both accuracy levels, aggregating the three LLMs. The agentic configurations improve mainly the implementation, specifically the multi-agent approach. The formulation + coding accuracy rises from 14.8% with the direct LLM to 33.3% with the single agent and 59.3% with the multi-agent workflow, and the share of runs lost only to implementation errors, AccFâAccF+CAcc_F-Acc_F+C, falls from 53.7 to 44.4 and 18.5 percentage points, respectively. The gain holds for every LLM, each of which reaches its highest formulation + coding accuracy in workflow (a) (Figure 6). The formulation accuracy, in contrast, hardly depends on the configuration (Figure 5b): it is 77.8% in both agentic workflows and 68.5% with the direct LLM. Figure 5: Accuracy per problem and workflow across the three LLMs: (a) formulation + coding accuracy, AccF+CAcc_F+C; (b) formulation accuracy, AccFAcc_F. Mean ± standard deviation over the nine runs of each workflow and problem (three LLMs Ă three replicates). Figures 6 and 7 break both accuracies down by LLM. At the formulation + coding level the ranking of the LLMs changes with the workflow: Gemini 2.5 Pro is the most accurate model in workflows (a) and (c), with 66.7% and 22.2%, and DeepSeek V4 Pro in workflow (b), with 38.9%. These differences, at most 16.7 points within a workflow, are much smaller than those between workflows. At the formulation level the LLMs are closer still, between 72.2 and 83.3% in the agentic workflows and between 61.1 and 77.8% with the direct LLM. On PC1âPC4, every LLM reaches zrefz_ref after implementation correction in every run with assessable code, so the differences come from PC5 and PC6: GPT-5 formulates PC5 correctly in the three replicates of workflow (a), and DeepSeek V4 Pro in those of workflow (b), whereas PC6 reaches zrefz_ref in only 4 of its 27 runs. The two levels do not rank the LLMs in the same way either. In workflow (a), GPT-5 has the highest formulation accuracy, 83.3%, but produces fewer correct scripts than Gemini 2.5 Pro, 61.1 against 66.7%, which indicates that the reliability of the implementation is a property of the LLM distinct from its modelling capability. Figure 6: Formulation + coding accuracy, AccF+CAcc_F+C, per problem, LLM and workflow: mean ± standard deviation over three replicates. Figure 7: Formulation accuracy, AccFAcc_F, per problem, LLM and workflow: mean ± standard deviation over three replicates. Figure 8: Inference time (bars, left axis) and tokens per run (diamonds, right axis, logarithmic scale) per LLM and workflow: mean ± standard deviation over the 18 runs of each workflowâLLM pair. Figure 8 and Table 8 show the cost of these results. The agentic workflows are considerably more expensive than the direct LLM: workflow (a) requires on average 370 s and 0.73 million tokens per run and workflow (b) 258 s and 0.44 million tokens, against 142 s and about 12 000 tokens, mostly output tokens, for workflow (c). Workflow (a) thus needs 43% more time and 66% more tokens than workflow (b), in exchange for 26 more points of formulation + coding accuracy. In both agentic workflows, 96% of the tokens are input tokens, and their number grows almost linearly with the number of tool calls, because the whole conversation, including the retrieved documentation, is re-sent at every turn of the tool-calling loop. The Formulator Agent accounts for only 1.7% of the tokens of workflow (a), but for 30% of its time, since it writes a long formulation in a single call. Within each workflow, the cost depends on the LLM far more than on the problem. DeepSeek V4 Pro consumes about seven times more tokens than Gemini 2.5 Pro in both agentic workflows (1.31 against 0.18 million tokens per run in workflow (a) and 0.82 against 0.11 million in workflow (b)), since it makes about four times more tool calls in (a) and three times more in (b), with GPT-5 in between, whereas the problem changes the consumption of a given workflowâLLM pair by less than a factor of 1.8. The inference time also depends on the LLM, but not in proportion to the tokens: GPT-5, which writes the longest outputs, is the slowest model in workflow (b), although it uses less than half the tokens of DeepSeek V4 Pro. In workflow (a), Gemini 2.5 Pro is both the cheapest and the most accurate model. 4.3.3 Generated Models and Error Analysis Table 9 classifies the outcome of the 162 generated models before and after the correction of their implementation errors. As generated, 58 scripts return the reference objective, 81 fail with an execution error, 14 of them after having printed zrefz_ref, six answers contain no complete script, and only 17 run to completion with a wrong or missing result: 14 find no solution within 60 s or prove their model infeasible, one reports an objective below the provable bound of PC5, two report no objective and two answers contain no code. No script delivers a feasible schedule worse than the reference: when a generated model runs, it either reproduces zrefz_ref or fails to solve. After the minimal correction of implementation errors, 121 models reach zrefz_ref, seven return feasible but worse schedules, between 2 and 8% above zrefz_ref in PC5 and twice zrefz_ref in a single PC6 run, and 27 still find no solution within 60 s. The difference between the two blocks of the table is the implementation. On PC1âPC4 it closes almost completely, from 53 to 105 correct models out of 108, whereas on PC5 and PC6 it only moves from 5 to 16 of 54, because the remaining models are over-constrained or structurally wrong. The workflow determines where a run is lost: the direct LLM loses 38 of its 54 scripts to execution errors and the single agent 29, against 14 for the multi-agent workflow, the only one in which solver-level outcomes are as frequent as crashes. Table 9: Outcome of the 162 generated models, as generated and after correcting their implementation errors, aggregated per workflow and per problem. Workflow Problem Outcome of the generated model (a) (b) (c) PC1âPC4 PC5 PC6 All Runs 54 54 54 108 27 27 162 Script as generated (single execution, no edits) Reaches zrefz_ref (correct model) 32 18 8 53 5 â 58 Invalid: objective below a proven bound â â 1 â 1 â 1 No solution within 60 s or proven infeasible 7 5 2 â 4 10 14 Completes without reporting an objective 1 1 â 1 1 â 2 Script fails with an error 14 29 38 51 16 14 81 of which after printing zrefz_ref 2 3 9 12 2 â 14 No complete script (not assessable) â 1 5 3 â 3 6 AccF+CAcc_F+C (%) 59.3 33.3 14.8 49.1 18.5 0.0 35.8 After correcting implementation errors only (formulation unchanged) Reaches zrefz_ref (correct model) 42 42 37 105 12 4 121 Feasible schedule, worse than zrefz_ref 3 3 1 â 6 1 7 Invalid: objective below a proven bound â â 1 â 1 â 1 No solution within 60 s or proven infeasible 9 8 10 â 8 19 27 No complete script (not assessable) â 1 5 3 â 3 6 AccFAcc_F (%) 77.8 77.8 68.5 97.2 44.4 14.8 74.7 tabnote Counts of runs. As generated, a run reaches zrefz_ref only if the script completes without error and reports z=zrefz=z_ref (strict criterion); (a) multi-agent + MCP; (b) single agent + MCP; (c) direct LLM. AccF+CAcc_F+C and AccFAcc_F: share of runs reaching zrefz_ref at each level (Table 7). Figure 9: Error analysis of the generated scripts. (a) Outcome of the 54 scripts of each workflow: correct as generated, or first point at which the script fails; result reporting includes the 14 scripts that fail after printing zrefz_ref, and the last class groups the scripts that run to completion without a valid solution. (b) The twelve most frequent implementation errors among the 159 distinct errors of the 104 incorrect runs, grouped by nature: hallucinated symbol (a name that does not exist in docplex.cp), misuse of an existing element of the API, silent semantic error, and format, environment or generic Python defects. Figure 9 details why the 104 incorrect runs fail (those that did not reach zrefz_ref at first). Panel (a) locates, for each of the 54 scripts of a workflow, the first point at which it fails, ordered as the stages of the pipeline. The three workflows fail at different depths. In the agentic workflows, the most frequent first failure is the import stage, before any model exists (8 runs in workflow (a) and 14 in workflow (b), against 3 with the direct LLM), followed by the model-building calls (4 and 6 runs). With the direct LLM the failures move downstream: 15 scripts fail while building the model and 13 while reporting a model that had already been solved, 9 of them after printing zrefz_ref (Table 9), and 8 answers are not even valid Python because prose, several drafts or corrupted text surround the code, a class that is practically absent from the agentic workflows. Only the last class of the panel does not correspond to an interpreter error: 15 scripts (7, 5 and 3) reach the solver and end without a valid solution, and these are the runs in which the formulation, not the code, is at fault. Two consequences follow for the modelling work that a practitioner would face after a generation. First, the failures are overwhelmingly loud: 89 of the 104 incorrect scripts stop with an explicit error message or an unusable output, whereas the silent failures that produce a wrong schedule without any warning are confined to the last class. Second, they are recoverable: once the implementation errors are corrected with the minimal literal patch, 63 of the 104 scripts return zrefz_ref (121 correct models against 58 in Table 9), and the remaining ones do not fail any more but expose a formulation problem, as the increase of the no-solution and worse-schedule outcomes in the second block of the table shows. Panel (b) classifies the 159 distinct implementation errors found in the 94 runs with coding errors by their nature, and separates two mechanisms that are often conflated under the term hallucination. Only 43 errors, roughly one in four, are hallucinations in the strict sense, that is, calls to symbols that do not exist in docplex.cp: 30 of them are invented accessors of the solve result and 13 are invented model methods, constructors or names. The largest group, 78 errors, is instead the misuse of an element that does exist: the variable constructors imported from docplex.cp.modeler instead of docplex.cp.model (29), the time limit assigned to model.parameters, an attribute that is not initialised on a new model (13), a solution object used as if it were its value (6), Pythonâs max() and if applied to CP expressions (6), or callable bounds passed to the variable-dictionary constructors (4). The two mechanisms also leave different traces in panel (a): the import idiom stops the script before the model is built, which is the dominant first failure of the agentic workflows, whereas an invented accessor is only reached after a successful solve, which is why the reporting stage concentrates the failures of the direct LLM. The remaining errors are 29 format and environment defects, of which prose around the code (7), an assumed database path (7), output truncated before the end of the script (6) and corrupted identifiers (4) are the most frequent, and 9 silent errors, 7 of them of the same kind: equating the start or end of an optional interval to another time, which evaluates to zero when the interval is absent and turns a correct PC6 model into an infeasible one without any error message. The 27 further errors grouped as other individual errors are of more than twenty different kinds, none occurring more than three times, so the corpus of implementation errors is highly concentrated: five recurrent mistakes explain more than half of it, which is precisely the situation in which a documentation server can be effective. 5 Conclusions Most high-accuracy approaches to LLM-assisted mathematical modelling rely on specialisation, such as dedicated fine-tuning, expert-curated knowledge, a single paradigm or solver, or problem-specific architectures, and are validated mainly on academic benchmarks. Meanwhile, agentic AI in manufacturing has largely operated around pre-existing optimisation models rather than building them. This work has explored a different role for agentic AI, namely the generation of the model: whether general-purpose LLMs, used without any training and orchestrated as agents, can formulate and implement CP models for industrial scheduling problems from nothing more than a natural-language description and the schema of the instance database. CP was chosen deliberately, since it is a paradigm of proven industrial strength in which LLM-assisted modelling remains far less explored than in MILP. To this end, two agentic workflows were proposed, a multi-agent pipeline that separates formulation from coding and a single agent that performs both tasks, and compared with a direct LLM baseline. The formulation was entrusted entirely to the reasoning capability of the LLMs, without any formulation hint, whereas the implementation, where hallucinated and misused API calls had been observed most often, was supported by an MCP server that gives the agents on-demand access to the docplex.cp documentation through discovery and precision tools and a retrieval protocol enforced within the server. Because the corpus, its chunking and its retrieval are built automatically from the reference documentation, without embeddings or an expert-curated taxonomy, and because each stage of the workflow is an independent module, the design can be transferred to other solvers and optimisation paradigms by parsing their documentation, and its catalogue of solved examples can be extended with models previously developed and validated by the user. The evaluation on six industry-oriented problems, three LLMs and 162 single-attempt generations shows, first, that formulation is largely within reach of current LLMs. On the flow shop with sequence-dependent changeovers and no-wait coupling, the weighted-tardiness job shop, the flexible job shop with machine eligibility and a cumulative operator pool, and the basic AGV transport and picking problem (PC1âPC4), 97.2% of the generated models were correctly formulated. Moreover, all three LLMs formulated every assessable run correctly, so the choice among the models evaluated makes little difference at this level. The limit lies in the two extended intralogistics problems, where optional transport intervals coexist with integer allocation quantities, binary assignments, presence links and more than 2 000 constraints: formulation accuracy falls to 44.4% in PC5 and 14.8% in PC6, and the remaining models are over-constrained or structurally wrong. Formulation accuracy also barely depends on the workflow (77.8% in both agentic workflows against 68.5% for the direct LLM), which confirms that it is governed by the reasoning capability of the LLM. The agentic approach makes its difference in the implementation. The share of scripts that run correctly exactly as generated rises from 14.8% with the direct LLM to 33.3% with the single agent and 59.3% with the multi-agent workflow, a fourfold improvement that reaches 80.6% on PC1âPC4, while the share of runs lost only to coding errors falls from 53.7 to 18.5 percentage points. The gain holds for every LLM, and the multi-agent workflow is the only configuration in which all three replicates of a setup produced a correct script, which indicates that separating formulation from coding is beneficial in itself. This gain has a cost: the multi-agent workflow requires on average 370 s and 0.73 million tokens per run, against 142 s and about 12 000 tokens for the direct LLM, because the retrieved documentation is re-sent at every turn of the tool-calling loop. The cost is determined by the LLM far more than by the problem: DeepSeek V4 Pro consumes about seven times more tokens than Gemini 2.5 Pro, owing to its three to four times more frequent tool calls, whereas Gemini 2.5 Pro is, in the multi-agent workflow, both the cheapest model (0.18 million tokens per run) and the most accurate one (66.7%). Considering that the output is an optimisation model that would otherwise require substantial expert effort, a generation time of a few minutes and a cost of roughly US$0.3â1 per model at current list prices remain highly competitive. Finally, the error analysis shows that implementation failures are loud, concentrated and recoverable. Of the 104 incorrect scripts, 89 stop with an explicit error or an unusable output rather than a silently wrong schedule; the 159 distinct coding errors found in 94 runs amount to fewer than two per script, so that at least two thirds of these scripts contain only one or two errors, and five recurrent mistakes explain more than half of the total; and a minimal literal patch turns 63 of the 104 incorrect scripts into correct ones, raising the number of correct models from 58 to 121. Only one error in four is a hallucination in the strict sense, whereas most are misuses of existing API elements, and the most frequent single error concerns the accessors of the solve result, which lie outside the documented corpus. Taken together, the results show that general-purpose LLMs, without any task-specific training, orchestrated as agents and grounded in solver documentation, can already formulate classical and moderately extended scheduling problems reliably and turn a large share of them into executable CP models at the first attempt, at a moderate computational cost. Although tightly coupled intralogistics models remain an open challenge, the combination of this performance with a modular design that is not tied to a specific problem class, solver or training procedure suggests that agentic AI emerges as a promising and versatile route towards making mathematical optimisation accessible to industrial practitioners. 6 Limitations and future directions Despite these encouraging results, the study also reveals limitations that point to several directions for future research. First, formulation accuracy drops sharply when assignment logic, heterogeneous variable types and thousands of constraints coexist, as in the extended intralogistics problems PC5 and PC6 (44.4% and 14.8%). For problems of this complexity, expert knowledge and specialised LLM-based approaches therefore remain necessary, and their combination with agentic workflows is a natural next step, for instance through expert review of the explicit formulation that the multi-agent pipeline produces before any code is written. Second, although the agentic configurations substantially improve the implementation, even the multi-agent workflow still produces faulty code in a considerable share of runs. Since most of these failures are explicit and are resolved by minimal corrections, iterative repair loops driven by execution feedback, deliberately excluded from this single-attempt evaluation, are expected to add considerable value. Finally, a practitioner has no reference objective against which to judge a generated model, so reliable mechanisms for validating its output, such as solver-independent constraint checkers and consistency tests on the resulting schedules, will be essential for the safe industrial deployment of these approaches. Disclosure statement No potential conflict of interest was reported by the author(s). Funding The authors received no specific funding for this project. Data availability statement The problem statements, instance databases, system prompts and generated scripts that support the findings of this study are openly available in the project repository at https://github.com/angelsnfn/AgenticPScheduling (SĂĄnchez-FernĂĄndez et al., 2026). Declaration of generative AI use During the preparation of this work the authors used Claude (Anthropic) to assist with language editing of the manuscript, with the generation of LaTeX tables and figures. The large language models evaluated in the study (Gemini 2.5 Pro, GPT-5 and DeepSeek V4 Pro) are the object of the experiments and are described in Section 4. The authors reviewed and edited all content and take full responsibility for the final manuscript. References Benoist et al. (2011) T. Benoist, B. Estellon, F. Gardi, R. Megel, and K. Nouioua LocalSolver 1.x: a black-box local-search solver for 0-1 programming. 4OR 9 (3), p. 299â316. External Links: Document Cited by: §2.2. Chen et al. (2026a) C. Chen, L. Li, T. Wang, Z. Wang, J. Leng, H. Shao, and L. Cheng Leveraging large language models for smart manufacturing: reviews, enablers, challenges, and opportunities. Journal of Manufacturing Systems 85, p. 593â612. External Links: Document Cited by: §2.3. Chen et al. (2026b) Y. Chen, J. Rao, Y. Zeng, M. Zha, W. Yan, Z. Jiang, and Y. Liu Dynamic-static knowledge graph enhanced LLM reasoning for intelligent process planning in steel manufacturing. Journal of Manufacturing Systems 86, p. 203â217. External Links: Document Cited by: §1. Chen et al. (2026c) Z. Chen, M. Peng, H. Zhang, J. Huang, X. Li, and L. Gao An LLM based framework for automated MILP modeling in dynamic multi-robot task scheduling. IEEE Robotics and Automation Letters 11 (10), p. 11346â11353. External Links: Document Cited by: §2.1. Colmenar et al. (2024) J. M. Colmenar, M. Laguna, and R. MartĂn-SantamarĂa Changeover minimization in the production of metal parts for car seats. Computers & Industrial Engineering 198, p. 110634. External Links: Document Cited by: §2.2. Da Col and Teppan (2022) G. Da Col and E. C. Teppan Industrial-size job shop scheduling with constraint programming. Operations Research Perspectives 9, p. 100249. External Links: Document Cited by: §2.2. El Baz et al. (2026) H. El Baz, M. Ghali, L. Andrus, D. Won, S. W. Yoon, and Y. Wang Generative AI-based optimization for high-mix warehouses: integrating agentic LLMs and discrete event simulation. Computers & Industrial Engineering 214, p. 111884. External Links: Document Cited by: §2.1, §2.3. Ham and Cakici (2016) A. M. Ham and E. Cakici Flexible job shop scheduling problem with parallel batch processing machines: MIP and CP approaches. Computers & Industrial Engineering 102, p. 160â165. External Links: Document Cited by: §2.2. Ham (2021) A. Ham Transfer-robot task scheduling in job shop. International Journal of Production Research 59 (3), p. 813â823. External Links: Document Cited by: §2.2. Haouassi et al. (2022) M. Haouassi, Y. Kergosien, J. E. Mendoza, and L. Rousseau The integrated orderline batching, batch scheduling, and picker routing problem with multiple pickers: the benefits of splitting customer orders. Flexible Services and Manufacturing Journal 34, p. 614â645. External Links: Document Cited by: §2.2. Hexaly (2026) Hexaly Hexaly optimizer: a hybrid mathematical optimization solver. Note: https://w.hexaly.com/hexaly-optimizerAccessed 30 September 2026 Cited by: §2.2. Hu and Li (2026) Z. Hu and Y. Li Generative adaptive resilience: LLM-MILP modeling and strategy generation for port vessel scheduling. Safety Science 201, p. 107233. External Links: Document Cited by: §2.1. Ivanov (2026) D. Ivanov Agentic digital twins: bridging model-based and AI-driven decision-making support for a new era of supply chain and operations management. International Journal of Production Research. External Links: Document Cited by: §1, §1. Jannelli et al. (2025a) V. Jannelli, S. Schöpf, M. Bickel, T. Netland, and A. Brintrup Agentic LLMs in the supply chain: towards autonomous multi-agent consensus-seeking. International Journal of Production Research. External Links: Document Cited by: §1. Jannelli et al. (2025b) V. Jannelli, S. Schöpf, M. Bickel, T. Netland, and A. Brintrup Agentic LLMs in the supply chain: towards autonomous multi-agent consensus-seeking. International Journal of Production Research. External Links: Document Cited by: §2.3. Jiang et al. (2026) X. Jiang, H. Zhang, M. Sha, Z. Jiao, L. He, J. Zhang, and W. Qi RideAgent: an LLM-enhanced optimization framework for automated taxi fleet operations. IEEE Transactions on Automation Science and Engineering 23, p. 8533â8544. External Links: Document Cited by: §2.1. Laborie et al. (2018) P. Laborie, J. Rogerie, P. Shaw, and P. VilĂm IBM ILOG CP optimizer for scheduling: 20+ years of scheduling with constraints at IBM/ILOG. Constraints 23 (2), p. 210â250. External Links: Document Cited by: §2.2. Leng et al. (2026) J. Leng, J. Wang, L. Zhou, R. Zhao, C. Chen, D. Zhang, S. Zheng, Q. Liu, and W. Shen A review of multi-modal deep learning towards agentic smart manufacturing. Advanced Engineering Informatics 70, p. 104117. External Links: Document Cited by: §1. Li et al. (2026a) M. Li, Q. Zhou, W. Li, T. Qu, M. Yang, and P. Jiang A4PS: agentic AI-assisted advanced planning and scheduling with large language models for smart manufacturing. Journal of Manufacturing Systems 85, p. 207â226. External Links: Document Cited by: §2.3. Li et al. (2026b) Q. Li, L. Zhang, and V. Mak-Hau An LLM-powered MILP modelling engine for workforce scheduling guided by expert knowledge. International Journal of Production Research. External Links: Document Cited by: 1st item. Li et al. (2026c) Q. Li, L. Zhang, and V. Mak-Hau An LLM-powered MILP modelling engine for workforce scheduling guided by expert knowledge. International Journal of Production Research. External Links: Document Cited by: §2.1. Meng et al. (2020) L. Meng, C. Zhang, Y. Ren, B. Zhang, and C. Lv Mixed-integer linear programming and constraint programming formulations for solving distributed flexible job shop scheduling problem. Computers & Industrial Engineering 142, p. 106347. External Links: Document Cited by: §2.2. Model Context Protocol (2026) Model Context Protocol MCP Python SDK: the official Python SDK for the Model Context Protocol. Note: https://py.sdk.modelcontextprotocol.io/DocumentaciĂłn oficial, versiĂłn 2. Repositorio: https://github.com/modelcontextprotocol/python-sdk. Consultado: 2026-09-30 Cited by: §3.2. MĂŒller et al. (2022) D. MĂŒller, M. G. MĂŒller, D. Kress, and E. Pesch An algorithm selection approach for the flexible job shop scheduling problem: choosing constraint programming solvers through machine learning. European Journal of Operational Research 302 (3), p. 874â891. External Links: Document Cited by: §2.2. Naderi et al. (2023) B. Naderi, R. Ruiz, and V. Roshanaei Mixed-integer programming vs. constraint programming for shop scheduling problems: new results and outlook. INFORMS Journal on Computing 35 (4), p. 817â843. External Links: Document Cited by: §2.2. Pernas-Ălvarez et al. (2025) J. Pernas-Ălvarez, JosĂ©-A. Becerra, and D. Crespo-Pereira A constraint programming-based decomposition strategy for the block assembly scheduling problem in shipbuilding. International Journal of Production Research 63 (20), p. 7617â7636. External Links: Document Cited by: §2.2. Perron et al. (2023) L. Perron, F. Didier, and S. Gay The CP-SAT-LP solver (invited talk). In 29th International Conference on Principles and Practice of Constraint Programming (CP 2023), Leibniz International Proceedings in Informatics (LIPIcs), Vol. 280, Dagstuhl, Germany, p. 3:1â3:2. External Links: Document Cited by: §2.2. Rossi and Prestwich (2026) R. Rossi and S. D. Prestwich Grammar-aware literate generative mathematical programming with compiler-in-the-loop. Note: arXiv:2601.17670 External Links: Link Cited by: 1st item, 3rd item, §1. SĂĄnchez-FernĂĄndez et al. (2026) Ă. SĂĄnchez-FernĂĄndez, J. Pernas-Ălvarez, and D. Crespo-Pereira AgenticProductionScheduling: system prompts, benchmark problems and instance data for agentic AI-assisted constraint programming modelling. Note: https://github.com/angelsnfn/AgenticProductionSchedulingGitHub repository. Accessed 30 September 2026 Cited by: Figure 2, §3.1, Data availability statement. Schmitt et al. (2026) T. Schmitt, N. Gegenmantel, M. Urenda Moris, P. MĂ„rtensson, and K. Amouzgar LLM-driven discrete-event simulation: a generative AI framework for automated model generation, adaptation, and evaluation in manufacturing. Journal of Manufacturing Systems 85, p. 642â661. External Links: Document Cited by: §1. Shi et al. (2025) W. Shi, M. Liu, W. Zhang, L. Shi, F. Jia, F. Ma, and J. Zhang ConstraintLLM: a neuro-symbolic framework for industrial-level constraint programming. In Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, Suzhou, China, p. 15999â16019. External Links: Document, Link Cited by: §2.1, §4.1. Shi et al. (2026) Y. Shi, Q. Xu, Y. Li, M. Liu, H. Qu, L. Ruan, and Q. Wang Automated constraint specification for job scheduling by regulating generative model with domain-specific representation. IEEE Transactions on Automation Science and Engineering 23, p. 3683â3698. External Links: Document Cited by: §2.1. Simchi-Levi et al. (2025) D. Simchi-Levi, T. Dai, I. Menache, and M. X. Wu Democratizing optimization with generative AI. Note: Working paper, this version: October 24, 2025 Cited by: §1. Szeider (2025) S. Szeider CP-Agent: agentic constraint programming. External Links: 2508.07468, Document Cited by: §2.3, §4.1. Telha and GonzĂĄlez-RamĂrez (2025) C. Telha and R. G. GonzĂĄlez-RamĂrez A constraint-programming approach for the storage space allocation problem in a distribution center. International Transactions in Operational Research 32, p. 3474â3496. External Links: Document Cited by: §2.2. Wang et al. (2025) R. Wang, R. Wang, Y. Shen, C. Wu, Q. Zhou, and R. Chandra Evaluation of LLMs for mathematical problem solving. Note: VersiĂłn 1, 30 de mayo de 2025 External Links: 2506.00309, Document, Link Cited by: §2.1, §4.1. Xiang et al. (2026) W. Xiang, J. Zhang, P. Zhang, and M. Wang Dynamic scheduling of wafer batch processing machines via reinforcement learning enhanced by expert-guided lightweight LLM. International Journal of Production Research 64 (7), p. 2731â2752. External Links: Document Cited by: §2.3. Ye and Li (2026) W. Ye and X. Li Coordination of LLM-embodied agents for manufacturing task allocation under constraints. Journal of Manufacturing Systems 87, p. 17â26. External Links: Document Cited by: §1, §2.3. Yuan et al. (2025) Z. Yuan, M. Li, C. Liu, F. Han, H. Huang, and H. Dai Chat with MES: LLM-driven user interface for manipulating garment manufacturing system through natural language. Journal of Manufacturing Systems 80, p. 1093â1107. External Links: Document Cited by: §2.3. Yuraszeck et al. (2026a) F. Yuraszeck, G. MejĂa, D. A. Rossit, and A. LĂŒer-Villagra A constraint programming-based decomposition procedure for shop scheduling problems. International Journal of Production Research. External Links: Document Cited by: §2.2. Yuraszeck et al. (2026b) F. Yuraszeck, F. Werner, and D. Rossit A comprehensive benchmark of constraint programming solvers for the makespan-minimisation job shop scheduling problem. Mathematics 14 (12), p. 2179. External Links: Document Cited by: §2.2. Zhang et al. (2025) X. Zhang, Z. Chen, H. Zope, H. Barbalho, K. Mellou, M. Molinaro, J. Kulkarni, I. Menache, and S. Li OptiMind: teaching LLMs to think like optimization experts. Note: Preprint; versiĂłn consultada v2, enero de 2026 External Links: 2509.22979 Cited by: 1st item, §2.1.