Strategy AI agent · Scenario modelling
Scenario Modelling AI Agent
Prise the assumptions out of the cells they hide in, give each one an owner and a date, and rank the handful that actually move the answer before anyone argues the central case.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Finance decides
- Owner-named
- After launch
- Agent Care
What this agent does
Builds the cases, never chooses the plan
In
- 01
A case is built, and every assumption inside it is lifted out of the formula and named.
- 02
An assumption changes, and the owner who set it and the date they set it move with it.
Reason
- 03
A range of cases opens, and not one is labelled expected, because a case is not a forecast.
- 04
A sensitivity run finishes, and the drivers that move the answer most are ranked before it is read.
- 05
A pair of drivers moves together, and neither may be flexed as though the other stood still.
Decide
- 06
An input goes stale, and the case resting on it is marked stale rather than quietly carried on.
- 07
A model is reopened a year later, and its version, provenance and purpose note are still attached.
Out
- 08
A plan is chosen, and that choice belongs to finance and the people accountable for it.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
Case building and sensitivity ranking belong to the agent. A named owner sets each assumption, and finance owns the plan chosen from the cases.
Example workflow
One case, assumption to publication
- 1Planning inputs receivedBudget models, driver files, actuals extracts or the planning system itself
- 2Case context assembledThe decision under test, the drivers it turns on, the sources behind them and the day each was refreshed
- 3Assumption register draftedThe assumption, its owner, its source and the range it may travel
- 4Controls appliedCorrelation checks, freshness checks, range checks and visibility confidence
No human action required
Stages 1 to 4 run unaided, and no plan is chosen at any of them — the agent only models, and the finance partner enters at the visibility gate.
Passes to the finance partner for release.
Adds a planning analyst read first.
Planning review
The case is held with its register, its gaps and the owners still to confirm.
Publish · Append assumption · Send to planning review
Published — by the finance partner
- 6Planning and model records updatedOnly where write access and records policy allow it
- 7Outcome evaluatedAssumption visibility, sensitivity coverage, analyst corrections and what review found
Corrections
Each analyst correction is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Choosing which case becomes the plan.
- Setting the value an assumption is modelled at.
- Declaring any case the expected outcome.
- Signing off a planning round for finance.
Automation boundary
Agent acts unaided
- ✓Lift each assumption out of the formulas into a named register.
- ✓Rank the drivers by the distance each one moves.
- ✓Flag the driver pairs that move together, never apart.
- ✓Mark a case stale the moment its source data stops being current.
No case is published and no plan is ever chosen except by a named person, on approval.
- Judging which of the cases is the likelier one.
- Telling the board that a scenario will happen.
- Owning an assumption on behalf of a person.
- Changes to the model, the register or the plan.
Example output
One assumption, annotated
This serves a strategy team whose model gets reopened by somebody else in a later planning round, so the owner, the version and the purpose note travel with every case.
Assumption record · single case
Illustrative example- Assumption
- Revenue growth rate, base driver
- Recorded as
- Set by the named owner, sourced and dated
- Case
- Downside case
- Evidence of record
- Planning driver file, 3 August 2026
- Confidence
- Held unpublished
- Held for
- The finance partner, by name
As received
Sourced from the driver file and the planning system — nothing behind those two shows here.
What the record holds
- Driver file
- Assumption owner note
- Prior-round model
Why nothing is predicted here
Which case actually occurs is not something this model claims to know.
What the score decides
Below the configured threshold a case picks up a planning read before the partner sees it.
Action
PublishAppend assumptionSend to planning reviewValue
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 assumption
From the owner who set it
Where the evidence is used
A scenario is not a forecast: this page shows the cases built and the assumptions under each, and it makes no claim about which of them will happen.
An assumption is a choice
Somebody chose that growth rate, and the register carries their name and the day beside it, not the formula on its own.
What was checked, and not found
No published benchmark exists for how often a planning assumption survives the round it was set in, so none is quoted here; and how any case compared with the year that followed is not something this page claims to know.
Build an evidence trail
The scenario, the assumption driving it 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.
Planning and budgeting
- Planning system
- budget models
- Driver files and case versions
Finance and actuals
- General ledger
- close reporting
- Actuals and variance history
Commercial and operations
- Pipeline
- capacity
- pricing
- Volume, price and cost drivers
Agent
Scenario and sensitivity modelling
- Reads the drivers
- Builds the cases
- Holds for the partner
Market and external inputs
- Index feeds
- research files
- Rate, index and demand assumptions
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six lenses between the model and the partner
Six lenses stacked in line, the last the sharpest. Whatever still resolves is drawn in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a case may stand
- L3
- Leaves the plan to a named person
- L4 – L5
- Keep the scenario and the assumption behind it
- L6
- Holds the model unpublished when signals degrade
How Nestack evaluates it
Evaluate the whole assembly — not only the case that comes out.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the case a planning meeting reads
- E1Final-output evaluationDid the register record every assumption the case actually turns on?
- E2Step-level evaluationDid the agent read the right driver file, the right version and the live actuals?
- E3Tool evaluationDid it read and write the correct model version and the correct case?
- E4Confidence calibrationDo low-visibility cases actually attract more planning corrections?
- E5Slice evaluationHow does performance change across specific case types?
- E6Business outcomeHow many cases needed a correction before the partner published?
Floor — the plan the company runs on
Failure modes
Where each failure originates in the agent
Seven failure modes, each fixed to the stage where it first bites.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- MF-03
Stale driver read
The driver values read are no longer the ones finance holds.
Stage gathers
The models, the drivers, the cases and the dates
02 · Reasoning
2 modes
- MF-04
Assumption left in the formula
A driver stays hard-coded and never reaches the register.
- MF-06
Case presented as expected
One case is read back as though it were the plan.
Stage proposes
The assumptions, their owners and the ranking
03 · Tool / write
2 modes
- MF-02
Unowned case passed forward
A case moves on with no owner named.
- MF-05
Coupled drivers flexed apart
Price and volume move as though unrelated.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- MF-01
Published, assumption unrecorded
The case shows a number but not the choice under it.
Stage returns
The case a partner signs and a planner reopens
05 · Change / Version
1 mode
- MF-07
Silent assumption drift
A refresh moves the driver while the case keeps the old one.
Stage tracks
Model, prompt, case rules and register fields
- Sev-1 · a plan chosen on a hidden driver
- Sev-2 · wrong driver reaches the case
- Sev-3 · source goes stale, case held back
Affected slices
Multi-year strategic cases absorb the corrections
A scenario-level assumption-visibility figure can read clean while multi-year strategic cases carry most of the rework. Nestack reports the correction rate by case type, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Multi-year strategic cases | 8.3% | 3.6× | Review | |
| Annual plan cases | 5.9% | 2.6× | Review | |
| Quarterly reforecast cases | 3.7% | 1.6× | Watch | |
| Steady-state base cases | 1.5% | 0.7× | Normal |
Bar: correction-rate lift vs. steady-state base-case baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
What a buried assumption costs
A cycle ends when the buried assumption is a standing case. That suite is what the next model published is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Correction rate rises on multi-year strategic cases.
- 02
Diagnose
The growth rate buried in a cell that three quarters of planning rested on is traced back until one cause is left standing.
- 03
Improve
Changes leave numbered, and the scenarios that forced them travel attached.
- 04
Verify
One scenario case still failing is enough to stop the whole release.
- 05
Learn
The case is kept, and the assumption rules are rewritten alongside it.
Learn → Detect
The return edge. The next case 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, case assembly, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Assumption-register and automation-boundary work.Week 1
- 02Planning, ledger and market sources.Week 1, Week 2
- 03Assumption-to-owner and sensitivity-coverage mapping.Week 1, Week 2
- 04Driver and actuals ingestion.Week 2
- 05Assumption, owner and source binding.Week 2, Week 3
- 06Visibility scoring and review routing.Week 3
- 07Finance partner release workflow.Week 3, Week 4
- 08Planning-system integration.Week 5
- 09Assumption and sensitivity cases.Week 4, Week 5
- 10Guardrails and publication controls.Week 4
- 11Scenario-trail instrumentation.Week 5, Week 6
- 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 tier | PilotOne round, one model | ProductionProduction planning workflow | AdvancedMultiple rounds / entities |
|---|---|---|---|
| Introduced at Pilot | |||
| Case assembly to your drivers | ✓ | ✓ | ✓ |
| Finance partner release | ✓ | ✓ | ✓ |
| Assumption-register baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by scenario | — | ✓ | ✓ |
| Partner sign-off workflow in your systems | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Planning-model integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-entity plans | — | — | ✓ |
| Cross-round case packs | — | — | ✓ |
| Large driver estates | — | — | ✓ |
| Multi-case version controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, model size, 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.
You bring
We build with it
01Your planning model and the drivers it turns on
→Driver mapping and assumption capture
Week 102Representative planning, actuals and market inputs
→Source binding, assumption logic and the register baseline
Week 203Your planning calendar and the owners it names
→Driver mapping, owner binding and the automation boundary
Week 104Access to relevant APIs, feeds or exports
→Planning, ledger and market source assessment, then integration setup
Week 205Models you would not want opened
→Sensitivity cases and the evaluation suite
Week 406What no scenario model may predict
→Visibility scoring, review routing, guardrails and release controls
Week 307A finance partner who owns the plan
→Release to the finance partner, 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
The fifth week doubles because two phases really do run together, not because the row needed filling.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Planning workflow discovery, driver mapping and the automation boundary
W2Source integration and the assumption-register baseline
W3Case assembly, sensitivity logic and release controls
W4Evaluation suite, sensitivity cases and failure-mode testing
W5Planning-system integration, pilot cases and targeted corrections
W6One planning round run under the finance partner, then Agent Care handover
- Reading the band
- Each bar covers only the weeks its own work is named for, and week five holds a pair that genuinely overlap.
- At the end of W6
- When the assumption record validates, Agent Care picks the agent up.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Strategy AI agent
Build a scenario agent on the assumptions your planning model keeps out of sight.
Show us one case and the assumptions under it. If the model that sets your plan cannot be reopened next year without its author sitting beside it, then it costs a rebuild every round. Choosing the plan stays with finance; the agent builds cases and ranks what moves them.
- Typical delivery
- 4–6 weeks
- Deployment
- Your planning model
- Finance decides
- Owner-named
- After launch
- Agent Care available
Nestack Agents · Scenario modelling
AGT-CS-08 · Agent Care available after launch