Copilot, rules engine or AI operator: who actually owns the workflow?

One scenario for comparing all three approaches

Consider an order already created in the TMS. At 4:12 p.m., the customer emails a request to move delivery to the following morning. The file contains a validated rule: any change received less than 24 hours before the slot must be submitted to operations. The new slot must also be checked in the delivery site portal.

The desired outcome is the same in every approach: link the email to the correct transport, identify the change, apply the 24-hour rule, check availability, prepare the decision, update the TMS if authorized, and retain evidence. What differs is the component responsible for each step.

What each component actually owns

The copilot: make a person faster

In this scenario, a copilot can summarize the email, retrieve relevant information when it has access, and suggest a response or a change. It is particularly useful when an operator wants to explore, verify or decide in an interaction-led situation.

Its limitation is not intelligence but ownership of the sequence. As long as the person must open the file, provide context, launch the next step and observe the result, that person owns the workflow. This can be exactly the right model for rare, sensitive or hard-to-formalize decisions.

The rules engine: make a decision explicit

A rules engine is excellent at the condition “change received less than 24 hours ahead: approval required.” It produces a stable, testable and explainable decision, provided it receives a structured request time, original slot and scope.

It should not be judged on promises it does not make. A rules engine does not necessarily resolve an ambiguous email, choose the right screen or verify the result by itself. Those capabilities can surround it. In Vigilo, validated rules remain essential assets: the AI operator uses them rather than replacing them with an opaque decision.

The AI operator: maintain the file loop

In the same scenario, the AI operator observes the new email, links it to the relevant order, identifies a change request and gathers the required information. It applies the validated rule, checks authorized availability, prepares the case for operations, and executes only the permitted action. After writing, it reads the resulting state and attaches evidence to the file.

Its role is less about “deciding everything” than maintaining continuity: knowing the file state, which step is allowed, which component to use and why it must stop. An ambiguous reference, conflicting sources or a missing right leads to a contextual handoff rather than improvisation.

1. 01
   Observe

   Detect the event in an authorized source.

2. 02
   Link

   Identify the file and retain the origin of the information.

3. 03
   Understand

   Qualify the change and the data it affects.

4. 04
   Decide within scope

   Apply the active rule or request approval.

5. 05
   Act

   Use the API or interface appropriate to the system.

6. 06
   Verify

   Compare the state actually obtained with the expected outcome.

Adaptability does not mean pretending every TMS is the same

Companies do not use the same screens, fields or approval rules. Even two teams using the same TMS may organize order entry and exceptions differently. An adaptable solution therefore does not claim that all systems are interchangeable.

Vigilo separates file logic — events, intents, rules, checks and stops — from the way each environment is operated. Connectors, UI paths, mappings and permissions can be configured and tested for the selected workflow without rebuilding the whole product. Adaptation becomes a governed, reusable capability rather than a succession of isolated projects.

Choose an architecture, not a label

• Use a copilot when exploration and decisions are intentionally led by a person.
• Use a rules engine for explicit, stable and auditable conditions.
• Use an AI operator when a file must progress across several sources and systems without losing context.
• Combine all three when a workflow alternates deterministic decisions, automated preparation and human judgment.
• Evaluate the whole system through its stops, checks and recovery paths, not only its nominal demonstration.