How the Adaptive Utility Agent framework gives pricing platforms context-adaptive objectives, a correction loop that prevents errors from amplifying at scale, and the full auditability that regulators now require — without separate rule sets for every scenario.
On this page
The pricing software landscape has three tiers, each with a structural failure mode that compounds as markets get faster and more complex.
The majority of pricing systems in production today are rule-based: "if competitor A drops below $X, match at $X-0.50; if inventory falls below 10 units, raise 10%." Rules execute quickly and are auditable in theory — you can trace which rule fired. But they are fundamentally static. Rules are written to handle conditions anticipated at the time of writing. When conditions emerge that weren't anticipated — a flash demand spike, a competitor pulling out of a category, a viral moment shifting demand curves — rules produce the wrong price until someone manually rewrites them. The gap between market conditions changing and rules catching up is where margin is lost.
ML repricing models — trained on historical demand, elasticity, and competitor data — appear to solve the static problem. But they introduce a more dangerous failure mode: when a learned pattern is wrong, the error propagates to every SKU, every market, every hour the model runs, before anyone detects it. As one industry analysis notes, "an algorithm that amplifies errors does so at scale, across every SKU it touches, before anyone notices." The model has no mechanism to detect when its own predictions are wrong and stop. There is no feedback loop between a detected pricing error and the model's behavior. It will reprice the same way tomorrow.
Hybrid approaches layer ML optimization inside rule-based guardrails. This addresses the most catastrophic ML failure (pricing at a loss) but not the structural problem: the ML component still has no correction loop, and the rule guardrails are still static. The system learns from historical data at retraining time, not from its own live errors.
The regulatory wave makes the auditability failure mode — not just the accuracy failure mode — commercially critical. A pricing system that cannot explain why it set a specific price, on a specific day, in structured and retrievable form, is now a regulatory liability in multiple jurisdictions.
The framework's utility function governs pricing through a single formula whose weights shift with market context — no separate rule sets, no retraining for new conditions:
U = w_r(f) · Revenue + w_cs(f) · Customer satisfaction + w_m(f) · Market share f — pricing context (supply constraint, competitive threat, normal, loyalty defense...)
The key property from §2.5 of the full whitepaper: "A flat 'never surge' policy is suboptimal in crunch conditions; a flat 'always surge' policy destroys customer relationships in normal conditions. The utility framework selects correctly in each context through a single formula with context-specific field parameters, without pre-programmed rules for each scenario."
Balanced profile. Customer satisfaction has meaningful weight — loyalty and repeat purchase matter more than squeezing margin on a single transaction.
Revenue weight rises to w_r=0.65. Surge pricing is optimal — allocates scarce inventory to highest-value buyers. Matches the whitepaper's supply constraint example. See §2.5.
Market share weight rises to w_m=0.40 — pricing shifts to defend position and retain customers. From §2.5.
High churn risk detected or customer segment identified as price-sensitive long-term buyers. Loyalty incentives dominate. Short-term revenue is sacrificed for LTV.
No rule proliferation. Each scenario above is a weight profile — a few numbers stored as field parameters. Adding a new pricing context (flash sale, event-driven demand, geography-specific campaign) means adding a weight profile and a classifier signal, not writing and testing a new rule set. The formula remains the same; only the weights change.
This is the framework's most commercially important advantage in the current regulatory environment, and the one that existing systems — rule-based, ML, and hybrid — cannot match structurally.
When a regulator, customer, or internal reviewer asks "why did this price change at 2:47pm on Tuesday?" the answer must be structured, retrievable, and factually accurate. A boilerplate notice that "prices are set by an algorithm" does not satisfy the NY disclosure law effective November 2025. The framework produces the answer as a byproduct of its normal operation.
Every pricing decision produces a structured log record:
{
"timestamp": "2025-11-14T14:47:23Z",
"product_id": "SKU-9821",
"price_set": 47.99,
"prior_price": 44.50,
"field": "supply_constraint",
"field_distribution": {"supply_constraint": 0.72, "standard": 0.28},
"utility_score": 0.681,
"components": {
"efficacy_ema": 0.74, // revenue performance vs baseline
"confidence": 0.82, // internal consistency of the pricing signal
"curiosity": 0.09 // novelty adjustment
},
"weights_active": {
"w_r": 0.65, // supply constraint profile
"w_cs": 0.20,
"w_m": 0.15
},
"confidence_gate": "passed", // C >= C_min — price move was made
"active_corrections": [
"elasticity overestimated for this segment last cycle — adjusted"
]
}
Every price decision records the exact weight vector active at the time, the U score, and each component (E, C, K). The pricing logic is not a black box — it is a logged arithmetic expression with retrievable inputs.
Below C_min, the system does not make a pricing move — it escalates to a human reviewer. No automated price change happens when the system's confidence is below threshold. The log records every escalation event.
When a pricing error is corrected — an elasticity misread, a surge that damaged relationships — the correction is stored in the assertions store with a timestamp and evidence summary. The log records not just what was priced, but why the model learned to price differently afterward.
The utility log is the disclosure artifact. When the NY law requires "this price was set by an algorithm using [inputs]," the framework's logs contain the exact inputs, their weights, and the decision boundary. The disclosure is factually accurate, not boilerplate.
Why no existing system provides this. Rule-based systems can trace which rule fired, but not why the rule was correct and how confidence was determined. ML systems produce a price from a high-dimensional function with no structured explanation at the decision level. The framework's utility function is an explicit arithmetic expression — every price has a logged decomposition into its components. That decomposition is what regulators and customers are increasingly demanding.
The confidence gate applies a hard decision rule: below C_min, the system does not set a price autonomously. It escalates to a human reviewer with the full decision context.
act (set price) if C ≥ C_min(f) AND E ≥ E_min(f) escalate to human otherwise Recommended C_min values per pricing context: Commodity / standard goods: C_min = 0.65 High-volume / high-visibility: C_min = 0.75 Regulated categories: C_min = 0.85 Premium / relationship pricing: C_min = 0.80
This matters for three practical reasons:
The framework's core contribution to pricing is that it closes the feedback loop that existing systems leave open. When a pricing decision produces a worse outcome than expected — demand elasticity was overestimated, a surge damaged customer relationships, a competitive response was faster than anticipated — that error is detected, stored as a correction, and the model does not repeat it.
1. Price set at $52.99 during supply constraint (w_r=0.65 active)
2. Demand response is measured: conversion rate 8% below elasticity model prediction
3. Contradiction detected: claimed demand response contradicts observed demand response
4. Correction stored:
"supply_constraint surge at this price point for this category overestimates
elasticity by ~12%. Adjust surge ceiling downward."
5. Correction injected into next pricing session for this category
6. DPO pair accumulated: (lower surge price, $52.99) → preferred response
7. Next calibration cycle: elasticity model updated with weighted DPO training
The result: the second time the system faces an equivalent supply constraint in this category, it applies the corrected elasticity estimate automatically. Without the correction loop, the same overestimated surge would repeat indefinitely until someone manually reupdated the model.
The framework's simulation (software engineering domain, but directly analogous) demonstrated a 69.6% reduction in repeated errors over an uncalibrated baseline across five correction cycles. Applied to pricing: a system that misreads elasticity in cycle 1 will misread it 70% less often by cycle 5. See Appendix A of the full whitepaper for the full simulation results.
| Property | Rule-based | ML-based | Hybrid | This framework |
|---|---|---|---|---|
| Adapts to emergent conditions | ✗ Rules pre-written | ~ Only at retraining | ~ ML within fixed rules | ✓ Weight profiles + correction loop |
| Corrects its own errors | ✗ Errors repeat until rules rewritten | ✗ Errors amplify at scale | ✗ ML component uncorrected | ✓ Detected, stored, not repeated |
| Fully auditable per decision | ~ Rule trace only | ✗ Black box | ✗ ML component opaque | ✓ Logged U, weights, components |
| Multi-objective balance | ✗ Separate rules per objective | ~ Single loss function | ~ Partial | ✓ Explicit weight vector per context |
| Hard accountability floor | ~ Hard floor rules only | ✗ No confidence gate | ~ Rules as floor only | ✓ C_min gate → human escalation |
| Regulatory disclosure capability | ~ Rule audit, not explanation | ✗ Cannot explain per decision | ✗ ML component unexplainable | ✓ Structured log per decision |
| Adds new pricing context | ✗ Write new rules | ✗ Retrain model | ✗ Both | ✓ Add weight profile + classifier signal |
| Customer relationship protection | ~ Cap rules only | ✗ No structural protection | ~ Cap rules only | ✓ w_cs term + low-confidence escalation |
Based on publicly documented behavior of rule-based and ML pricing systems. Framework properties from §2.5 and the correction loop specification in §8.
The 2024–2025 regulatory wave around algorithmic pricing is specifically targeting opacity and the lack of human accountability. The framework's properties map directly onto what regulators are requiring.
| Regulatory requirement | Jurisdiction / instrument | Framework property that addresses it |
|---|---|---|
| "This price was set by an algorithm using [specific inputs]" disclosure | New York State — effective Nov 10, 2025 | Utility log records exact inputs (field distribution, weight vector, signal values) for every price decision. Disclosure is factually accurate, not generic. |
| Human oversight requirement for high-impact automated decisions | EU AI Act (2024), High-Risk AI classification | Confidence gate creates a documented human-in-the-loop boundary. Every escalation event is logged with context. Human reviewer receives the full decision trace. |
| Antitrust: no algorithmic price fixing via shared pricing software | DOJ / FTC; RealPage suit (2024) | The correction loop and confidence gate operate on the platform's own demand signals. No mechanism for cross-platform signal sharing. Assertions store is local by default. |
| Price gouging limits — pricing must reflect legitimate supply/demand | 30+ states; proposed federal Price Gouging Prevention Act | Confidence gate prevents pricing on bad or manipulated data signals. The w_cs customer satisfaction weight structurally penalizes pricing that damages relationships. |
A practical MVP for a pricing platform does not require replacing the existing pricing system. It begins as a shadow layer that builds the correction infrastructure:
AUA v1.0 adds per-decision utility logs, a correction loop, and a tamper-evident audit chain on top of any pricing model. Configure with a custom UtilityScorerPlugin for your pricing-specific quality signals.
pip install adaptive-utility-agent
aua init my-dynamic-pricing-agent --preset coding --tier macbook cd my-dynamic-pricing-agent aua doctor
# aua_config.yaml
specialists:
- name: software_engineering
model: qwen-coder-7b-awq
port: 11434
field: software_engineering
safety:
abstention_enabled: false
require_arbiter_for_high_risk: true
min_confidence_for_direct_answer: 0.70
security:
encryption: {enabled: true, key_secret: AUA_ENCRYPTION_KEY}
audit:
enabled: true
hash_chain: true
Generate your encryption key: python3 -c "import os; print(os.urandom(32).hex())" or openssl rand -hex 32 — 64-char hex string. See Tutorial §12.4 for key management.
aua serve
curl -X POST http://localhost:8000/query \
-H "Authorization: Bearer $AUA_TOKEN" \
-H "Content-Type: application/json" \
-d '{"prompt": "...", "session_id": "demo"}'
| AUA v1.0 provides | You bring |
|---|---|
| Multi-specialist routing + utility scoring | Domain-specific specialist models |
| Arbiter + contradiction detection | Domain-specific quality criteria |
| Correction loop + DPO pair export | Fine-tuning infrastructure (TRL, Axolotl, …) |
| Blue-green deployment + rollback | Evaluation datasets for your domain |
| Append-only audit log with hash chain | Pricing platform API integration |
| Prometheus + Grafana + OTEL | Your monitoring infrastructure |
Full instructions: AUA Tutorial · Framework v1.0 · GitHub ↗