Scheduling Agents
Scheduling agents are the specialists of a planning agent team that work the scheduling horizon: they check a generated schedule against the signed plan and the operation's rules before it is published, prepare a shift bid from the plan and the preference ledger, and propose intraday reoptimizations to the real-time team. The page's claim is that generating a schedule is already automated in any function with a WFM platform, that the work still done by hand around it, checking, preparing and proposing, is specified work an agent team can take, and that the gate belongs at publication because publication is the act that touches every worker. This page gives the three agents, the checks, and the gate.
What is already automated and what is not
Schedule generation, the assignment of agents to shifts to cover a demand curve at minimum cost or maximum preference, is a solved optimization problem and has been for decades; Schedule Generation gives the set-covering formulation and the methods, and any WFM platform of record runs a solver.[1] A scheduling agent team does not replace the solver. It replaces what a scheduler does before and after the solver runs, which in most functions is a morning of checks in a spreadsheet, an afternoon of bid preparation, and a standing worry about whether the published schedule still matches the plan that was signed last month.
Three Bands of Work sorts the scheduling work as follows, and this page follows the sort: schedule publication is specified; schedules generated and reviewed before publication are overseen. The design of the schedule, its preference weights, guardrails and workforce mix, stays with the scheduler, whom Role Evolution in the Resource Optimization Center describes as designing the schedule and as measured on retention and acceptance rather than coverage alone. The band is a property of the process as written down; this page's publication gate is stricter than the band sort, deliberately, for the period in which the checker's catch rate is being earned.
The three agents
| Agent | Reads | Does | Writes | Gate |
|---|---|---|---|---|
| Checker | The generated schedule from the platform of record; the signed plan version; the rules in the profile (hours, breaks, contract terms, fairness rules); the forecast version the schedule was built on | Reconciles scheduled hours by interval and skill to the plan's requirement; checks every rule; flags any interval where coverage falls below the plan's tolerance; reports the forecast version the schedule used and whether a newer signed version exists | A check record attached to the schedule version, every finding graded | Publication gate: the scheduler publishes; the checker cannot |
| Bid preparer | The signed plan; the shift catalog; the preference ledger; the bid rules (seniority, lottery, optimization, per Schedule Bidding and Preference Based Scheduling) | Assembles the shift set the plan requires; runs the allocation under the rules; produces the bid pack with each rule's effect shown; flags where preferences cannot be met and by how much | A bid version with its assumption register | Publication gate: the bid opens on a person's signature |
| Reoptimizer | The day's actuals and reforecast from the short-term loop; the published schedule; the lever catalog in Real-Time Schedule Adjustment; the guardrails | Proposes moves within guardrails: break shifts, skill reassignments, voluntary time off, overtime offers; states the coverage effect of each; never executes | A proposal to the real-time team's action gate | Action gate: inside guardrails a real-time analyst approves; outside, a manager |
The checker's most useful finding is usually the last one in its list: the schedule was built on a forecast version that a later signed version has superseded. In a function without a checker that mismatch is discovered on the floor.
The publication gate
Publication is the act that changes every worker's week. It is therefore the gate, and it is enforced the way every gate in the series is: the platform's publication step reads a signature block on the schedule version, and the checker cannot write one. Two things pass through the gate together, the schedule and the check record, so that the scheduler signs with the findings in front of them. A schedule whose check record shows an interval below tolerance can still be published; the signature then carries the scheduler's reason, and the reason is logged.
Placing the gate at publication rather than at generation follows the ordinary rule for placing automation stages: the higher the consequence of an error, the later the automation's authority should stop.[2] Generation can run unattended because a generated schedule affects nobody; publication cannot. The bid gate sits in the same place for the same reason.
The gate has a known failure: a scheduler who signs a schedule every week that the checker has passed every week stops reading the check record, the complacency effect the human-factors literature documents for reliable automation.[3] The countermeasure is the one The Agent Overseer prescribes: error injection. A checker that is periodically given a schedule with a known defect, and a scheduler who is told afterward whether it was caught, produces a catch rate for the check and keeps the signature a decision.
Reoptimization proposals
The reoptimizer is the scheduling team's link to the real-time day, and its boundary is drawn carefully. It proposes; the real-time team's action gate decides; the platform executes. It works within the guardrails the scheduler designed, which are part of the profile ledger, and any proposal outside them is routed to a manager rather than an analyst. Its proposals carry the coverage effect and the reforecast version they rest on, so that a proposal made on a stale reforecast is visible as such. What it never does is act on the platform directly, even where the platform exposes a write-back; the series keeps execution behind a gate until a catch rate has been published, and Level 3: The Automation Layer describes the rule-governed layer that eventually takes the execution.
Worked example
In the series example, phase 2 of the migration doubles the migrated population on Monday 30 March 2026, and the schedule for the week of 30 March is generated on Thursday 19 March from forecast version 2026-03-18.v1. On Wednesday 25 March the short-term loop's planner gate signs version 2026-03-25.v1 with the partner cohort's handle time held at 452 seconds [M] and the phase 2 population ratio applied. On Thursday 26 March the checker runs on the generated schedule. Its record shows: scheduled hours reconcile to the plan's requirement on chat and email; on voice, Monday 30 March intervals 08:00 to 11:00 fall 14 percent below the plan's requirement [C], because the schedule was built on version 2026-03-18.v1, which assumed the pre-phase-2 population; a newer signed version exists. It flags one contract-rule breach on a single roster line. The scheduler regenerates on the newer version, the checker's second record is clean except for a 4 percent Monday-morning shortfall the plan tolerates, and the scheduler signs with the note "Monday 08:00 to 11:00 covered by overtime offer, see reoptimizer proposal R-031." The reoptimizer's proposal R-031, an overtime offer to 12 cross-trained email agents for Monday morning, sits at the real-time team's action gate for approval on the day.
Without the checker, the schedule built on the old version would have been published on 19 March and the phase 2 Monday would have opened 14 percent short.
What would change this
The placement of the gate at publication is the page's load-bearing choice, and it rests on the consequence rule and the wiki's own band sort. A function that published a catch rate for the checker high enough, over long enough, to satisfy the overseen-to-specified tests of The Agentic Handover Gate could run publication as Three Bands of Work already sorts it, specified, without this page's gate; the release condition is the one Human Gates and Number Grades states. The reoptimizer's no-execution rule would be relaxed on the same evidence, and Real-Time Schedule Adjustment describes the rule-based automation it would then hand to.
How this connects
The scheduling agents are a second team in the pattern of The Agent Team Model, reading the signed plan from Long-Term Planning Agents and the Plan of Record and the forecast versions from The Short-Term Forecasting Loop with an Agent Team; the reoptimizer's proposals go to the action gate on Real-Time Agents. The publication gate is one of five on Human Gates and Number Grades. The scheduling methods themselves are on Schedule Generation and Schedule Bidding and Preference Based Scheduling; the lever catalog is on Real-Time Schedule Adjustment.
Maturity Model Position
Automated generation with manual checking is Level 2 on the WFM Labs Maturity Model™. A checker and bid preparer with a publication gate is Level 3 to Level 4, and the check record's reconciliation of schedule to signed plan version is the scheduling horizon's contribution to error by layer. Reoptimization executed within guardrails without a gate is not described here; the condition on which the gate is released is stated in evidence terms on Human Gates and Number Grades.
See Also
- AI Agent Teams for Workforce Management — the series hub
- The Agent Team Model — the pattern the three agents follow
- Real-Time Agents — the action gate the reoptimizer proposes into
- Human Gates and Number Grades — the publication gate
- Schedule Generation — the solver the team works around
- Schedule Bidding and Preference Based Scheduling — the bid rules the preparer runs
- Real-Time Schedule Adjustment — the lever catalog and the automation it grows into
- Three Bands of Work — the sort that places publication and review
References
- ↑ Ernst, A. T., Jiang, H., Krishnamoorthy, M., & Sier, D. (2004). "Staff scheduling and rostering: A review of applications, methods and models". European Journal of Operational Research 153(1), 3–27. doi:10.1016/S0377-2217(03)00095-X.
- ↑ Parasuraman, R., Sheridan, T. B., & Wickens, C. D. (2000). "A model for types and levels of human interaction with automation". IEEE Transactions on Systems, Man, and Cybernetics — Part A 30(3), 286–297. doi:10.1109/3468.844354.
- ↑ Lee, J. D., & See, K. A. (2004). "Trust in automation: Designing for appropriate reliance". Human Factors 46(1), 50–80. doi:10.1518/hfes.46.1.50_30392.
