Main site

Operations AI agent · Capacity planning

Capacity Planning & Forecasting AI Agent

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.

Typical delivery
4–6 weeks
Deployment
Your stack
Capacity lead
Assumption-led
After launch
Agent Care

What this agent does

Builds the plan, never sets the headcount

In

  1. 01

    A horizon is set, and the demand signal, the hiring lead time and the shift pattern are held apart.

  2. 02

    An assumption changes, and the plans standing on it are listed before anyone asks which they were.

Reason

  1. 03

    A utilisation rate sits inside a formula, and it is lifted out as a named line in the register.

  2. 04

    A plan is built, and each assumption under it carries the person who set it and the day they did.

  3. 05

    A source ages past its term, and the plan leaning on it goes amber rather than carrying quietly on.

Decide

  1. 06

    A downside case is drawn, and it is labelled a case and dated, so forwarding it cannot promote it.

  2. 07

    A resource pool turns up in two plans, and the double count is reported rather than netted away.

Out

  1. 08

    An assumption moves, and what shifts in the plan is shown beside what stays exactly where it was.

  2. 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

  1. 1Planning inputs receivedDemand signals, attrition history, shift patterns, hiring lead times or the last approved plan
  2. 2Horizon set and assumptions registeredThe pools counted in, the horizon each input is held at, and the day each registered assumption was set
  3. 3Required capacity derivedThe capacity asked for, the register under it, what moves if one assumption moves and confidence
  4. 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

  1. 6Planning and workforce records updatedOnly where write access and records policy allow it
  2. 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 required

8 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 boundary

    Agent 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 pool

Illustrative example
Pool
Second-line support, one region
Recorded as
Assumptions lifted, one unowned
Horizon
Quarterly, rolling
Evidence of record
Demand extract, 3 August 2026
Confidence
Held unapproved
Held for
The capacity lead, by name

As received

Built out of the demand extract and the register on file — nothing past those two is claimed.

What the record holds

  • Demand extract
  • Attrition history
  • Assumption register

Why it is held

One assumption sitting under this plan still has no owner recorded.

What the score decides

Below the configured threshold a plan gets a planner read before the lead sees it.

Action

ApproveAmend assumptionSend to planning review

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every plan

From 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.

04

Build 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 systems

    • Workday
    • SuccessFactors
    • UKG
    • Headcount, roles and attrition history

  • Demand signals

    • Contact centre
    • ticketing
    • The arrival pattern planned for

  • Planning and modelling

    • Anaplan
    • 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 patterns

    • Greenhouse
    • Lever
    • rosters
    • Open roles and the lead time on each

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six baffles between the model and the plan

Six baffles in one channel, the last the deepest. What carries is set out in the map below.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeFall back to the flat horizon and hold the plan when evaluation or production signals degrade.Roll back
L5Version monitoringTrack model, prompt and assumption rules, and note the version each plan was built under.Track
L4TraceabilityRecord each plan, the assumptions under it, the owner of each and every read of the file.Record
L3Lead approvalHold the plan for a named capacity lead; the hold governs approval, not whether the headcount is right.Gate
L2Assumption guardrailsTest each plan against its registered assumptions, and return one whose input moved underneath it.Restrict
L1Confidence thresholdsRoute a plan carrying a stale or unowned assumption to a planner read before the lead sees it.Require review
Model corePlan built — the horizon, the register, what moves if one assumption moves and confidence
L1 – L2
Test whether a plan may stand
L3
Leaves the approval to a named capacity lead
L4 – L5
Keep the plan and the assumption behind it
L6
Falls back to the flat horizon when signals degrade

How Nestack evaluates it

Evaluate the whole build — not only the headcount that comes out of it.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the plan a hiring decision rests on

  1. E1Final-output evaluationDid the plan record the assumptions it was actually built on?
  2. E2Step-level evaluationDid the agent read the right signal, the right period and the live register?
  3. E3Tool evaluationDid it read and write the correct pool and the correct horizon?
  4. E4Confidence calibrationDo low-confidence plans actually attract more lead corrections?
  5. E5Slice evaluationHow does performance change across specific resource pools?
  6. E6Business outcomeHow many plans needed a correction before the lead approved?

Floor — the headcount a plan asks for

Failure modes

Where each failure originates in the agent

Seven failure modes, each placed where it first shows in the plan.

Agent lifecycle

Direction of processing →

  1. 01 · Retrieval

    1 mode

    • MZ-03

      Stale demand signal read

      The signal read is not the one now published.

    Stage gathers

    The signals, the pools, the periods and the plans

  2. 02 · Reasoning

    2 modes

    • MZ-04

      Horizons averaged together

      A weekly signal is flattened into a quarter.

    • MZ-06

      Assumption buried in a formula

      A rate inside a cell never reaches the register.

    Stage proposes

    The horizon, the register and what moves

  3. 03 · Tool / write

    2 modes

    • MZ-02

      Thin plan passed forward

      A plan moves on without the planner read.

    • MZ-05

      Pool counted in two plans

      The same people are planned for twice.

    Stage writes

    Only where write access and approval policy allow it

  4. 04 · Output

    1 mode

    • MZ-01

      Approved, assumption unowned

      The owner of record for an assumption has left.

    Stage returns

    The plan a lead approves and a team hires to

  5. 05 · Change / Version

    1 mode

    • MZ-07

      Case circulated as the plan

      A dated downside case is recruited against as approved.

    Stage tracks

    Model, prompt, horizon rules and source dates

  • Sev-1 · a plan approved on no assumption
  • Sev-2 · a stale plan reaches the hiring cycle
  • Sev-3 · signal degrades, plan held back
See the complete Operations failure-mode catalogue

Affected slices

New pools carry most of the re-planning

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 aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
Newly created pools7.2%3.7×Review
Pools shared across teams5.1%2.6×Review
Seasonal demand pools3.1%1.6×Watch
Steady long-running pools1.3%0.7×Normal

Bar: correction-rate lift vs. steady-pool baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 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 stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Correction rate rises on newly created pools.

  2. 02

    Diagnose

    The utilisation rate typed into a cell once and carried through every quarter since is taken apart until one cause is left standing.

  3. 03

    Improve

    The change goes out numbered, and the plans that forced it travel attached.

  4. 04

    Verify

    A single red plan case is enough to stop the release.

  5. 05

    Learn

    It is retained permanently, and the assumption rules travel with it.

  6. Learn → Detect

    The 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.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Assumption-register and automation-boundary mapping.Week 1
  2. 02Demand, workforce and planning sources.Week 1, Week 2
  3. 03Signal-to-plan and assumption-ownership mapping.Week 1, Week 2
  4. 04Demand-signal ingestion.Week 2
  5. 05Assumption, owner and horizon binding.Week 2, Week 3
  6. 06Staleness scoring and review routing.Week 3
  7. 07Lead approval workflow.Week 3, Week 4
  8. 08Planning-model integration.Week 5
  9. 09Assumption and horizon cases.Week 4, Week 5
  10. 10Guardrails and revision controls.Week 4
  11. 11Plan-trail instrumentation.Week 5, Week 6
  12. 12Deployment, documentation and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final 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 price
Confirmed after discovery based on integrations, workflow complexity, pool volume, approval controls and deployment requirements.
Separate from build
Build 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.

  1. 01Your live resource pools and the assumptions each is planned on

    Assumption capture and owner binding

    Week 1

  2. 02Representative demand, workforce and planning sources

    Signal binding, build logic and the plan baseline

    Week 2

  3. 03Your planning calendar and the capacity leads it names

    Assumption mapping, owner binding and the automation boundary

    Week 1

  4. 04Access to relevant APIs, feeds or exports

    Demand, workforce and planning source assessment, then integration setup

    Week 2

  5. 05Plans you would not want interrogated

    Assumption cases and horizon-drift testing

    Week 4

  6. 06What no forecast may promise

    Staleness scoring, review routing, guardrails and approval controls

    Week 3

  7. 07A named capacity lead who approves the plan

    Approval by the named capacity lead, then pilot and production validation

    Weeks 5–6

Nothing else is required

Deployment, 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.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Assumption discovery, owner binding and the automation boundary

W2Source integration and the capacity-and-demand baseline

W3Plan building, staleness logic and approval controls

W4Evaluation suite, assumption cases and failure-mode testing

W5Planning-model integration, pilot plans and targeted corrections

W6One planning horizon run under the capacity lead, then Agent Care handover

Reading the band
A band spans the weeks its own work is named for, and week five holds two of them.
At the end of W6
Once the assumption record validates, Agent Care takes the agent on.
Duration
Six-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.

Typical delivery
4–6 weeks
Deployment
Your resource pools
Capacity lead
Assumption-led
After launch
Agent Care available

Nestack Agents · Capacity planning

AGT-OP-10 · Agent Care available after launch

Build a capacity agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your capacity

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.