Travel & Hospitality AI agent · Dynamic pricing
Dynamic-Pricing & Revenue-Management AI Agent
Propose rate moves from your own demand data alone, show the inputs behind each one, and hold every move for the revenue manager who releases it and owns the decision.
- Typical delivery
- 4–6 weeks
- Deployment
- Your stack
- Named manager
- First-party
- After launch
- Agent Care
What this agent does
A proposal, and a manager who decides it
In
- 01
Ingestion of your own demand, pace and inventory from supported revenue, property and channel systems.
- 02
Normalisation of rate structures and segments, so every input carries the system it was read from.
Reason
- 03
A proposed move for one date and one segment, with the inputs that produced it listed beside it.
- 04
Governors you set — a maximum rise and a maximum fall, applied symmetrically in both directions.
- 05
Provenance checks at runtime, so an input outside the permitted set stops a proposal rather than shaping it.
Decide
- 06
Disclosure where a price is set from a guest's own data, in the form the state requiring it prescribes.
- 07
A hold on every move for the revenue manager named on the date, whose decision is the pricing decision.
Out
- 08
Retention of the inputs, the proposal, the manager's adjustments and the move actually released.
- 09
Execution of write actions only inside the approval boundaries agreed during implementation.
Product statement
The agent proposes a move; the revenue manager decides the rate, and the operator stays the one setting its own price.
Example workflow
One date, demand to release
- 1Date and segment receivedRevenue system, property system, channel manager or booking feed
- 2Inputs assembledYour own pace, inventory, length of stay and published calendars, each with its source
- 3Move proposedRate move, its inputs and confidence
- 4Controls appliedProvenance checks, symmetric governors, personalised-price disclosure and confidence threshold
No human action required
Stages 1 to 4 run unaided, and no rate changes at any of them — the agent is proposing, and the manager's lane opens at the confidence gate.
Goes to the revenue manager to release.
Adds a commercial-lead read first.
Manager releases
The move is held with its inputs, its flagged lines and the confidence.
Release · Adjust · Send to commercial review
Released — the manager's decision
- 6Revenue systems updatedOnly where write access and approval policy allow it
- 7Outcome evaluatedAdjustment distance, flagged-input outcomes, realised demand and post-release corrections
Adjustments
Every manager adjustment is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required
8 items
- Publishing a rate to a channel or a distributor.
- Setting the bands the copilot must price inside.
- Reading a rival's non-public rate or occupancy.
- Pricing from a guest's personal data or device.
Automation boundary
Agent acts unaided
- ✓Propose a move for one date and segment from your own demand.
- ✓Show every input that produced the proposal, with its source.
- ✓Apply the maximum rise and fall the manager configured.
- ✓Flag what a person must weigh, and hold the proposal.
Any write happens inside the boundaries agreed at implementation, never ahead of approval.
- Holding rate against a rival, or matching what one did.
- Undercutting a channel a parity term still binds.
- Setting a floor, a ceiling or a market-wide target.
- Changes to input sources, governors or release rules.
Example output
One rate move, annotated
Everything the agent proposes is attached to the inputs it was drawn from.
Rate-move output · single date
Illustrative example- Date
- Midweek, corporate
- Proposed move
- Held for the revenue manager named on the date
- Change proposed
- +3.5%
- Source of record
- Own booking pace
- Confidence
- 88%
- Attribution
- Property and revenue team
As received
Taken from your own pace and inventory on file — nothing on this side is written by the agent.
Inputs used
- Own booking pace
- Own inventory on hand
- Published event calendar
Why this move
It reads your own demand, not another property's rate — the line the manager weighs.
What the score decides
Below the configured threshold the move picks up a commercial read before it.
Action
ReleaseAdjustSend to commercial 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 date
From your own systems
Propose from your own data
Draw on the pace, inventory and calendars you already hold; third-party history used in training is aged and drawn from settled business.
Your own data, and a person
Routine dates arrive with a move already proposed and already sourced.
Report adjustment, not adoption
The page reports how often a manager changed a move, because an acceptance rate is a figure a plaintiff can use, not a quality signal.
Build an evidence trail
The rate move, the inputs behind it and the manager who released it stay on the date record.
Integrations
Typical integrations
Five system groups connect to the same agent. Which of them are in scope is decided in discovery.
Revenue management
- IDeaS
- Duetto
- Atomize
- Flyr
- Cloudbeds
Property management
- Opera Cloud
- Mews
- Infor HMS
- Apaleo
Distribution
- SynXis
- Derbysoft
- Channel manager
- CRS
Agent
Dynamic pricing & revenue management
- Reads your data
- Proposes the move
- Holds for release
Business intelligence
- Snowflake
- BigQuery
- Power BI
- Looker
Observability & evaluation
- OpenTelemetry
- Langfuse
- Supported monitoring/evaluation sources
Integration availability depends on the client's existing systems and API access.
Agent controls
Six layers between the model and your rate
The controls sit inside one another. What none of them catches is set out below.
L6 · Outermost — last line of defence
Inward → L1 · closest to the model
- L1 – L2
- Test whether a move may stand
- L3
- Puts the release in a manager's hands
- L4 – L5
- Keep the move and the inputs behind it
- L6
- Narrows to demand reporting when signals degrade
How Nestack evaluates it
Evaluate the pricing workflow — not only the number at the end.
Coverage runs the whole depth of the workflow, and every layer is cut by slice.
Surface — the rate the market sees
- E1Final-output evaluationDid every input behind the move come from a permitted source?
- E2Step-level evaluationDid the agent use the right dates, governors and segment configuration?
- E3Tool evaluationDid it read and write the correct date and the correct rate plan?
- E4Confidence calibrationDo low-confidence moves actually attract more manager adjustments?
- E5Slice evaluationHow does performance change across specific date and segment groups?
- E6Business outcomeHow many moves needed an adjustment or a correction after release?
Floor — the price the operator answers for
Failure modes
Where each failure originates in the agent
Seven ways a rate move goes wrong, by stage.
Agent lifecycle
Direction of processing →
01 · Retrieval
1 mode
- CU-03
Input outside provenance
A rate input arrives from a source the boundary excludes.
Stage gathers
Your own pace, inventory and public calendars
02 · Reasoning
2 modes
- CU-04
Coordination-shaped output
A move is framed as what the market ought to hold.
- CU-06
Governor breach
A proposal exceeds the rise or fall the manager set.
Stage proposes
The move the manager reads and releases
03 · Tool / write
2 modes
- CU-02
Move published unreleased
A rate reaches a channel with no manager behind it.
- CU-05
Personalised price unlabelled
A guest-specific price is shown without its disclosure.
Stage writes
Only where write access and approval policy allow it
04 · Output
1 mode
- CU-01
Rival rate in the loop
A rival's non-public rate reaches a runtime input.
Stage returns
The rate the manager releases and guests pay
05 · Change / Version
1 mode
- CU-07
Silent governor regression
A model or rule change widens what the agent will propose.
Stage tracks
Model, prompt, governors and input-source config
- Sev-1 · a rate moves without release
- Sev-2 · a wrong move reaches a channel
- Sev-3 · input degrades, move routes to review
Affected slices
Overall quality can hide one bad cohort
An aggregate adjustment rate and the adjustment rate for one slice are different measurements The cohorts that carry it are named, not averaged away Nestack reports it by slice rather than in aggregate..
Slice performance — reported separately, not only in aggregate
Illustrative example| Slice | Failure rate | Lift | Lift vs. threshold | Status |
|---|---|---|---|---|
| Compression and event dates | 8.0% | 3.7× | Review | |
| Group and contract blocks | 4.5% | 2.1× | Review | |
| Personalised and member rates | 3.2% | 1.5× | Watch | |
| Stable midweek dates | 1.7% | 0.8× | Normal |
Bar: manager-adjustment-rate lift vs. stable-midweek baseline · scale 0–4.0× · tick marks the 2.0× review threshold
2 of 4 slices over threshold
Evidence-linked improvement
A cycle ends in the regression suite
The cycle ends when a case exists in the suite, not when the miss was discussed. That suite is what the next rate move released is measured against.
Improvement cycle · five stages
Switchback — the path turns at Improve and returns at Learn
- 01
Detect
Manager-adjustment rate rises in a date slice.
- 02
Diagnose
If the rise sits in one slice, the inputs behind those dates are read first, before any rule is touched.
- 03
Improve
Changes carry a version and the moves that prompted them.
- 04
Verify
Release is held until the affected cases pass.
- 05
Learn
The case is kept permanently, and the pricing rules move with it.
Learn → Detect
The return edge. The next detection runs 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, pricing workflow, evaluation, integration, then production validation and handover.
Workstream
Week 1Week 2Week 3Week 4Week 5Week 6
- 01Pricing workflow discovery and boundary definition.Week 1
- 02Revenue and property source assessment.Week 1, Week 2
- 03Governor, segment and input-provenance rule mapping.Week 1, Week 2
- 04Demand-input ingestion and normalisation.Week 2
- 05Proposal logic and input binding.Week 2, Week 3
- 06Confidence scoring and flag routing.Week 3
- 07Revenue-manager release workflow.Week 3, Week 4
- 08Revenue-system and channel integration.Week 5
- 09Input-provenance cases.Week 4, Week 5
- 10Guardrails and release controls.Week 4
- 11Rate-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 property, one market | ProductionProduction revenue systems | AdvancedMultiple properties / brands |
|---|---|---|---|
| Introduced at Pilot | |||
| Proposals from your own data | ✓ | ✓ | ✓ |
| Manager release | ✓ | ✓ | ✓ |
| Move-quality baseline | ✓ | ✓ | ✓ |
| Introduced at Production | |||
| Reporting by segment and date | — | ✓ | ✓ |
| Approval workflow in your systems | — | ✓ | ✓ |
| Approved write-back | — | ✓ | ✓ |
| Revenue-system integration | — | ✓ | ✓ |
| Introduced at Advanced | |||
| Multi-market pricing rules | — | — | ✓ |
| Multi-stage commercial approvals | — | — | ✓ |
| High date and segment volume | — | — | ✓ |
| Multi-property pricing controls | — | — | ✓ |
| Build price | From $5,000 | From $8,000 | Custom quote |
- Final build price
- Confirmed after discovery based on integrations, workflow complexity, transaction 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 rate structures and segment definitions
→Demand-input ingestion and source mapping
Week 102Representative dates you have already priced
→Proposal baseline, segment extraction and input binding
Week 203Your governors and the bands you price inside
→Governor, segment and input-provenance rule mapping
Week 104Access to relevant APIs, feeds or exports
→Revenue, property and channel assessment, then integration setup
Week 205Moves you would not want published
→Provenance cases and failure-mode testing
Week 406What no model may take as an input
→Confidence scoring, flag routing, guardrails and release controls
Week 307Named revenue managers to release moves
→Release workflow, 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 bands follow the actual work, which is why the fifth week doubles rather than pads.
Phase
W1
W2
W3
W4
W5
W6
- DiscoveryW1
- BuildW2 – W3
- EvaluateW4 – W5
- Pilot & LaunchW5 – W6
Week focus
W1Pricing workflow discovery, governor mapping and the automation boundary
W2Source integration and the proposal baseline
W3Pricing workflow, confidence logic and release controls
W4Provenance cases, disclosure checks and failure-mode testing
W5Revenue-system integration, pilot dates and targeted corrections
W6One pricing period run under revenue management, then handover
- Reading the band
- Every bar covers the weeks its own work runs and no others. The fifth week genuinely doubles up.
- At the end of W6
- The period closes validation and Agent Care owns the running agent.
- Duration
- Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Travel & Hospitality AI agent
Build a revenue-management copilot on your own data and a manager's signature.
Show us where each pricing input comes from and who releases a rate. Get that boundary wrong and the cost is not one bad night — a federal appeals court has held that keeping final authority with a person does not answer an agreement claim, and that a high acceptance rate supports the inference, so the adoption slide in your board pack becomes the exhibit. We map the inputs, set the governors and name the manager who decides.
- Typical delivery
- 4–6 weeks
- Deployment
- Your own data
- Named manager
- First-party
- After launch
- Agent Care available
Nestack Agents · Dynamic pricing
AGT-TH-09 · Agent Care available after launch