Automated rescheduling on disruption

A floor lead’s day rarely fails because the morning plan was careless. It fails because someone calls out, a high-priority work item appears after stand-up, or both land in the same hour. The published roster still looks coherent on paper. On the floor, queues lengthen, skill coverage thins, and the lead spends the next stretch rebuilding assignments by hand.

Manual recovery has a predictable shape. You open the current schedule, scan who is still available, remember who can cover which work, and try not to create a second problem while fixing the first. That process is slow under pressure. It also depends on one person’s working memory of constraints, so the same disruption can produce different recoveries depending on who is on shift.

Automated rescheduling on disruption does not replace that judgment. It shortens the time between “something changed” and “here is a credible revised roster.” An agent monitors unexpected absences and new high-priority items against the live schedule, then proposes a revised plan for staff to review and publish. Until someone publishes, the floor keeps running on the last approved version.

Rescheduling only helps when the inputs are complete enough to reason over. The agent should treat three sources as mandatory: absence data, priority changes, and the current published schedule. If any of those are missing, incomplete, or stale beyond the team’s agreed freshness window, the correct output is empty. A partial proposal is worse than silence because it invites a lead to publish a plan built on gaps.

Absence data should identify who is unavailable, from when, and for how long if known. A name without a start time is not enough to free their slots safely. Priority data should identify what became urgent, why it outranks existing work, and any hard deadlines or service commitments attached to it. The current schedule should expose who is assigned where, which tasks are in progress, and which slots are already locked by policy (handoffs already started, regulated coverage windows, or tasks that cannot be interrupted without a formal stop).

Optional enrichments improve proposal quality without becoming gatekeepers. Skill tags, location or station constraints, overtime rules, and known preference notes help the agent avoid illegal or low-quality swaps. They should not unblock a proposal when the three mandatory sources are absent. The rule is simple: no absence signal, no priority signal, or no current-schedule snapshot means no revised roster to review.

When a valid disruption arrives, the agent freezes a snapshot of the published schedule and marks the affected capacity. For an absence, it removes or blocks that person’s remaining assignable windows. For a new high-priority item, it inserts a demand that must be covered without orphaning work that is already mid-flight unless policy allows interruption.

Next it searches for a feasible recovery, not a perfect one. Typical moves include reassigning open slots to remaining staff with matching skills, delaying lower-priority work into later windows, splitting coverage across two people when one cannot absorb the full load, and protecting in-progress tasks that would be costly to restart. The search should respect the same constraints that governed the original plan: required coverage, skill-task fit, station limits, break rules, and any blackout periods the floor already enforces.

The deliverable is a proposed revision, not an auto-publish. The proposal should show what changed, why each change was chosen, and what remains at risk if the lead rejects specific swaps. Clear diffs matter more than elegance. A floor lead under disruption needs to see “Person A covers Station 3 from 11:00,” “Task X moves from Person B to Person C,” and “Task Y is deferred to 14:30,” not a rewritten schedule with silent edits.

If the agent cannot find a feasible recovery within the constraint set, it should return empty or an explicit no-feasible-plan result according to your operating rule, rather than inventing a schedule that violates coverage or skill requirements. Empty output on missing data and empty or blocked output on infeasible recovery are both safer than a confident bad plan.

Human-in-the-loop is the control point. The agent proposes; staff still publish. That split keeps accountability with the people who live with the outcome and who can see context the feed may not carry, such as a private coaching conversation, equipment that is about to fail, or a temporary floor layout change.

A practical review checklist stays short:

1. Confirm the disruption itself is real and correctly timed.
2. Check that in-progress work was protected or deliberately interrupted with a reason.
3. Verify skill and station coverage for the rest of the shift.
4. Scan deferred work for SLA or customer impact you are unwilling to accept.
5. Publish only when the revision is good enough to run, then communicate the change to the floor.

Speed still matters. The value of the agent is that the lead starts from a structured proposal instead of a blank whiteboard. Review time should be minutes, not a second full rebuild. If reviews routinely take as long as building from scratch, the proposal format is too opaque or the constraint model is too weak.

Trust collapses when the agent invents coverage, quietly overrides locks, or keeps proposing after its inputs go dark. Codify a few non-negotiables.

First, empty on incomplete inputs. Missing absence records, missing priority metadata, or a missing current-schedule snapshot must yield no proposal. Do not fill gaps with last week’s pattern or assumed availability.

Second, never auto-publish. Even a high-confidence recovery stays in draft until a named reviewer accepts it. Logging who published, and against which disruption event, creates an audit trail when the shift is later reviewed.

Third, preserve hard locks unless policy explicitly allows break. Tasks already past a point of no return, regulated dual-control windows, and agreed blackout periods should remain visible as immovable in the proposal.

Fourth, keep related planning surfaces connected but distinct. Constraint-based auto-scheduling builds the baseline. Skill-task matching informs who can absorb reassigned work. SLA breach prediction helps the lead judge which deferrals are acceptable. Automated rescheduling on disruption is the recovery loop that runs when the live day diverges from that baseline.

Measure the loop as an operations practice, not as a model demo. Useful signals include time from disruption detection to first reviewable proposal, share of disruptions that produce a feasible proposal versus empty or blocked outcomes, lead edit rate before publish, and whether published recoveries actually restore throughput without creating secondary absences of coverage.

Track empty-output cases separately from rejected proposals. Empty output caused by missing data is a data-pipeline problem. Rejected proposals with complete inputs are a constraint or UX problem. Mixing those buckets hides the real fix.

Start narrow: one site, one shift pattern, a defined set of absence and priority event types. Expand only after leads trust that silence means “inputs incomplete or recovery infeasible,” and that a proposal is always a draft until someone on the floor publishes it.

Related: Constraint-based auto-scheduling, SLA breach prediction, Skill-task matching