Lift each assumption out of the formula it hides in, into a register that carries an owner and a date — then hold the plan for the capacity lead, who decides the headcount.
A horizon is set, and the demand signal, the hiring lead time and the shift pattern are held apart.
02
An assumption changes, and the plans standing on it are listed before anyone asks which they were.
Reason
03
A utilisation rate sits inside a formula, and it is lifted out as a named line in the register.
04
A plan is built, and each assumption under it carries the person who set it and the day they did.
05
A source ages past its term, and the plan leaning on it goes amber rather than carrying quietly on.
Decide
06
A downside case is drawn, and it is labelled a case and dated, so forwarding it cannot promote it.
07
A resource pool turns up in two plans, and the double count is reported rather than netted away.
Out
08
An assumption moves, and what shifts in the plan is shown beside what stays exactly where it was.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
Building the horizon, registering the assumptions and marking staleness belong to the agent. The headcount, the assumption itself and the approval of the plan belong to a named capacity lead.
Example workflow
One plan, assumptions to approval
AgentHuman
1Planning inputs receivedDemand signals, attrition history, shift patterns, hiring lead times or the last approved plan
2Horizon set and assumptions registeredThe pools counted in, the horizon each input is held at, and the day each registered assumption was set
3Required capacity derivedThe capacity asked for, the register under it, what moves if one assumption moves and confidence
4Controls appliedRegister checks, source-age checks, horizon checks and derivation confidence
No human action required
Stages 1 to 4 run unaided, and no headcount is decided at any of them — the agent is building, and the capacity lead lane opens at the assumption gate.
5DecisionSplits at the assumption gate
Register owned and current
Goes to the capacity lead to approve.
Anything stale or unowned
Adds a senior planner read first.
Capacity lead review
The plan is held with its register, its aged inputs and the pools it counted in.
Approve · Amend assumption · Send to planning review
Approved — by the capacity lead▼
6Planning and workforce records updatedOnly where write access and records policy allow it
7Outcome evaluatedAssumption currency, register completeness, lead corrections and what review found
Corrections
Each capacity-lead correction is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Approving a plan into the hiring cycle.
Deciding the headcount for a resource pool.
Setting the utilisation rate a plan runs on.
Signing off a capacity plan for the board.
Automation boundaryAgent acts unaided
✓Build the horizon so demand, hiring and shift patterns stay apart.
✓Lift each assumption into a named register with an owner and a date.
✓Flag a plan whose source data is no longer current.
✓Show what moves when one assumption is changed.
No headcount is decided except by a named capacity lead, inside the agreed boundaries.
Judging whether a demand signal is credible.
Telling a board that a plan is achievable.
Choosing which scenario becomes the plan.
Changes to the plan, the pools or the assumptions.
Example output
One capacity plan, annotated
Demand forecasting sizes goods and patient flow is beds; this is people and shift capacity across a company, where an assumption is meant to carry a name and a date.
Capacity output · single resource poolIllustrative example
Pool
Recorded as
Horizon
Evidence of record
Confidence
Held for
Second-line support, one region
Assumptions lifted, one unowned
Quarterly, rolling
Demand extract, 3 August 2026
Held unapproved
The capacity lead, by name
As receivedBuilt out of the demand extract and the register on file — nothing past those two is claimed.
What the record holdsDemand extractAttrition historyAssumption register
Why it is heldOne assumption sitting under this plan still has no owner recorded.
ActionApproveAmend assumptionSend to planning review
What the score decidesBelow the configured threshold a plan gets a planner read before the lead sees it.
Value
Where AI adds value
The same four claims, placed at the point in the workflow where each one applies.
Where the value landsValue 01 – 04
Every planFrom the signal that drove it
03Assumptions
Where the assumption is used
The agent does not vouch for a demand signal, only for what that signal said, when it was pulled, and which assumption carried it into the plan.
01Approved path
A forecast is an assumption
Move the utilisation rate, the attrition assumption or the hiring lead time, and the headcount moves with nobody having lied. When an approved plan later turns out to have run on a stale input, it is marked stale where it was circulated and the capacity lead who approved it is told.
02Human review
What was checked, and not found
No external regime governs how a company plans its own capacity: no filing, no certification, no auditor and no statutory deadline attaches to a headcount plan. The published roster and the notice owed on it are a separate duty and belong to the workforce scheduling agent, not to this page. What holds this page up is planning discipline set by your own policy, and the only thing holding a plan back is a named person.
04Build an evidence trail
The plan, the assumption it rests on and the owner who set it stay together.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Workforce systemsWorkday · SuccessFactors · UKG Headcount, roles and attrition history
Demand signalsContact centre · ticketing The arrival pattern planned for
Planning and modellingAnaplan · Pigment · spreadsheet models The models a plan is actually built in
Agent
Capacity planning and forecasting
Reads the signals Builds the horizon Holds for the lead
Recruiting and shift patternsGreenhouse · Lever · rosters Open roles and the lead time on each
A pool-level assumption-visibility figure can read clean while newly created pools carry most of the re-planning. Nestack reports the correction rate by pool, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Newly created pools
7.2%
3.7×
Review
Pools shared across teams
5.1%
2.6×
Review
Seasonal demand pools
3.1%
1.6×
Watch
Steady long-running pools
1.3%
0.7×
Normal
Bar: correction-rate lift vs. steady-pool baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
What an invisible assumption costs
A loop closes when the unstated assumption is a standing case. That suite is what the next horizon issued is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Correction rate rises on newly created pools.
02Diagnose
The utilisation rate typed into a cell once and carried through every quarter since is taken apart until one cause is left standing.
03Improve
The change goes out numbered, and the plans that forced it travel attached.
04Verify
A single red plan case is enough to stop the release.
05Learn
It is retained permanently, and the assumption rules travel with it.
Learn → DetectThe return edge. The next horizon is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, plan derivation, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Assumption-register and automation-boundary mapping.
02Demand, workforce and planning sources.
03Signal-to-plan and assumption-ownership mapping.
04Demand-signal ingestion.
05Assumption, owner and horizon binding.
06Staleness scoring and review routing.
07Lead approval workflow.
08Planning-model integration.
09Assumption and horizon cases.
10Guardrails and revision controls.
11Plan-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne pool, one horizonProductionProduction planning workflowAdvancedMultiple pools / geographies
Introduced at Pilot
Plan building to your assumptions✓✓✓
Named capacity lead approval✓✓✓
Capacity-and-demand baseline✓✓✓
Introduced at Production
Reporting by resource pool—✓✓
Planner review workflow in your systems—✓✓
Approved write-back—✓✓
Demand-signal integration—✓✓
Introduced at Advanced
Multi-signal reconciliation——✓
Cross-pool capacity packs——✓
Large pool inventories——✓
Multi-horizon assumption controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, pool volume, approval controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your live resource pools and the assumptions each is planned on→Assumption capture and owner bindingWeek 1
02Representative demand, workforce and planning sources→Signal binding, build logic and the plan baselineWeek 2
03Your planning calendar and the capacity leads it names→Assumption mapping, owner binding and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Demand, workforce and planning source assessment, then integration setupWeek 2
05Plans you would not want interrogated→Assumption cases and horizon-drift testingWeek 4
06What no forecast may promise→Staleness scoring, review routing, guardrails and approval controlsWeek 3
07A named capacity lead who approves the plan→Approval by the named capacity lead, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Bands are sized to the work behind them, so one week carries two rather than one being stretched.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Assumption discovery, owner binding and the automation boundaryW2Source integration and the capacity-and-demand baselineW3Plan building, staleness logic and approval controlsW4Evaluation suite, assumption cases and failure-mode testingW5Planning-model integration, pilot plans and targeted correctionsW6One planning horizon run under the capacity lead, then Agent Care handover
Reading the bandA band spans the weeks its own work is named for, and week five holds two of them.
At the end of W6Once the assumption record validates, Agent Care takes the agent on.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Operations AI agent
Build a capacity agent around the assumption nobody remembers typing.
Show us one capacity plan and the utilisation rate sitting inside it. Not the number people argue about. The number nobody can find, in a formula with no owner and no date, that the hiring decisions since have quietly followed.
