The Short-Term Forecasting Loop with an Agent Team
The short-term forecasting loop with an agent team is the daily clock on which a planning function's first agent team runs: actuals arrive, are reconciled and versioned, yesterday's forecast is scored and its miss decomposed, events are matched to the miss, open hypotheses are updated where a test now has data, a reforecast is proposed with its assumption register, an evaluator passes or blocks it, a planner approves it, and only then is the daily note published and the forecast file written for the WFM platform of record. The loop is the series' recommended first handover because its failure is contained, its steps are already half-documented in most functions, and the planner who approves it is the person best placed to correct it. This page walks the clock end to end and separates what each agent does from what the planner does.
Why this loop first
Three properties make the short-term loop the right first process, and they are the properties The Agentic Handover Gate recommends in a first candidate. It is internal to the function: a wrong proposal is caught at the gate, not on a customer. It has low stakes per run: a day's reforecast is revised the next day. And it forces exactly one object to be canonical, the definitions the demand ledger cites, which the function must reconcile anyway. It is also the loop planners spend the most hours on, which is why A Roadmap Pattern for Agent Teams in WFM measures planner-hours on it before anything else.
The loop is not the forecasting method. Reforecast and Rolling Forecast Methodology governs when a forecast is revised and by whom; Intraday Reforecasting Methods gives the ratio, regression and Bayesian updates an intraday revision uses; Forecasting Methods covers the models. This page describes the operating loop the team runs around whichever method the function has chosen.[1]
The clock, step by step
| Step | Agent | What it does | Rung | Output |
|---|---|---|---|---|
| 1 | Data engineer | Loads the day's actuals by channel and interval; checks that offered equals handled plus abandoned, that every column cites a definition, that the population count matches the profile; writes a new version of the demand and supply ledgers | — | Demand and supply versions, graded [M] |
| 2 | Post-analyst | Scores yesterday's forecast version against the actual by channel and interval; decomposes the hours miss into volume, handle time, mix and supply; runs control charts; flags regime changes | 1 | A variance record attached to the forecast version |
| 3 | Scout | Reads the events ledger for anything whose effect window covers the miss; proposes new events where none does, with a window and grade [A] | 1 | Event matches and proposals |
| 4 | Causal analyst | For each open register row whose settling test now has data, runs the test and updates the hypothesis table; opens no new row without the librarian | 2 and 3 | Hypothesis table updates |
| 5 | Forecaster | Proposes the next forecast version with its assumption register; every changed assumption states its old value, new value, source and grade; carried assumptions are labeled carried | — | Forecast version, proposed |
| 6 | Evaluator | Checks: no unlabeled carried assumption; every number graded; no rung-1 finding written as cause; every definition cited; the miss decomposition sums to the miss; passes or blocks with reasons | — | Pass or block, in the run log |
| 7 | Coordinator | Writes a gate request naming the version, the changed assumptions and the evaluator result | — | Gate request |
| 8 | Planner | Approves, amends or rejects; an amendment is a new version with the planner as author | — | Signed version |
| 9 | Reporter | Publishes the daily note in answer-first form: title sentence with grade, what changed, decision requested, next date | — | Daily note |
| 10 | Adapter | Writes the forecast file in the platform of record's shape; refuses an unsigned version | — | Forecast load |
Steps 1 to 7 run without a person. Step 8 cannot. Steps 9 and 10 cannot begin until step 8 has. The order is the coordinator's rule and does not vary.
What the post-analyst may and may not say
The post-analyst's decomposition is arithmetic, not explanation. It splits an hours miss into the share attributable to volume, handle time, channel mix and supply by holding each fixed in turn, which is the sequential or Shapley decomposition the variance literature standardizes. Its control charts distinguish common-cause variation from a special cause using the ordinary rules.[2] What it writes is "handle time is out of control since date X and accounts for Y percent of the miss." What it does not write is why. That sentence belongs to the causal analyst, after a diagram and a test, and the evaluator blocks a run in which the post-analyst has written it. The rule is the ladder of causation applied as a permission.[3]
What the planner does
The planner's work changes shape rather than disappearing. Before the team, the planner typed the reconciliation, ran the comparison, wrote the note and loaded the file. With the team, the planner does four things the agents cannot.
- Decides. The gate is a decision, not a click. A gate a planner approves reflexively is not a control, and the human-factors literature is clear that verification of reliable automation decays toward assent unless the verifier must produce something.[4] The gate request therefore asks the planner to confirm or amend each changed assumption, not to approve the version as a whole.
- Confirms events. A scout's proposed event is [A] until a person says it happened. The planner is usually that person, because the planner heard about the go-live in a meeting the agents were not in.
- Sets the question. When the miss is not explained, the planner states the decision the explanation would feed, which opens a register row through the intake door on The Question Register and Knowledge Base.
- Corrects the specification. Every rejection at the gate is logged with a reason; a reason that recurs is a defect in an agent's rules, and it goes to the automation analyst.
Worked example
The series example: a corporate client book on voice, chat and email, in-house and partner teams, phase 1 of a servicing-platform migration live from Monday 2 March 2026. The clock runs on Wednesday 4 March.
Step 1 writes demand and supply for 3 March; sums reconcile on all three channels; the population count matches the profile. Step 2 scores 3 March: voice handled 4,210 [M] against 4,180 [C], plus 0.7 percent; handle time 452 seconds [M] against 412 seconds [C], plus 40 seconds; the hours miss is 92 percent handle time and 8 percent volume [C]; the handle-time chart is beyond its upper limit on both post-go-live days loaded, 2 and 3 March. Step 3 finds no event whose window covers 2 to 3 March and proposes "phase 1 go-live, partner cohort," window open-ended from 2 March, grade [A]. Step 4 has no row open yet. Step 5 proposes version 2026-03-05.v1: voice handle-time assumption 452 seconds [M] from the demand ledger, replacing 412 seconds, which it relabels "carried from pre-migration average [A]"; volume unchanged. Step 6 passes. Step 7 requests the gate. At step 8 the planner confirms the event (the go-live happened; the partner cohort went first), approves the version, and adds one line: "handle-time assumption to be reviewed at phase 2." Steps 9 and 10 follow within the hour.
The register row that asks whether the shift is structural or transitional is opened the same afternoon; what happens inside it is on Hypothesis Testing with Agent Teams. A control chart on daily handle time flags a level shift on the third day; the same shift read from a monthly trend line is not visible until the trend has enough months to move. That difference is what a daily clock with a control chart is for, and it is an illustration of the mechanism, not a measured result.
What would change this
The order of steps is a design choice validated against one prototype. Field evidence that planners reject an amend-each-assumption gate as too slow, or that the evaluator step catches nothing the planner would not, would change the design: the first would argue for a lighter gate on unchanged assumptions, the second for merging the evaluator into the forecaster. Evidence that the loop's accuracy is no better than the manual process it replaced would not by itself change the design, because the loop's first claim is auditability, not accuracy.
How this connects
The loop is the roster of The Agent Team Model running once, over the ledgers of Living Ledgers, under the gate rules of Human Gates and Number Grades. Its step 3 is The Intelligence Feed; its step 4 is Hypothesis Testing with Agent Teams; its step 10 is Integration Agents. The reforecast governance it operates inside is Reforecast and Rolling Forecast Methodology, and the day it hands the forecast to is described from the human side by Daily ROC Routine.
Maturity Model Position
The loop presupposes Level 3 on the WFM Labs Maturity Model™: versioned forecasts, explicit definitions, a platform of record that accepts a file. Running it with an agent team is the first Level 4 act of a planning function, and the variance records it accumulates are what a Level 4 function's horizon-resolution curve and model cards are built from.
See Also
- AI Agent Teams for Workforce Management — the series hub
- The Agent Team Model — the roster and the clock rules
- The Intelligence Feed — the event matching of step 3
- Hypothesis Testing with Agent Teams — what happens in the row the loop opens
- Human Gates and Number Grades — the planner gate of step 8
- Reforecast and Rolling Forecast Methodology — the revision governance the loop runs inside
- Intraday Reforecasting Methods — the update methods an intraday revision uses
- Daily ROC Routine — the human day the forecast is handed to
References
- ↑ Hyndman, R. J., & Athanasopoulos, G. (2021). Forecasting: Principles and Practice (3rd ed.). OTexts. otexts.com/fpp3.
- ↑ Montgomery, D. C. (2019). Introduction to Statistical Quality Control (8th ed.). Wiley. ISBN 978-1-119-39930-8.
- ↑ Pearl, J., & Mackenzie, D. (2018). The Book of Why: The New Science of Cause and Effect. Basic Books. ISBN 978-0-465-09760-9.
- ↑ Skitka, L. J., Mosier, K. L., & Burdick, M. (1999). "Does automation bias decision-making?". International Journal of Human-Computer Studies 51(5), 991–1006. doi:10.1006/ijhc.1999.0252.
