{"slug": "every-price-is-a-hypothesis-i-built-an-open-source-ai-agent-workflow-to-test-it", "title": "Every Price Is a Hypothesis. I Built an Open-Source AI Agent Workflow to Test It", "summary": "An open-source research workflow called Value Pricing was built to document the evidence behind pricing decisions rather than calculate a single optimal price, according to its author's account. The workflow combines market references, customer value, buyer research, demand analysis and delivery economics, and in a demonstration an AI agent refused to guess a price for a fictional invoice tool, instead asking seven questions and later having its own devil's advocate reviewer catch two mistakes. The author says the tool helps identify conflicts between research methods and turn findings into hypotheses testable with buyers, and a walkthrough installs the plugin and runs a pricing study for a fictional product in three prompts.", "body_md": "I asked an AI agent to price a fictional invoice tool. It refused to guess a number. It asked me seven questions first, and later its own devil’s advocate reviewer caught two mistakes in its work. That refusal to guess is the whole point of what I built.\n\nA pricing decision usually begins with a number. A competitor charges €49. Another charges €79. The finance team wants a particular gross margin. Someone suggests €59.\n\n**But what supports that number?**\n\nCompetitor prices tell us what other businesses charge, not necessarily what customers value. Cost models tell us what a business needs to earn, not what a buyer will pay. Surveys reveal stated preferences, which may differ from purchasing behaviour. Historical transactions show what happened under previous conditions, but do not automatically explain what would happen at another price.\n\nEach method answers a different question. Pricing decisions often combine their outputs without checking whether the evidence is comparable or whether the methods support the conclusion.\n\nI built Value Pricing as an open-source research workflow for investigating those questions. It brings together market references, customer value, buyer research, demand analysis and delivery economics. It does not calculate a universally optimal price. It helps document the evidence behind a pricing decision, identify conflicts between methods and turn findings into hypotheses that can be tested with buyers.\n\nIf you want to follow along, the walkthrough near the end installs the plugin, runs a pricing study for a fictional product in three prompts, and shows which reviewer agents it calls and what they concluded.\n\nConsider a fictional B2B software company reconsidering its pricing structure. It wants to know what comparable alternatives charge, which capabilities differentiate its offering, how much economic value the service creates, which buyer segments value those outcomes, how usage affects delivery costs and how observed transaction quantities vary with realised prices.\n\nThese questions require different evidence. A competitor comparison cannot establish willingness to pay. A value model cannot establish whether the business can deliver profitably. A simulated buyer panel cannot establish real purchasing behavior.\n\nThe first stage is discovery. Before selecting a research method, the workflow needs to understand what is sold, who buys it and what decision the business needs to make.\n\nA usage-based software service requires different research from a professional-services retainer or a one-off digital product. The billing unit, customer segments, alternatives and distinction between buyer and user all affect the research design.\n\nA study can be configured using a structured YAML specification:\n\n```\ndecision:  question: \"Evaluate the current pricing structure\"  constraints:    - \"Maintain delivery profitability\"offering:  id: example-service  name: \"Example Service\"  description: null  business_model: nullmarket:  geography: null  target_market: null  alternatives: []currency: EURsegments:  axis: null  bands: []research:  methods: []  scenarios: []  sensitivity_assumptions: {}  validation_requirements: []\n```\n\nThis is intentionally incomplete. It does not supply fictional market prices, customer shares or operating costs. Those inputs must come from the business or be labelled as assumptions in a synthetic exercise.\n\nA blank field should remain a gap until somebody provides evidence.\n\nA competitor comparison needs more than a list of prices. One vendor might charge €30 per month for a limited number of transactions. Another might charge €80 for a larger allowance, priority support and additional capabilities.\n\nComparing those numbers without considering scope, billing units and commercial terms can produce misleading conclusions.\n\nValue Pricing records market references with their source, observation date, geography, commercial terms and relevant attributes. It distinguishes public prices from quote-based and undisclosed pricing.\n\nWhen enough comparable offers are available, a hedonic model can investigate the association between product attributes and listed prices:\n\n**ln(Pᵢ) = β₀ + Σⱼ₌₁ᵏ βⱼXᵢⱼ + εᵢ**\n\nHere, Pᵢ is the observed listed price, Xᵢⱼ represents an attribute of offering i, and βⱼ estimates the association between that attribute and price.\n\nThe coefficients are not automatically causal premiums. An attribute may appear alongside other capabilities, different customer segments or different commercial terms.\n\nThe repository includes a synthetic market fixture that generates 260 fictional vendors, multiple plans per vendor, structured product attributes, public and quote-based offers, usage allowances and random price variation.\n\nThree planted attribute effects are:\n\nThese are constructed values, not estimates from an actual market. The self-test checks whether the estimated coefficients’ 90% confidence intervals contain the planted values. It also tests a planted relationship between usage allowances and listed prices.\n\nMarket references establish what alternatives charge. They do not establish what an alternative is worth to a particular buyer.\n\nEconomic Value to the Customer (EVC) compares an offering with the buyer’s next-best alternative, considering the economic outcomes that differ between them.\n\nSuppose a fictional software service reduces manual work. A basic value model might be:\n\n**V = H × C × R**\n\nWhere:\n\nThe realisation term matters. A system might theoretically save 100 hours, but if the customer can convert only 60% of those hours into productive capacity, treating all 100 hours as realised financial value overstates the benefit.\n\nValue Pricing includes a configurable Monte Carlo workflow for scenarios where uncertainty can be represented meaningfully. The model examines how different assumptions affect the resulting value distribution.\n\nThe result is a modelled value estimate, not an observed willingness-to-pay figure.\n\nCustomers may value functionality, implementation support, service quality or different access levels. Their preferences do not necessarily translate into the same willingness to pay for every feature.\n\nThe workflow supports qualitative interviews, price-sensitivity research, Van Westendorp, Gabor-Granger, choice-based conjoint and exploratory simulated buyer research.\n\nThese methods answer different questions. Van Westendorp investigates perceived price acceptability. Gabor-Granger examines stated purchase likelihood across presented prices. Choice-based conjoint investigates preferences across combinations of attributes and prices.\n\nThe repository includes a synthetic panel test with planted willingness-to-pay contributions:\n\nThe fixture creates synthetic respondents and choice tasks with controlled preferences. The test runs the panel analysis and conjoint estimation, then checks whether the estimated willingness-to-pay contribution for the service-level attribute falls within a specified tolerance of its planted value.\n\nSimulated buyers can help pilot questions, identify confusing terms and generate hypotheses. They are not a substitute for human respondents or observed behaviour, and their outputs should not be reported as empirical findings or demand forecasts.\n\nThe word elasticity appears in different parts of pricing research, but it does not always describe the same relationship.\n\nThe market analysis can investigate how listed prices vary with a competitor’s usage allowance or another pricing metric. The synthetic market fixture plants an elasticity of 0.75 for usage-based pricing. The self-test checks whether the implementation recovers that relationship within a tolerance of 0.05.\n\nThis concerns the relationship between market-listed prices and plan limits. It is not customer demand elasticity.\n\nA separate module examines how observed transaction quantities vary with realised unit prices:\n\n**ε = (% change in quantity) / (% change in realised unit price)**\n\nEquivalently:\n\n**ε = (%ΔQ) / (%ΔP)**\n\nThe repository implements a hierarchical Bayesian negative-binomial model. It accounts for repeated customer transactions, partial pooling across segments, seasonality and available controls such as promotions, channel and contract duration.\n\nThe synthetic demand fixture creates two fictional customer segments, 36 customers per segment and 12 monthly observations per customer. It plants a price elasticity of −0.80 and introduces deliberately invalid rows to test data validation.\n\nThe self-test checks whether segment-level estimates recover the planted value within a defined tolerance, whether their 90% posterior intervals contain the known value, whether convergence diagnostics pass, and whether insufficient price variation blocks estimation.\n\nThe model conditions on observed positive transactions, so it does not estimate purchase incidence. Historical prices may also be endogenous. Without a defensible identification design, the result is an observational association, not a causal estimate.\n\nA price can appeal to customers and still be commercially unsustainable.\n\nThe cost model investigates what it takes to deliver the offering. Depending on the business, inputs can include infrastructure, support, onboarding, labour, payment processing, channel commissions, fixed platform costs and capacity constraints.\n\nThe model calculates cost and contribution scenarios using configured inputs. Cost is an independent constraint in the research. It should not automatically determine what customers should pay. A cost-plus calculation can establish a minimum commercially viable price under stated assumptions, but it cannot establish perceived customer value.\n\nImagine an investigation produces several observations: competitor listings suggest an association between certain capabilities and higher prices; the EVC model suggests that one customer outcome creates potential economic value; buyer research indicates a preference for additional support; transaction analysis suggests that observed quantity declines as realised prices increase; and delivery economics shows that additional support has a meaningful cost.\n\nNone independently determines the price.\n\nThe synthesis stage brings the findings together while retaining their separate evidence bases. It should expose disagreements rather than hide them in a weighted average.\n\nThe handover records the decision, selected methods and rationale, evidence and source dates, modelled results and uncertainty, assumptions, unresolved gaps, candidate pricing hypotheses where supported, trade-offs and a validation plan.\n\nA model-selected candidate remains conditional on its inputs. It is not a guaranteed optimal price.\n\nValue Pricing is an open-source Agent Skill with supporting Python analysis tools. Its structure separates workflow instructions, method references, configurable templates and analytical scripts.\n\nThe project includes specialised perspectives such as a pricing strategist, competitive analyst, behavioural economist, buyer persona, CFO/unit-economics reviewer and devil’s advocate. These perspectives structure different questions; they are not independent experts or empirical evidence.\n\nThe implementation includes data-handling safeguards. Scripts run only when invoked. Crawling is optional. External model calls require explicit confirmation of data transfer. The workflow is designed to work without sending confidential study material to a model provider.\n\nRepository: [https://github.com/C-Kapsalis/value-pricing](https://github.com/C-Kapsalis/value-pricing)\n\nThe repository includes an optional calibration procedure based on Brand, Israeli and Ngwe’s *Using LLMs for Market Research* (Harvard Business School Working Paper 23–062).\n\nThe procedure is designed to reproduce selected choice tasks using original study materials and compare simulated willingness-to-pay estimates with a human-research benchmark. The calibration script requires the relevant choice sets and original prompt template as inputs; these materials are not bundled with the repository.\n\nIt generates repeated prompts, processes responses and estimates willingness to pay using a multinomial logit model. It reports a bootstrap 90% confidence interval and the ratio between the simulated estimate and the supplied human benchmark.\n\nThe procedure does not automatically adjust the main study’s estimates. Its existence should not be confused with a completed calibration experiment.\n\nTo show what the workflow does in practice, I installed it into Claude Code and ran a study for a fictional product: Ledgerly, an invoice-reconciliation tool for small accounting firms that charges $49 per firm per month and is considering tiers based on invoice volume. Below are the exact prompts I typed and what happened after each one. An agent will not phrase things identically on your machine, but the steps, files and checks will be the same.\n\nIn Claude Code, add the marketplace and install the plugin:\n\n```\n/plugin marketplace add C-Kapsalis/value-pricing/plugin install value-pricing@value-pricing\n```\n\nIn Codex or another Agent Skills client, run npx skills add C-Kapsalis/value-pricing. The install adds one skill (value-pricing), a /value-pricing command and seven reviewer agents: a pricing strategist, competitive analyst, buyer persona, CFO, behavioural economist, go-to-market lead and devil's advocate. The analysis scripts need Python 3.12 or later and the packages in the skill's requirements file; the agent can set that up, or you can do it yourself:\n\n```\npython3.12 -m venv .venv && source .venv/bin/activatepip install -r skills/value-pricing/scripts/requirements.txt\n```\n\n*Help me research pricing for our product. Ledgerly is a (fictional) invoice-reconciliation tool for small accounting firms. Today it costs $49 per firm per month, flat. We’re deciding whether to move to tiers based on the number of invoices a firm processes each month.*\n\nNo slash command was needed. Claude Code matched the request to the skill and loaded value-pricing on its own, then read the skill's intake guide (references/1-intake.md). It did not run anything. Instead, it asked whether I wanted to work from real data or from labelled assumptions, followed by seven discovery questions. The first three:\n\nThis is the behaviour I designed for: scope the decision before choosing methods, and never fill a gap with a plausible-sounding number.\n\n*Option B. Assumptions: 300 firms, US, USD, monthly self-serve billing. Invoice volume per firm per month: under 100 for 45% of firms, 100 to 500 for 40%, over 500 for 15%. Variable cost is OCR at $0.02 per invoice plus about 20 minutes of support per firm per month at $30 an hour. Ledgerly saves about 3 minutes of staff time per invoice at $40 an hour […] Constraint: no existing customer’s bill can rise more than 30% in year one. We have no customer research. Set up the study and run the value and cost phases.*\n\nThe agent created a pricing-study/ folder from the skill's templates (study.yaml, offering.yaml, costs.yaml, value_drivers.yaml) and started a DECISIONS.md log that records each ruling and who made it. It ran the bundled cost_model.py. For value, it chose not to use the bundled Monte Carlo script and logged why: with a single value driver, splitting value across features would be meaningless. It wrote a small study-specific model instead. The headline results:\n\nIt also listed the inputs that would change the answer most, starting with the real distribution of invoices per firm.\n\n*Draft two or three tier structures that respect the 30% cap, then convene the pricing council to critique them and tell me which one to test first.*\n\nThe agent drafted three structures in proposals.yaml, modelled them against the 300 firms and wrote a council dossier. It then spawned five of the seven reviewer agents in parallel. It left out the competitive analyst because no market phase had been run, and the buyer persona because there was no persona evidence, which would have made its answers pure invention.\n\nThe reviewers disagreed in a useful way. The pricing strategist, behavioural economist and go-to-market lead favoured A, because cutting the light tier to $39 gives 45% of firms good news in the migration message. The CFO and the devil’s advocate favoured B, because the $1,350 a month lost on light firms is certain while the gains elsewhere are assumed. All five agreed that invoices processed is the right unit, that single-month tiering would swing with tax season, and that the real risk is the year-two jump once the cap expires.\n\nThe devil’s advocate also caught two mistakes in the main agent’s own work: a claim in the dossier that the heavy tier became unprofitable at 2,500 invoices, and an unknown that had not been saved to the cost file. The agent corrected both and re-ran the cost model before answering.\n\nThe final recommendation was an adjusted structure, A+, tested on new sign-ups only:\n\nIts first action item was free: pull twelve months of invoice counts per firm from the OCR logs, because that one input decides between A and B.\n\nThe Ledgerly run used the value and cost tools. The heavier statistical methods (hedonic regression, Bayesian demand elasticity, choice-based conjoint) are checked by a self-test that builds a synthetic study with known answers and verifies that each method recovers them:\n\n```\npython tests/selftest_value_pricing.py --dir ./demo-study\n```\n\nOn my run, all 18 checks passed:\n\nNot everything was perfect. One hedonic premium came out 0.09 high, and the conjoint estimates run slightly low across the board. The self-test also leaves a full study in demo-study/. Its synthesis flags that competitor prices ($103 to $130) sit above what the value model says any segment could capture ($22 to $71), and that the large segment has no defensible price window at all. That is the behaviour the synthesis stage exists for: when evidence streams conflict, it shows the conflict instead of averaging it away.\n\nThe synthetic self-test checks analytical components against known values. It does not establish that competitor listings represent transaction prices, synthetic buyers behave like real customers, modelled value becomes realised benefit, historical price relationships are causal, or a recommended structure will maximise revenue.\n\nThe quality of the workflow depends on the research design and inputs. A sophisticated model cannot compensate for an incorrectly defined segment, a misleading counterfactual or a poorly measured cost driver.\n\nI want to validate the methods against appropriately sourced real pricing studies, improve how evidence quality is represented across research streams, and develop a more complete treatment of purchase incidence.\n\nI also want to make the handover between analytical components easier to inspect. A reader should be able to trace a pricing hypothesis back to its source evidence, assumptions, model and uncertainty.\n\nValue Pricing is available at [https://github.com/C-Kapsalis/value-pricing](https://github.com/C-Kapsalis/value-pricing).\n\nThe repository includes the Agent Skill, specialised perspectives, configurable study templates, Python analysis scripts, synthetic self-tests and method references. Consult the README and tests/selftest_value_pricing.py for setup and execution details.\n\n*Disclosure: I am the author of Value Pricing. The project and synthetic examples discussed here are independent open-source work. Synthetic figures and test data are illustrative; they are not customer research, market benchmarks or evidence of commercial pricing performance.*\n\nThe objective is to make the reasoning behind a pricing decision explicit, reproducible and open to challenge.\n\nIf you’ve made a pricing call recently, what evidence did you lean on, and what did you wish you had? Tell me in the replies. I’m looking for real cases to test the workflow against.\n\n[1] J. Brand, A. Israeli and D. Ngwe, Using LLMs for Market Research (2023), Harvard Business School Working Paper 23–062\n\n*This story was drafted on* *TK**.*\n\nChristoforos (Chris) Kapsalis is a technical author and marketer with a passion for building open-source tools that will hopefully help businesses in disadvantaged parts of the world or run by members of disadvantaged communities improve their workflows and maximize the value generated by their marketing efforts.\n\n[Every Price Is a Hypothesis. I Built an Open-Source AI Agent Workflow to Test It](https://pub.towardsai.net/every-price-is-a-hypothesis-i-built-an-open-source-ai-agent-workflow-to-test-it-d4d44f3129cb) was originally published in [Towards AI](https://pub.towardsai.net) on Medium, where people are continuing the conversation by highlighting and responding to this story.", "url": "https://wpnews.pro/news/every-price-is-a-hypothesis-i-built-an-open-source-ai-agent-workflow-to-test-it", "canonical_source": "https://pub.towardsai.net/every-price-is-a-hypothesis-i-built-an-open-source-ai-agent-workflow-to-test-it-d4d44f3129cb?source=rss----98111c9905da---4", "published_at": "2026-11-15 20:01:02+00:00", "updated_at": "2026-11-15 20:21:27.665169+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "artificial-intelligence"], "entities": ["Value Pricing"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/every-price-is-a-hypothesis-i-built-an-open-source-ai-agent-workflow-to-test-it", "markdown": "https://wpnews.pro/news/every-price-is-a-hypothesis-i-built-an-open-source-ai-agent-workflow-to-test-it.md", "text": "https://wpnews.pro/news/every-price-is-a-hypothesis-i-built-an-open-source-ai-agent-workflow-to-test-it.txt", "jsonld": "https://wpnews.pro/news/every-price-is-a-hypothesis-i-built-an-open-source-ai-agent-workflow-to-test-it.jsonld"}}