Long-Term Planning Agents and the Plan of Record

From WFM Labs

Long-term planning agents are the specialists of a planning agent team that run the monthly and annual clock: they assemble the inputs to the capacity plan, convert requirement hours to full-time equivalents to a roster shape to a gap, run the scenarios, and draft the plan in the shape the enterprise planning platform consumes, where it waits for a signature. The page's claim is that everything in the monthly cycle up to the decision is specified work an agent can do, and that the decision itself, what the organization commits to, is discretionary work a person does, with the plan of record as the boundary between them. This page maps the agents onto the stages of the Capacity Planning Cycle, separates proposal from signature, and gives the arithmetic in graded form.

The cycle the agents run inside

The Capacity Planning Cycle page defines the monthly process as six stages on a business-day calendar: demand refresh, supply roll-forward, requirement and gap, clearing, lock and decide, execute and learn. This page does not redefine them. It says what an agent team does in each.

Stage What the agents do What a person does Gate
Demand refresh The forecaster produces the mid- and long-term forecast versions from the demand ledger and the events ledger, with assumption registers; the scout injects confirmed drivers Confirms drivers the agents cannot know: a client's announced change, a contract renewal None; the versions are proposals
Supply roll-forward The data engineer rolls headcount forward by cohort and tenure from the supply ledger: attrition, ramp, planned moves, shrinkage Confirms planned moves and hiring already approved None
Requirement and gap The capacity planner computes requirement hours by channel and month, converts to FTE, and states the surplus or deficit by unit with its drivers, every input graded Reviews the driver attribution None
Clearing The capacity planner nets surpluses against deficits under the rules in the profile, producing a feasible-move set, a residual need and the binding constraints Owns the rules; challenges a move the rules permit but the unit would decline None
Lock and decide The capacity planner assembles the decision pack: the plan, the scenarios, the moves, the requisitions, each with its assumption register Signs. Node owners accept or decline each move; the planning lead signs the plan of record Plan signature
Execute and learn The adapter exports the signed plan to the enterprise planning platform; the post-analyst scores last month's plan against actuals by layer Reads the variance; opens a register row where the miss is unexplained Export refuses an unsigned plan

The annual plan is the same clock run with a longer horizon and a budget envelope from finance as an additional input, on the calendar Workforce Planning Calendar and Annual Planning Cycle describes. The agents do not know the envelope; the profile ledger holds it, entered by a person.

The arithmetic, graded

The conversion from demand to FTE is standard and is stated here only to show how grades travel through it.[1] Requirement hours per day equal handled contacts times handle time, divided by the target occupancy. Paid hours equal requirement hours divided by one minus shrinkage. FTE equals weekly paid hours divided by the paid hours in one full-time week. A computed figure inherits the weakest grade among its inputs, so an FTE figure built on a measured volume, a measured handle time, an asserted occupancy target and an estimated shrinkage is at best [E], and the plan says so. An estimate is stated as a calibrated range with its assumption, never as a point, which is the measurement discipline's ordinary rule for a quantity nobody has measured yet.[2]

The scenario runs are the same arithmetic over alternative assumption registers: a migration phase landing a month late, a partner cohort's handle time holding its level shift, an attrition rate at the top of its range. The capacity planner produces the scenario pack as a set of plan versions that differ only in named assumptions, so that a reader can see what each scenario changed. Scenario planning as a discipline is older than the tooling and does not depend on it; what the agent adds is that every scenario is a versioned file with a register rather than a tab in a workbook.[3]

Proposal and signature

The boundary is the plan of record, and it is enforced in the file, not in policy. A plan version has a signature block: the name of the signer, the date, and the version signed. The adapter that exports to the enterprise planning platform reads the block and refuses a version without it. A node owner's acceptance or decline of a move is recorded the same way, on the move, with the price of the decline where one is stated. The design follows Build the Rule, Not the Destination: the agents re-derive the destination each cycle; the rule that produces it and the signature that adopts it are human.

Two consequences follow. A plan is never "in the system" without a person having put it there, which answers the most common governance objection to planning automation. And the cycle cannot stall on the arithmetic, because the arithmetic is done before the forum meets; it can stall only on the decision, which is where a stall is informative.

Why the enterprise planning platform is the system of record

The plan of record lives in the enterprise planning platform, not in the agent team's ledgers, for a reason that has nothing to do with agents. Finance, HR and the business read the plan there; the budget–forecast–actuals loop runs there; a plan the agent team held privately would be a second source of truth. The plans ledger is therefore an archive of versions and registers, and the platform holds the signed current state. The adapter's job is to keep the two consistent in one direction only: from signed version to platform. It never reads a plan back from the platform as if it were a proposal, because a plan edited in the platform has no register and no grades and cannot be evaluated.

Technology Journey from Level 2 to Level 5 places the plan of record and the simulation engine as the Level 4 additions, one component deliberately held as two arms on separate platforms, on the data core that Level 4 builds; this page assumes that placement and adds the signature rule at its boundary.

Worked example

The series example, in the last week of March. Phase 2 of the migration is scheduled to double the migrated population on Monday 30 March 2026, and the March cycle must size it. On the demand-refresh stage the forecaster's mid-term version carries voice handle time at 452 seconds [M], the level measured since go-live, with a second scenario at 412 seconds [A] labeled "pre-migration level, carried, for comparison." On requirement and gap, the capacity planner computes voice requirement for the phase 2 population: 4,210 handled contacts per day [M], scaled by the phase 2 population ratio from the profile [M], times 452 seconds [M], divided by an occupancy target of 85 percent [A, policy], divided by one minus a shrinkage of 30 percent [E, range 28 to 32], across a seven-day operation, over a 40-hour week: about 155 FTE at the current population and about 310 at the doubled one, both [E] because shrinkage is. Clearing finds 22 FTE of surplus on email that the profile's rules permit to move to voice after cross-training, and states the binding constraint: the training lead time exceeds the phase 2 date. The decision pack shows the plan at 452 seconds, the comparison at 412 seconds (about 140 and 280 FTE), the move, the residual requisition, and one line under "would change this": "a handle-time learning curve in the partner cohort by 20 March would lower the plan toward the comparison." The planning lead signs the 452-second plan on 27 March. The adapter exports it. The 412-second scenario is archived with it, so that when the question is asked in May the answer is in the register.

What would change this

The stage mapping is a design proposal against the wiki's own cycle definition; the signature rule is a governance choice. A function whose enterprise planning platform can hold assumption registers and grades natively could make the platform the ledger and drop the archive, which would simplify the adapter. The claim that everything before the decision is specified work is testable: a function should sort its own monthly cycle by the Three Bands of Work test, and a stage that turns out to be discretionary stays with people.

How this connects

The page is the monthly clock of The Agent Team Model, writing to the plans ledger of Living Ledgers and exporting through Integration Agents. Its plan-signature gate is one of the five on Human Gates and Number Grades. The cycle it runs inside is Capacity Planning Cycle; the finance handoff it feeds is Labor Budgeting and Financial Planning; the scenario discipline is Scenario Planning and Contingency Staffing. The clearing stage, where surplus is netted against deficit before hiring, is the operating form of The Workforce Broker.

Maturity Model Position

A monthly cycle run by hand with one scenario is Level 2 on the WFM Labs Maturity Model™. Agents assembling the inputs and running the arithmetic, with a signed plan of record on one data core, is Level 4, and the scenario pack as versioned files is what makes planning in distributions possible: a distribution over assumptions is a set of registers, not a single point. Level 5 would re-derive the plan on triggers between cycles; this page keeps the monthly clock.

See Also

References

  1. ↑ Koole, G. (2013). Call Center Optimization. MG Books. ISBN 978-90-820179-0-8.
  2. ↑ Hubbard, D. W. (2014). How to Measure Anything: Finding the Value of "Intangibles" in Business (3rd ed.). Wiley. ISBN 978-1-118-53927-9.
  3. ↑ Schwartz, P. (1991). The Art of the Long View: Planning for the Future in an Uncertain World. Doubleday. ISBN 0-385-26731-2.
Retrieved from "https://wiki.wfmlabs.org/w/index.php?title=Long-Term_Planning_Agents_and_the_Plan_of_Record&oldid=4676"