Procurement AI agent · Category management
Category Management AI Agent
State the bets a category plan is making — about the market, the supplier, the specification — date each one, give it an owner, and leave every revision to a named category manager.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Named manager
- Bets on record
- After launch
- Agent Care
What this agent does
Tests the plan, never sets the strategy
In
- 01
A plan is set, and each assumption it stands on is written out beside it with an owner and a date.
- 02
An assumption moves, and the plans resting on it are marked stale rather than left reading as current.
Reason
- 03
A plan is inherited, and any bet in it with no living owner is raised as an orphan instead of carried on.
- 04
A lever is listed, and a plan that lists consolidation, re-specification and demand work alike says so.
- 05
A market signal arrives, and it is put against the assumption it bears on the day that signal lands.
Decide
- 06
A saving is claimed, and the baseline behind the claim is shown, or the claim does not travel onward.
- 07
A plan is copied out of another category, and the assumptions that did not travel with it are named.
Out
- 08
A bet is put under test, and what the plan would become if that bet failed is set out alongside it.
- 09
Execute write actions only inside the approval boundaries agreed during implementation.
Product statement
Assumption capture, staleness marking and signal watch belong to the agent. The strategy, the lever, the spend and any claim that a market has changed belong to a named category manager.
Example workflow
One category plan, bets to review
- 1Plan and category receivedCategory plan, spend cut, supplier list, contract register or the last review pack
- 2Assumptions lifted outThe market, supply, specification and demand bets the plan rests on, each with an owner and a date
- 3Standing testedThe assumption, the signal against it, whether it still holds and confidence
- 4Controls appliedAssumption-coverage checks, signal-age checks, owner checks and confidence threshold
No human action required
Stages 1 to 4 run unaided, and no plan is revised at any of them — the agent is testing, and the category manager lane opens at the confidence gate.
Goes to the category manager to accept.
Adds a procurement lead read first.
Category manager review
The plan is held with its assumptions, the signals against them and the confidence.
Accept · Amend · Send to category review
Accepted — by the category manager
- 6Plan and category records updatedOnly where write access and records policy allow it
- 7Outcome evaluatedAssumption coverage, staleness caught, manager amendments and what review found
Amendments
Each amendment made in review is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Setting the strategy a category is bought under.
- Choosing which lever a category is taken to.
- Committing spend against a plan.
- Declaring that a market has changed.
Automation boundary
Agent acts unaided
- ✓Write each assumption down with an owner and a date.
- ✓Mark a plan stale when the assumption beneath it stops holding.
- ✓Watch the market signals beneath a standing plan.
- ✓Show what the plan would look like if one of its stated bets failed.
Nothing revises a category plan except a named category manager, inside the agreed boundaries.
- Judging whether a category can be planned at all.
- Telling a board that a plan is still sound.
- Deciding which supplier a category consolidates on.
- Changes to the plan, the levers or the assumptions.
Example output
One category assumption, annotated
This serves a procurement team who may have to explain years later why a category was bought the way it was; below is one assumption exactly as the agent leaves it.
Assumption output · single category plan
Illustrative example- Category
- Packaging, regional plan
- Assumption as written
- The regional supply base stays competitive
- Stated as
- Written as a fact, not a bet
- Standing
- Signal dated 3 August 2026
- Confidence
- Held unaccepted
- Held for
- The category manager, by name
As received
Taken from the plan as written and the signals as they arrived — nothing on this side is judged by the agent.
Evidence used
- Plan text
- Supplier signal
- Prior review pack
Why this is a bet
Whether this bet holds is a judgement the category manager makes.
What the score decides
Below the configured threshold an assumption gets a lead read before the manager sees it.
Action
AcceptAmendSend to category 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 category plan
From the plan that carries it
Where the bet is tested
The classification deciding what a category even contains is the spend analysis agent; this one starts after that line is drawn, and its subject is the assumption a plan rests on.
A plan is a set of bets
Say a market will stay competitive and you have made a prediction; write it into a plan as a fact and nobody goes back to test it.
What was checked, and not found
No category plan reviewed states its own expiry, and none carries a mechanism for withdrawal, so a plan whose premise has gone is reported as still in force rather than quietly retired.
Build an evidence trail
The plan, the assumption under it and the manager 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.
Category and spend data
- Spend cubes
- category hierarchies
- Category spend and volumes
Market and price data
- Index series
- price feeds
- Input cost and capacity moves
Supplier and contract data
- Supplier master
- contract register
- Terms, expiries and dependencies
Agent
Category management and planning
- Reads the plan
- Tests the bets
- Holds for the manager
Planning and reporting
- Coupa
- Ariba
- Ivalua
- Jaggaer
- Category plans and review calendars
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six proofs between the model and the plan
Six proofs run in sequence, the last the hardest. What survives is drawn in the map below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a bet may stand
- L3
- Leaves the revision to a named manager
- L4 – L5
- Keep the plan and the bet under it
- L6
- Falls back to the standing plan when signals degrade
How Nestack evaluates it
Evaluate the whole test — not only the register that comes out.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the plan a category review reads
- E1Final-output evaluationDid the register record the assumption the plan was actually built on?
- E2Step-level evaluationDid the agent read the right plan, the right period and the live signals?
- E3Tool evaluationDid it read and write the correct plan and the correct assumption?
- E4Confidence calibrationDo low-confidence assumptions actually attract more manager amendments?
- E5Slice evaluationHow does performance change across individual category plans?
- E6Business outcomeHow many assumptions needed an amendment before the manager accepted?
Floor — the plan a budget owner answers for
Failure modes
Where each failure originates in the agent
Seven failure modes, each shown at the stage where it first surfaces.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- OQ-03
Stale market signal read
The signal read is not the one now published.
Stage gathers
The plans, the bets, the signals and the owners
02 · Reasoning
2 modes
- OQ-04
Bet asserted as a fact
A prediction is recorded with no bet behind it.
- OQ-06
Retired plan read as live
A withdrawn plan is worked as the current one.
Stage proposes
The assumption, the signal and the owner
03 · Tool / write
2 modes
- OQ-02
Stale assumption passed on
A dead bet moves on without the lead read.
- OQ-05
Bet bound to the wrong plan
The assumption is filed against another category.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- OQ-01
Accepted, owner unrecorded
The register shows a bet but not who holds it.
Stage returns
The plan a category review and a board read
05 · Change / Version
1 mode
- OQ-07
Silent assumption drift
A bet weakens while the stored plan keeps the old one.
Stage tracks
Model, prompt, planning rules and signal dates
- Sev-1 · a plan revised on no assumption
- Sev-2 · a dead bet reaches a category review
- Sev-3 · signal degrades, plan held stale
Affected slices
Inherited plans absorb the amendments
A category-level assumption figure can read clean while inherited category plans carry most of the amending. Nestack reports the amendment rate by slice, not only in total.
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Inherited category plans | 7.9% | 3.7× | Review | |
| Single-source categories | 5.6% | 2.6× | Review | |
| Volatile input markets | 3.5% | 1.6× | Watch | |
| Established stable categories | 1.5% | 0.7× | Normal |
Bar: amendment-rate lift vs. established-category baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
What a dead assumption costs
The loop ends when the assumption nobody stated is a standing case. That suite is what the next plan published is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Amendment rate rises on inherited category plans.
- 02
Diagnose
The category plan built on a supply assumption that stopped being true two quarters ago, still being executed because no plan carries an expiry, is worked backwards until one cause stands.
- 03
Improve
The change goes out numbered, and the category plans behind it travel attached.
- 04
Verify
A single red category case is enough to stop the release.
- 05
Learn
It is retained permanently, and the planning rules travel alongside it.
Learn → Detect
The return edge. The next plan 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, assumption logic, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Category-assumption discovery and boundary setting.Week 1
- 02Spend, market and contract source review.Week 1, Week 2
- 03Assumption-to-signal and category-coverage mapping.Week 1, Week 2
- 04Plan ingestion and assumption extraction.Week 2
- 05Assumption logic and owner binding.Week 2, Week 3
- 06Confidence scoring and review routing.Week 3
- 07Category manager review workflow.Week 3, Week 4
- 08Market-signal integration.Week 5
- 09Assumption and coverage cases.Week 4, Week 5
- 10Guardrails and revision controls.Week 4
- 11Plan-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 category, one cycle | ProductionProduction planning workflow | AdvancedMultiple categories / regions |
|---|---|---|---|
| Introduced at Pilot | |||
| Assumption capture to your plans | ✓ | ✓ | ✓ |
| Category manager acceptance | ✓ | ✓ | ✓ |
| Category-structure baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by category owner | — | ✓ | ✓ |
| Category review workflow in your systems | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Market-signal integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Cross-region assumption sets | — | — | ✓ |
| Multi-category plan packs | — | — | ✓ |
| Large plan portfolios | — | — | ✓ |
| Multi-category assumption controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, plan 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.
You bring
We build with it
01Your live categories and the plans each is bought under
→Assumption capture and register versioning
Week 102Representative category plans and review packs
→Signal binding, staleness logic and the assumption baseline
Week 203Your planning calendar and the managers it names
→Assumption mapping, owner binding and the automation boundary
Week 104Access to relevant APIs, feeds or exports
→Spend, market and contract source assessment, then integration setup
Week 205Plans you would not want interrogated
→Assumption cases and the drift evaluation
Week 406What no category plan may promise
→Confidence scoring, review routing, guardrails and release controls
Week 307A named category manager who accepts the register
→Release to the category manager, 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 each one, so a week carries two rather than one being stretched.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Category discovery, assumption mapping and the automation boundary
W2Spend, market and contract integration and the assumption baseline
W3Staleness logic, confidence scoring and release controls
W4Evaluation suite, assumption cases and failure-mode testing
W5Planning integration, pilot registers and targeted corrections
W6One planning cycle run under the category manager, then Agent Care handover
- Reading the band
- Each bar covers only the weeks its own work is named for, and week five is shared by design.
- At the end of W6
- When the category 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 · Procurement AI agent
Build a category management agent around the bets your last plan never wrote down.
Show us one category plan in flight and the assumptions under it. If a bet in that plan has gone untested for over a cycle, then the plan is costing you the lever nobody looked at. We will map the assumptions, set the automation boundary and name what stays with the manager.
- Typical delivery
- 4–6 weeks
- Deployment
- Your categories and plans
- Named manager
- Bets on record
- After launch
- Agent Care available
Nestack Agents · Category management
AGT-PR-09 · Agent Care available after launch