The expensive part of a rush order isn’t the rescheduling. It’s the knock-on effects that get missed and the half-day of manual what-ifs. Convect’s agent layer does three things: it uses the ontology to find exactly what’s affected, calls the optimizer for options, and puts an explained recommendation in front of the planning manager. People make the trade-offs; they stop doing the arithmetic.
Here’s what that looks like, step by step.
The scenario: Customer D’s rush order
This is the multi-agent rush-order scenario from our demo (illustrative data, not a customer measurement):
Demand Sensing Agent: New order SO-88 from Customer D: Product A × 3,000 cases, due Thursday — 4 days earlier than standard lead time. Classified as RUSH ORDER.
Disruption Response Agent: Current schedule can’t absorb it: Line 3 is at 100% this week. Triggering incremental replan. Scope: 3 lines, 7 work orders.
Root-Cause Agent: Traced through the ontology: the bottleneck is filling. Line 2 is qualified for Product A, and raw material B1 has enough stock.
Scheduling Agent: Optimization run complete (1m 48s): 3 options. Recommending Option A — run on Line 2, defer 2 low-priority orders. Cost +0.6%, every order still on time.
Coordination Agent: Checked procurement and logistics: no extra material needed; a truck is available on Thursday’s second shift. Option A clears every cross-functional constraint.
→ Planning manager: Recommendation and reasoning sent for approval. One click to apply.
The point isn’t the speed. It’s that every step answers a specific question: Can we take it? Where’s the constraint? What are the alternatives? What does each cost? Can the other functions support it? Traditionally, a planner answers those five questions by flipping between several spreadsheets and a few phone calls.
Five agents, five jobs
| Agent | Job | How |
|---|---|---|
| Demand Sensing | Detect shifts in demand and trigger plan updates | Monitors orders, sell-through and external signals |
| Scheduling | Build the best feasible schedule from live constraints | Calls the optimization engine with current capacity and material status |
| Disruption Response | Replan around breakdowns, late materials and rush orders | Listens for execution events and triggers incremental replans |
| Coordination | Keep procurement, production and logistics aligned | Cross-functional constraint checks and conflict resolution |
| Root-Cause | Answer “why can’t this order ship on time?” | Traces the ontology backward to the binding constraint |
Incremental replanning, not a full re-run
This is the key difference from a traditional APS. After a full re-run, the planner faces a brand-new plan that doesn’t match yesterday’s, and has to work out by hand what changed. An incremental replan walks the relationship network first, draws a boundary around the affected work orders, lines, materials and customer orders — in the example, 3 lines and 7 work orders — and solves only inside that boundary.
Everything outside it stays put. The planner sees what changed and why, not a wall of new numbers.
Autonomous, but always under control
The biggest fear in any enterprise is a system that changes the plan on its own. So the agent layer is governed by four rules:
- Configurable autonomy. Thresholds by cost impact, orders affected or customer tier. Inside them, agents act; outside them, they ask.
- Every recommendation explained. Binding constraints, cost and service impact, and a comparison with the options that were rejected.
- Full audit trail. Events sensed, reasoning path, optimization runs and final decisions are logged — replayable and auditable.
- Humans in the loop. Significant decisions are approved or edited by a planner with one click, and agents learn from those choices.
Two common questions
How is this different from a chatbot? A chatbot answers questions. These agents sense business events, reason about impact using the ontology, call the optimizer to generate options, and then act or ask for approval. They take part in decisions; they aren’t just an interface.
Do we need real-time data first? No. Real-time data makes agents faster, but many teams start with scheduled syncs — hourly or once per shift — and add MES, WMS and other execution events over time.
Want to see agents handle a rush order or a breakdown on a scenario from your own operation? Book a demo, or read more about how planning agents work.
