Propose markdowns from your own sales history and genuinely public data, freeze anything a live emergency declaration reaches, and hold every price for the pricing manager who releases it.
Ingest sales, cost, stock and calendar data from the retailer's own systems and genuinely public sources.
02
Normalise the fields, and carry every input forward with the feed it came from.
Reason
03
Estimate demand and propose a markdown or a price move inside the approved band.
04
Apply the pricing rules, bands and channel-parity requirements configured for the banner.
05
Check the provenance of each input, and reject anything a competitor could have supplied.
Decide
06
Freeze any SKU that a live emergency declaration reaches in a served geography.
07
Route every proposed price to the pricing manager who releases it.
Out
08
Retain the inputs, the rule, the proposal, the approver and the geographies published to.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
The agent proposes a price; the pricing manager releases it — and algorithmic pricing is now an antitrust question, not only a commercial one.
Example workflow
One price change, input to release
AgentHuman
1Price trigger receivedA markdown calendar, a stock position, a cost change or a rule review
2Inputs gatheredSales history, stock, cost, calendar and published list prices, each with its feed
3Price proposedOld price, new price, the rule that produced it, the channels and confidence
4Guardrails appliedProvenance checks, band checks, emergency-declaration checks, channel parity and confidence threshold
No human action required
Stages one to four run unaided and no price moves at any of them — the agent is proposing, and the pricing manager's lane opens at the confidence gate.
5DecisionBranches at the price guardrail
Inside the guardrail
Goes to the pricing manager to release.
Outside the guardrail
Adds a legal read first.
Pricing-manager approval
The change is held with its inputs, their provenance and the confidence.
Approve · Adjust · Send to legal review
Approved — released to publish▼
6Price systems updatedOnly where write access and approval policy allow it
7Change evaluatedMargin and sell-through, gate failures, channel divergence and post-release corrections
Rollbacks
Every pricing-manager adjustment is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Releasing any price to a live channel.
Approving a move outside the agreed band.
Onboarding a new price feed or data source.
Pricing on any input drawn from an identifiable shopper.
Automation boundaryAgent acts unaided
✓Estimate demand from the retailer's own sales history for the named owner.
✓Propose markdowns inside the approved band and queue.
✓Reconcile shelf, till.
✓Freeze a SKU when a legal gate fails, and hold it for approval.
Any write happens inside the boundaries agreed at implementation, never ahead of approval.
Wording and placement of an algorithmic-pricing disclosure.
Certifying a former price before a strike-through runs.
Accepting a vendor model or rule-set upgrade.
Remediation after a wrong price has been charged.
Example output
One price change, annotated
Everything the agent proposes is attached to the inputs it was drawn from.
Pricing output · single SKUIllustrative example
SKU
Proposed change
New price
Input provenance
Confidence
Personal data
Seasonal apparel line
Markdown inside the approved band for the clearance window
$34.00
Own sales history
93%
None used
As receivedTaken from the retailer's own systems and published list prices.
Inputs usedOwn sales historyStock and cost positionPublished list price
Why this priceIt sits inside the band the pricing manager approved — the move they weigh.
ActionApproveAdjustSend to legal review
What the score decidesBelow the configured threshold the change picks up a legal read before it reaches the pricing.
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 price changeFrom the retailer's own systems
03Proposal
Price from your own data
Draw on first-party sales, cost and stock, and the bands the pricing manager approved.
01Approved path
Move the price, keep the record
Routine markdowns inside the band arrive already worked out.
02Human review
Send review to the risky moves
Gate failures and low-confidence proposals are marked, so the pricing manager's read starts where exposure concentrates.
04Build an evidence trail
Each price keeps its rule, its inputs and the approver who released it.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Price and markdown optimisationRevionics · Blue Yonder Pricing Pricefx · PROS
An aggregate gate-failure rate can look settled while one cohort of price changes carries almost all of it. Nestack reports that rate by slice as a lift on the all-price-change.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Emergency geographies, personalised
5.4%
2.7×
Review
Strike-through in strict states
4.2%
2.1×
Review
Shared-engine concentrated categories
2.4%
1.2×
Watch
Single-channel, non-personalised
1.2%
0.6×
Normal
Bar: gate-failure lift vs. the all-price-change baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
A cycle is not closed by a fix
What closes a cycle is a case in the suite, not agreement about what went wrong That suite is what the following detection is measured against..
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Gate failures rise in one price cohort.
02Diagnose
Until the cause narrows to a single feed, rule or prompt, the pricing manager keeps reading the runs behind the failures.
03Improve
Each change is version-stamped and linked to the run that surfaced it.
04Verify
The release waits on the affected cases passing again.
05Learn
It becomes a permanent case and a change to the pricing guardrails.
Learn → DetectThe return edge. Detection next time runs against a longer suite than this one.
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, pricing workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Pricing workflow discovery and boundary definition.
02Price-engine and margin-source assessment.
03Rule, band and jurisdiction mapping and rule mapping.
04First-party sales, stock and cost ingestion.
05Proposal logic and input-provenance.
06Confidence scoring and gate-failure routing.
07Pricing-manager approval.
08Price-book, shelf and channel integration.
09Pricing regression cases.
10Guardrails and release controls.
11Price-history 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 banner, one channelProductionProduction price systemsAdvancedMultiple banners / markets
Introduced at Pilot
Proposals to your rules and bands✓✓✓
Pricing-manager approval✓✓✓
Price-integrity baseline✓✓✓
Introduced at Production
Reporting by category—✓✓
Approval workflow in your systems—✓✓
Approved write-back to price systems—✓✓
Price-engine integration—✓✓
Introduced at Advanced
Multi-banner rule sets——✓
Multi-stage pricing approvals——✓
High SKU and channel volume——✓
Enterprise pricing controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, transaction 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 price rules, bands and markdown calendar→Rule, band and jurisdiction mappingWeek 1
02Representative past price changes→Proposal baseline, elasticity and provenance bindingWeek 2
03The feeds you price from, and where each one comes from→Rule and band mapping, and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Price-engine, POS and channel assessment, then integration setupWeek 2
05Prices that should not have gone live→Pricing cases and failure-mode testingWeek 4
06Which prices may never move unattended→Guardrail bands, release routing and controlsWeek 3
07A named pricing manager to release prices→Pricing-manager approval workflow, 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
Phases occupy real weeks, and evaluation overlaps launch in the fifth rather than being stretched.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Pricing workflow discovery, rule mapping and the automation boundaryW2Cost and competitor-public feeds in placeW3Proposal workflow, confidence logic and release controlsW4Pricing cases and release guardrailsW5Channel integration, pilot price changes and targeted correctionsW6A live pricing cycle released by the pricing manager, then handover
Reading the bandEach bar spans only its named weeks; the overlap in week 5 is real work.
At the end of W6A verified cycle in production, then monitoring sits with Agent Care.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Retail AI agent
Build a pricing agent that can show where every input came from.
Show us the feeds you price from, the bands you work inside and who releases a change. A price that has already been charged cannot be unwound by a refund alone, so we set the provenance, emergency and disclosure gates before anything moves.
