In Copilot's Optimization agent template, Microsoft provides a noteworthy interaction method for enterprise decision-making: business personnel provide goals, rules, and data, and the agent sorts out the requirements through dialogue, and then calls the solving tool to calculate the solution.
It connects AI’s ability to understand natural language with the computing power of operations research and optimization. Users can discuss business requirements, and the system needs to implement these requirements into clear variables, constraints, and goals before entering actual calculations.
Understanding this division of labor will help us think further: How can AI+operations research develop from solving a single problem to a decision-making capability that enterprises can use in the long term?
1. Let’s first look at a specific direction: Microsoft’s optimized agent template
For example, in a staffing scenario, users can request that projects be staffed by skills, while proposing constraints on budget, location, or team scheduling. The agent organizes these requirements into computable questions; if there is missing or ambiguous information, it further clarifies it through dialogue.
During this process, users can view how the system understands goals, decision variables, constraints and data in the sidebar, and can also request modifications to the content. The so-called decision variables are the choices that the program needs to determine, such as which project a certain employee is assigned to. After the user confirms the problem settings, the system calls the solving tool to calculate and provides results that can be viewed and exported.
This process connects the expression of business requirements with the calculation of solutions. People can first explain what results they hope to achieve, and then gradually check whether the system understands it correctly; the operations research method implements the confirmed requirements into resource allocation. As of this investigation, official documents still mark this template as an early access preview, which shows a product direction and does not yet represent the maturity of a complete enterprise decision-making center.
Around this work process, the research field is also advancing the capabilities of different links. Microsoft Research's OptiMind focuses on how to convert natural language descriptions into optimized mathematical models and executable codes. Another study, OptiChat, targets already established optimization mathematical models, helping business personnel understand their meaning, diagnose constraint conflicts, and analyze the impact of modifying conditions.
The two correspond to different problems: the former helps "write requirements into calculable problems", and the latter helps "understand and adjust problems that have been written." They are case studies looking at related technological advances and are not meant to be internal components of the Microsoft templates described above.
Looking at these efforts together, we can find a clear technical path: AI assists in understanding and expressing business requirements, operations research converts them into clear calculation basis, and then solvers or dedicated algorithms generate solutions. What enterprises need most is that this path can run stably and continue to be effective after business changes.
When enterprises apply operations research and optimization, they usually start with specific issues such as production scheduling, replenishment, and personnel allocation. But customer priorities have been adjusted, new equipment has been put into use, delivery commitments have changed, and the original reasonable arrangements may need to be reconsidered. At this time, the difficulty lies not only in whether the algorithm can calculate better results, but also in whether the company can express the new business requirements clearly in a timely manner and accurately implement them into the program.
AI Coding provides new means to maintain these decision-making capabilities. AI can assist in understanding requirements, writing code, and can also adjust algorithms based on test results. If business data, rule management and execution feedback are further connected, the system has the opportunity to continuously support business decisions.
In this system, operations research is responsible for a core job: transforming ideas proposed by AI into decision-making procedures with clear goals and clear constraints that can be repeatedly executed and inspected. We can understand this process as gradually transforming the uncertainty in the AI generation process into the certainty of program execution and rule checking. Completing this transformation requires business confirmation, formal expression and independent verification, and cannot just rely on generating a piece of code.
The "decision-making center" mentioned here is a system that can repeatedly complete the following tasks: humans determine business goals, AI assists in clarifying constraints and rules, the decision-making program calculates plans based on current data, and the execution results become the basis for the next round of adjustments. It serves specific decisions and continuously maintains these capabilities as the business changes. Next, we follow this link to see what work each link needs to undertake.
2. When people define goals, they also need to clarify how to choose between goals.
Reduce costs, improve delivery rates, reduce inventory, and keep plans stable, often all at the same time. The problem is that they are not necessarily the best at the same time. For example, in order to improve equipment utilization, the same products can be produced together, but this may increase the waiting time for some orders; in order to deliver on time, overtime can be arranged, but this increases costs.
If these conflicts are not accounted for, the program may still give a mathematically good result, but it may optimize in a direction that is not consistent with what the manager really cares about.
This is where AI can help people expand general goals into discussable options. Rather than directly asking how much weight each goal has, it is better to first calculate several sets of candidate options and show the impact of different options on delivery, cost and schedule changes, and then let the business leader confirm which costs are acceptable.
For example, managers can first require key orders to meet delivery commitments and then use the remaining space to reduce overtime costs. If the two cannot be reconciled, the system should explain where the conflict occurs and provide comparable adjustment options. Whether to add shifts, coordinate delivery dates, or change order priorities still needs to be decided by someone with the appropriate authority.
Therefore, the results of goal definition should include optimization direction, prioritization, and adjustment authority. AI can help ask questions, calculate impacts, and explain differences, but operational trade-offs need to be clearly attributed to humans.
3. AI assists in forming rules. The key is to make vague requirements checkable.
Equipment cannot process two tasks at the same time, usually due to resource constraints that must be met. Certain types of operations require corresponding qualifications and should also be explicitly restricted. In contrast, minimizing line changes and giving priority to the original plan are often preferences that can be weighed against other goals.
There are still some practices that need to be reaffirmed. For example, a certain team has been responsible for a certain type of orders in the past, which may be due to skill requirements or just historical division of labor. If AI sees this correlation and writes it into a rule that cannot be violated, the system may fix past habits and lose room for rearrangement.
Therefore, what AI sorts out from files and historical data should first become rule candidates to be confirmed. Business personnel need to examine its basis, scope of application and exception conditions, and then decide whether it should become a hard constraint, an optimization preference, or just a reference experience.
These validations should ideally form a decision-making protocol that can be maintained on an ongoing basis. There are goals and priorities, as well as rule sources, applicable objects, data calibers and inspection methods. When the rules change in the future, the system can follow this specification to find the affected code and tests without having to look for the current meaning in the chat history.
The natural language modeling and conversational checking introduced at the beginning come into play here: the confirmed requirements need to be accurately entered into the mathematical model and code, and the conflicts that arise in the calculation need to be interpreted back to the business language. Only when these two directions can be connected can business personnel continue to participate in the establishment and adjustment of rules.
Two concepts need to be always distinguished here: the large language model is responsible for understanding and generation; the optimization mathematical model expresses business problems with variables, constraints and goals. The fact that the language model has written code that can run can only mean that the generation process has taken a step forward. It also needs to be verified whether the program accurately expresses the original requirements.
4. Operations research allows the ideas proposed by AI to become decision-making logic that can be stably executed
If you directly let a large language model schedule production, it needs to understand the rules, remember resource constraints, and decide the order of tasks in the process of generating answers. The same requirement may be handled differently due to changes in context and generation process. Even if the output looks reasonable, further confirmation is needed to see if equipment conflicts, process dependencies, or delivery conditions have been missed.
Operations research provides a means of articulating these requirements. Which tasks can be adjusted correspond to the decision variables; which conditions must be adhered to, correspond to the constraints; how to compare different solutions, correspond to the objective function. A solver or specialized algorithm performs calculations based on these definitions, and the output is verified by a checker. The business requirements thus move from the description in the dialogue to the logic of actual execution.
For example, "the same device cannot process two tasks at the same time" can be written as a clear time constraint, or it can be implemented as a resource occupation check in the algorithm. The program must deal with this restriction every time it schedules a task, and the final result must be independently verified. This way, the system does not have to rely on the language model to remember and correctly implement this requirement every time it generates a schedule.
This is the core value of operations research in the decision-making center: to convert the candidate methods proposed by AI in the understanding, design and coding stages into executable decision-making capabilities after confirmation and verification. AI can continue to propose new algorithms, but each candidate must be checked against the same set of business requirements and evaluation methods before it becomes an officially operational version.
The “certainty” mentioned here mainly means that the rules are clear, the execution process is controlled, and the results can be inspected and traced. It does not require that all algorithms return exactly the same arrangement every run. Some search algorithms involve stochastic processes, and there may be multiple equally good solutions to the same problem; these solutions should be subject to the same constraint checks and use consistent metrics to compare quality.
Similarly, just because a program can be executed stably does not mean that it is necessarily correct, nor does it mean that it can always find the optimal solution. Whether the rules are fully expressed requires business confirmation and testing; whether the solution is feasible requires inspection; whether the quality is good enough requires comparison with baselines, known limits, or other methods. Operations research provides a clear expression of these issues, and the verification mechanism implements them into procedures.
Future demand, processing times and equipment conditions may still change. For these real-world uncertainties, different scenarios can be set up to check whether the solution is still available under disturbances and recalculated after the status is updated. What the system gains from this is the ability to handle changes with a basis and boundaries.
5. AI Coding can build capabilities, and daily decisions are run by verified programs.
The construction cycle is responsible for building and modifying decision-making capabilities. Business people make requests, AI assists with clarification, and then writes modeling code, specialized algorithms, and data interfaces. After independent inspection, historical replay and necessary simulation, the candidate program forms a releaseable version.
The run loop handles daily tasks. The system receives the latest orders, inventory and resource status, loads the confirmed rules and procedures, calculates and checks the plan, and then hands it over to the business system for execution according to authority. The data, rules, program versions and output results used for each run should be retained.
This arrangement allows the two loops to run at different speeds. When orders change, existing programs can be recalculated immediately. For equipment failures, material shortages or personnel absences that have been considered, the system will make adjustments according to the existing exception handling mechanism. It is only necessary to enter the program modification process when encountering situations that are not covered, changes in rules, or continued failure to meet requirements.
This has different engineering characteristics from having the language model re-develop the entire business problem every time it is scheduled. Verified programs can be executed repeatedly, and the results are easier to check and compare. The role of AI is more in proposing improvements, implementing improvements, and helping to analyze whether improvements are effective.
AlphaEvolve provides a practical example of this route. It generates candidate code through a language model, runs and scores it using an automatic evaluator, and then continuously improves the algorithm. Google reports that the heuristics discovered therein are used in data center scheduling. This supports an important assertion: AI can participate in decision-making systems by improving running algorithms without having to personally bear every online decision.
The computing backend can also remain open. For problems that can be clearly expressed as mathematical models, mature solvers can be called; for problems with special structures or response requirements, dedicated algorithms written with AI assistance can be used; the two can also be combined. The selection should be based on correctness in actual tasks, solution quality, time consumption and maintenance difficulty.
6. Enterprise-level coordination requires sharing goals, status, and resources
Purchasing may want to expand batch sizes to reduce unit prices, warehousing may want to reduce inventory occupancy, production may want to keep equipment running continuously, and sales may want to shorten delivery times. If each program is optimized only around the metrics of its own department, the overall cost to the enterprise may be higher.
Therefore, the decision-making center needs to establish cross-business coordination relationships. Which resources are used jointly by multiple departments, which commitments have higher priority, and which subsequent arrangements will be affected by changes in a plan all need to be expressed in the system.
Here, business ontology can play a specific role. By unifying objects such as orders, materials, equipment, and teams and their relationships, the system enables different decision-making processes to use consistent business meanings. Only after objects are associated with current data and executable operations can calculation results have the opportunity to smoothly enter the business process.
Palantir's Ontology document connects business objects, relationships, actions, and functions to the same operational layer, providing a reference for this organizational approach. However, unifying business meaning is only the foundation, and the system still needs special rules and algorithms to handle resource competition and goal conflicts.
Architecturally, we can allow different business areas to retain their own decision-making services, connected by common goals, status, and resource boundaries. For example, upper-level planning first determines production capacity allocation and delivery commitments, and then calculates the execution sequence for specific production scheduling procedures; if local arrangements cannot meet requirements, conflicts are fed back to the planning level for re-coordination.
This layered approach allows companies to gradually expand capabilities. Making one scenario reliable first and then connecting adjacent scenarios is easier to verify and maintain than trying to squeeze all businesses into the same computing problem from the beginning.
7. Implementation feedback should help the system find areas that really need improvement.
Order data may not be updated in a timely manner, processing time forecasts may be low, and there may be constraints on site that procedures have not yet documented. If the system sees a delivery delay, it simply asks the AI to rewrite the search strategy, possibly in the wrong place.
Therefore, feedback needs to be checked layer by layer along the decision-making process: whether the data at the time was accurate, whether the predictions deviated, whether the rules were complete, whether the algorithm found a good enough solution within the specified time, and whether the execution was carried out according to the original plan. Different reasons correspond to different treatments.
This is also the importance of long-term operating records. Nextmv's DecisionOps documentation treats versions, runs, experiments, and deployments as a set of co-managed objects. By saving input, configuration, results, and operational information, teams can replay a decision and compare the differences before and after modifications.
On the other hand, automated improvements must maintain the original business requirements. OptiRepair distinguishes between mathematical feasibility and business plausibility in supply chain optimization repair studies: Just because a program recovery is feasible does not mean that the repaired arrangements still meet business requirements. If the necessary constraints are removed in order to work out the answer, apparent success loses its meaning.
Therefore, the decision-making center needs an independent checking mechanism. The modified procedure needs to be valid on the new problem but also correct on the original test. For requirements that truly cannot be met simultaneously, the system should clearly state the conflict and allow people to choose how to adjust the conditions.
8. Start with a scenario to verify decision-making quality and maintenance efficiency.
The first step is to determine the baseline of the existing process, including solution quality, response time, and how many manual changes will be required by business personnel. Then, under the same goals and data, a fixed program built by experts was compared with a program built with AI assistance to check whether the new method actually improved the results.
Next, rule changes and unusual scenarios should be proactively included. After adding a new resource limit, how long does it take to go online correctly? After the order structure changes, does the original algorithm still apply? Will fixing one problem break other scenes? These questions can verify whether the system has continuous maintenance capabilities.
Historical playback can help compare plans, and shadow running can allow new programs to receive real data without affecting the business temporarily. Finally, the actual effect can be observed through a small-scale launch. Good results in shadow operations also need to be verified by business results after execution.
For enterprises, the benefits worth measuring include not only cost, delivery rate and resource utilization, but also the time required for rule adjustment, the proportion of manual intervention, and the ability to quickly find out the cause of a problem after it occurs. Only with the joint improvement of these aspects can AI + operations research truly reduce the difficulty of enterprises using and maintaining decision-making systems.
Moving from solving a problem to building a decision-making center means that we begin to put goals, rules, algorithms, data and execution into the same continuous running process. People are responsible for determining business direction and key trade-offs, AI assists in exploring and implementing methods, and operations research implements these methods into calculation processes with clear goals, constraints, and evaluation basis.
AI brings the flexibility to propose new methods, and operations research and verification mechanisms allow these methods to become stable running programs. This transformation from uncertainty of generation to certainty of execution is an important reason why AI+operations research deserves to become an enterprise decision-making infrastructure. Companies can continually improve algorithms while basing every formal decision on confirmed rules and proven procedures.
Here is the link to the Microsoft OptiMind code base
MVP Juji Station | Microsoft Research releases OptiMind: a 20 billion parameter model that converts natural language into optimization solver-ready models
Machine-translated from the Chinese original AI＋运筹：从求解一个问题，到建设企业的决策中枢 (published 2026-10-31). WeChat original ↗