Your AI planning assistant needs an onboarding plan

A new order arrives. A machine stops. Someone is absent from the next shift. The production plan needs to change, and each person has a different part of the answer.

Purchasing knows what materials are available. Production knows which machines can run. The planner has to turn those separate views into a decision before the situation changes again.

That is where Nicolas Souvlakis begins in Episode 2 of AI in Swiss Industry. His argument is about the limits of a fragmented planning process. Adding analytical capacity can help the planner see more of the situation, but the business still has to teach the system what matters.

His comparison is useful: think of AI as a new employee. Give it a defined job, explain the context, review its work and correct its mistakes. A capable new colleague does not arrive knowing which customer commitment is sensitive, which production constraint is negotiable or which data source is out of date. Neither should an AI planning assistant be treated that way.

For a manufacturer considering AI in production planning, the practical question is what the system should prepare so that a responsible person can make a better decision.

Watch the published short on LinkedIn. French recording; English article.

01 Start with the decision that keeps interrupting the day

In the clip, Nicolas describes a planner, a buyer and a production manager looking at different parts of the operation. The problem emerges when a disruption crosses those boundaries. A revised sequence might be feasible on the machine schedule but impossible with the available materials. A delivery promise might look achievable until staffing is considered.

Our recommendation is to choose one recurring decision before selecting the technology. For example: when a machine becomes unavailable, which orders need attention and what alternatives can the planner consider? That is a more useful starting point than asking an assistant to optimise the factory.

Describe the trigger, the person responsible and the output they need. An initial assignment might ask the system to assemble affected orders, identify missing information and compare feasible alternatives. The planner would check the assumptions and decide what to do next.

This creates a clear boundary for the first implementation. It also makes evaluation possible. You can examine whether the assistant found the right orders, used the current constraints and explained the consequences. A broad ambition to make planning intelligent offers much less to review.

02 Separate the forecast, the plan and the explanation

The source conversation moves between forecasting and operational planning. They are connected, but an implementation should distinguish their jobs.

A forecast estimates what may happen. A production plan decides what to make and when, subject to constraints. An explanation helps someone understand why an option was proposed. These outputs require different evidence and may come from different components.

A forecasting model might estimate demand. Scheduling logic might test capacity and material availability. A language model might summarise the results for the planner. The fact that an explanation sounds convincing does not establish that the forecast is accurate or that the schedule is feasible.

A useful acceptance check is therefore specific to each layer. Does the demand estimate perform against an appropriate benchmark? Does the proposed sequence respect the constraints? Does the summary faithfully describe the underlying results? Combining those checks into one impression of whether the assistant seems intelligent makes failures harder to locate.

The forecasting methodology in Forecasting: Principles and Practice reinforces the need to evaluate predictions on data that were not used to fit the model. For this planning use case, that means a polished explanation of yesterday's events should not substitute for evidence about decisions made with information available at the time.

SAP describes a similar division of responsibility in its production planning and operations agents: the system checks material, capacity and scheduling conditions, recommends corrective actions and asks for confirmation before execution. This is a vendor example of a bounded workflow, not evidence of a particular result for your factory.

03 Write the new employee's job description

The new-employee analogy becomes operational when the team can specify what the assistant may do. We suggest a short role description that answers five questions.

• What event starts the work? A machine outage, a material delay or a changed order priority.
• Which information may it use? Named systems, approved fields and an agreed refresh frequency.
• What must it return? A concise exception summary, alternatives and the assumptions behind them.
• What must it leave to a person? Decisions involving customer promises, unresolved constraints or changes outside its assigned scope.
• What happens when it cannot complete the task? It flags the missing evidence and directs the issue to the right owner.

For the machine-outage example, a useful output could compare retaining the sequence, moving eligible work to another machine or rescheduling affected orders. Each option should show which constraints have been checked and which still need confirmation.

This is a proposed operating pattern, rather than a claim that any off-the-shelf assistant can perform it immediately. Access to the right data, the scheduling logic and the review process all need to be implemented. The role description helps the team find those requirements before an impressive demonstration becomes a production dependency.

04 Give it business context that someone owns

Nicolas's central warning is that a new model needs time to learn the business. In implementation terms, there are several ways to supply context: configuration, reference information, retrieval from approved systems, explicit business rules and, where appropriate, model training.

Those mechanisms should not be confused. Correcting a response in a chat does not automatically update every future decision. Someone needs to determine where the correction belongs and how to check that it has taken effect.

Start with the terms people use. What counts as available stock? Does a material quantity include items awaiting inspection? Which order date is a customer commitment, and which is an internal target? Can an alternative machine perform the same operation without additional setup or approval?

Then identify the owner of each definition. Purchasing should be able to resolve a supplier-status ambiguity. Production should own capacity assumptions. The planner should know who can authorise an exception. An assistant can bring conflicting information together; the organisation must decide which information governs the decision.

The result is a practical onboarding pack: a bounded set of definitions, rules, examples and contacts. It can be reviewed as the operation changes. This also gives the team a shared reference instead of leaving essential context in the memory of the most experienced planner.

05 Make correction part of the workflow

Near the end of Short4, Nicolas makes correction part of the new-employee analogy. The point is that feedback belongs in the relationship with the system from the beginning.

A correction should do more than make the latest answer look better. It should help the team identify the failure. Was the input stale? Was a constraint missing? Did the model make a poor estimate? Did the summary misrepresent an otherwise valid calculation?

For each rejected recommendation, record the reason, the evidence used by the reviewer and the owner of the fix. A missing capacity rule should lead to a rule change and a repeat check. An outdated material status should lead to a data-refresh investigation. A misleading explanation should lead to a check of how the results are presented.

Treating every failure as a prompt-writing problem can hide the real work. Equally, retraining a model will not repair an unclear decision owner. The review loop should connect each observed problem to the part of the process that can actually correct it.

The NIST AI Risk Management Framework provides a broader basis for this approach through defined responsibilities, ongoing assessment and management of AI risks. Here, the practical application is modest: the person reviewing the recommendation needs both a way to challenge it and a route to get the underlying issue fixed.

06 Ask for an evidence trail, not just an answer

A planner needs enough information to decide whether a recommendation deserves attention. We suggest keeping the first view short, with the detail available underneath it.

The summary should identify the disruption, the affected work and the proposed next step. The supporting view should show when the inputs were refreshed, the constraints considered and the information still missing. If an option depends on a supplier delivering earlier than currently confirmed, that dependency belongs in the recommendation itself.

For the planner, this changes the interaction. Instead of reconstructing the whole analysis, they can challenge a particular assumption: is the alternative machine really available, or has the system missed a maintenance window? The answer can then be checked with the person who owns that information.

An evidence trail is also useful after the decision. If the team later asks why an order moved, the record should distinguish the system's proposal from the planner's choice and the conditions known at that moment. That makes review more useful than simply labelling the final outcome good or bad.

07 Evaluate the handoff as well as the model

Nicolas argues that AI can analyse and summarise information so that an experienced planner can decide. That handoff is where the first evaluation should focus.

Select a recurring planning problem and capture how it is handled today. Record the available information, the time spent assembling it, the people consulted and the final decision. Run the proposed assistant against comparable cases while keeping operational authority with the existing team.

Review several dimensions together: whether it identified the relevant constraints, how much checking the planner had to do, whether an explanation concealed uncertainty and whether the final choice remained workable. Track time spent reviewing and correcting as well as time saved preparing the analysis.

Avoid converting faster analysis directly into a claim about financial return. A quicker recommendation may still require the same coordination work. Any business case should connect the changed process to outcomes the organisation can observe, such as fewer avoidable replanning cycles or better adherence to commitments, with clear definitions and a credible comparison.

The clip's expansive language about analytical capacity is a speaker's perspective, not a measured performance guarantee for your operation. The implementation earns trust through its own evidence.

08 Questions to answer before the first planning pilot

Does an AI assistant need access to every system?

Start with the information needed for the selected decision. A bounded role makes it easier to establish permissions, validate definitions and notice missing dependencies. Broaden access when the use case and the evaluation justify it.

Should it change the production schedule automatically?

For the proposed first workflow, it prepares options for review. Any later execution authority should be specified separately, with clear limits, exception handling and a way to recover. Preparing a recommendation and applying it are different responsibilities.

How do we know it has learned a correction?

Save the case that exposed the problem, apply the appropriate change and run it again alongside other representative cases. Check the result rather than assuming the correction persists because the system acknowledged it.

What is the first deliverable?

A role description and a small set of representative planning decisions. Together, they give the team something concrete to build, challenge and improve.

AI's role in this clip is to expand what a planner can analyse. The organisation's role is to make that capacity useful. Give the assistant a clear assignment, teach it the business context and make correction routine.

Explore our method or talk to Embiggen X about the planning decision you want to improve first.

09 Sources

• Embiggen X, IA dans l’industrie suisse: Optimiser la planification coûte cher. Episode 2: Nicolas Souvlakis discusses fragmented planning, the new-employee analogy and correction.
• Hyndman and Athanasopoulos, Forecasting: Principles and Practice, evaluating forecast accuracy.
• NIST, AI Risk Management Framework: Core.