Install
$ agentstack add skill-asgard-ai-platform-skills-algo-price-dynamic ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Dynamic Pricing
Overview
Dynamic pricing adjusts prices in real-time based on demand signals, time, inventory, and competitive conditions. Common in airlines, hotels, ride-sharing, and e-commerce. Objective: maximize revenue (or profit) subject to capacity/inventory constraints.
When to Use
Trigger conditions:
- Pricing perishable inventory (hotel rooms, airline seats, event tickets)
- Implementing demand-responsive pricing for e-commerce
- Building surge pricing or time-based pricing systems
When NOT to use:
- For one-time pricing decisions (use Van Westendorp or conjoint)
- When price changes are impractical (regulated markets, long-term contracts)
Algorithm
IRON LAW: Dynamic Pricing Requires REAL-TIME Data
Stale data produces prices optimal for PAST conditions, not current ones.
Three data streams must be current:
1. Demand signal (bookings, searches, cart additions)
2. Inventory/capacity status
3. Competitive prices (where applicable)
Update frequency: minutes for ride-sharing, hours for hotels, daily for retail.
Phase 1: Input Validation
Collect: current demand indicators, remaining inventory/capacity, time until expiration/event, competitor prices, price floor/ceiling constraints. Gate: Real-time data feeds connected, business rules defined.
Phase 2: Core Algorithm
Rule-based: If demand > threshold, increase price by X%. Tiered rules by inventory level.
Demand-curve based: 1. Estimate demand curve at current conditions. 2. Find price that maximizes revenue = P × Q(P). 3. Apply inventory constraint: if capacity is scarce, price up; if excess, price down.
ML-based: Train model to predict demand at each price point given context features. Optimize over predicted demand curve.
Phase 3: Verification
Monitor: revenue per unit, booking pace, customer complaints, competitive position. A/B test new pricing rules. Gate: Revenue improved without significant volume loss or customer backlash.
Phase 4: Output
Return recommended price with reasoning and expected impact.
Output Format
{
"recommended_price": 1200,
"current_price": 999,
"reasoning": {"demand_signal": "high", "inventory_remaining_pct": 15, "competitor_avg": 1100},
"expected_impact": {"revenue_change_pct": 18, "volume_change_pct": -5},
"metadata": {"strategy": "demand-curve", "update_frequency": "hourly"}
}
Examples
Sample I/O
Input: Hotel room, 3 days until date, 85% occupancy, average competitor price $150 Expected: Price above competitor ($160-170) due to high occupancy, short time horizon.
Edge Cases
| Input | Expected | Why | |-------|----------|-----| | Zero demand | Drop to floor price | Stimulate demand, recover some revenue | | Last unit available | Price near ceiling | Scarcity maximizes willingness to pay | | Competitor flash sale | Don't auto-match if unnecessary | Avoid price war; assess if your product differentiates |
Gotchas
- Customer fairness perception: Visible price discrimination (same product, different prices for different users) generates backlash. Segment by time, channel, or bundle — not by individual.
- Price war spiraling: Automated competitive pricing can create a race to the bottom. Set absolute floors and rate-of-change limits.
- Demand cannibalization: If customers learn prices drop later, they wait. This is the "strategic customer" problem — don't train customers to delay.
- Regulatory risk: Dynamic pricing may violate anti-gouging laws during emergencies. Build in legal constraint rules.
- A/B testing bias: Testing different prices creates revenue measurement challenges. The control group at the "wrong" price loses money by design.
References
- For revenue management models (airline/hotel), see
references/revenue-management.md - For fairness constraints in dynamic pricing, see
references/fairness-constraints.md
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: asgard-ai-platform
- Source: asgard-ai-platform/skills
- License: MIT
- Homepage: https://github.com/asgard-ai-platform
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.