The Pricing for the Agent Economy book is the work of a community. It has been shaped by seven interviews with the people shaping the agent economy and actually designing credit based pricing systems and has benefitted from comments and feedback by more than 20 people in the community. A big thank you from Wolfgang, Michael and I to everyone who has contributed to the book and to the broader value, billing and pricing community.

The website for the book is now online at https://pricingfortheagenteconomy.com/

The website is more than just promotion for the book. It includes some tools you will find useful in your day-to-day work, interviews with industry leaders, a glossary and one of the key chapters.

• Tool: The Credit Based Pricing Design Process

• Glossary: All the critical terms you need to know

• Sample Chapter: Chapter 2: The Agent Economy — A Field Guide

• Interviews: Learn from the people who are taking agents to market

If you can’t wait to get your hands on the book you can pre-order the PDF version.

Included with the PDF pre-order is the full text of Part 1 of the book (subject to future revision).

PART I: The Structural Shift

Chapter 1: Your Pricing Model Was Built for Humans
Chapter 2: The Agent Economy: A Field Guide
Chapter 3: The Long Road to Credit-Based Pricing
Interlude: The Arguments Against Credits
Spotlight: The COMPASS Framework

Some of you will find the Interlude the most interesting part of the book. It argues the case against the book looking at

(i) why credits are a bad idea, or at best a stepping stone to something else

(ii) that agents are not how the power of AI will be delivered into the economy

A shout out to Danilo Zatta, who insisted we add this! Danilo has written some great pricing books himself, including The 10 Rules of Highly Effective Pricing: How to Transform Your Price Management to Boost Profits.

Interested? Sign up to be notified when Pricing for the Agent Economy is available or get started now by buying the PDF.

If you read a lot on LinkedIn you have probably seen the word ‘legibility’ creep into the lexicon. Many things are being described as legible, including value and pricing. Some recent sightings in the wild.

“The platform tracks user engagement metrics to make consumer desire legible to advertisers.”

“Providing an inflation-adjusted GPA makes student contexts legible to employers.”

“Modern tech platforms run entirely on a hyper-optimized drive to render human existence legible and machine-readable.”

“Social media platforms encourage users to make themselves legible to the algorithm.”

I expect most of us have come across the term as we wander the Internet, especially when we are reading AI generated content. For me it has become a tell that AI played some role in generating or editing the content.

Michael Mansard, Wolfgang Ulaga and I use the term ‘legible’ quite often in our new book Pricing for the Agent Economy where we talk about making everything from value and pricing to agent-to-agent interactions legible.

A few years ago we would have probably used ‘transparent’ where we now say ‘legible.’

Is there any meaningful difference between ‘transparent’ and ‘legible’?

I think there is actually.

‘Transparent’ implies that the information, for example the pricing model, is easily available and shared in a way that does not disguise or mislead.

‘Legible’ information is visible to systems in a way that they can categorise, manipulate and compute.

The term ‘legible’ came into modern use with James C. Scott's paradigm making book Seeing Like a State. This book argues that pre-modern societies were a "messy, complicated blur" to centralized rulers. To tax, conscript, and govern, states forced "administrative legibility" onto the population. They did this by inventing permanent last names, standardizing the metric system, and mapping organic communal lands into uniform squares. The term became shorthand for simplifying complex human realities so a central authority can monitor them.

Ouch. I am not sure most of us are aware of where this term comes from or what it implies about standardization, control, or stripping away the messiness that makes us human.

How did ‘legibility’ become such a popular word? It does capture a moment, the transition from transparency (which is for humans) to legibility (which is mostly for other AIs). But AI itself plays a role in this. It is one of those tells that suggests that the text is AI generated. Others are ‘load-bearing,’ ‘mechanism’ or ‘bespoke.’ Maybe the AI agents that are the most common readers of content get more out of these word than us humans!

That said, pricing is moving towards legibility, as is value communication, and in general how we communicate across the business ecosystem (had to work ‘ecosystem’ in here as it another of those words Claude seems to love).

What pricing needs is both transparency and legibility.

Transparent pricing being pricing that is meaningful to a human, that does not try to trick, mislead or deceive, and that can meaningfully connected to value. This is the approach taken by The Value Project and its open source JSON schema for pricing models and value models.

Legible pricing is pricing that is transparent and machine computable (computable, not just readable). An agent should be able to compute the price (and the value) of a product and put it into a wider configuration of agents and services that will work together to solve a business problem, meet a use case or provide a job-to-be-done.

This is the direction I think The Value Project needs to go. And it will be the role played by the Mapper in the The Credit Pricing System.

(No tokens were consumed in writing this post.)

How much does a credit cost in your credit based pricing system?

This is a deceptively simple question. To answer it you need to be clear on a few things. The most important are how credits get consumed and the weights in your credit weight table (see below). Designing this table is the heart of credit based pricing design.

The other big choice is the price per credit. Should this be one price or several? We can see both in the market.

Variable and constant credit pricing

Many companies do not even bother to publish the price per credit, or cannot easily do so as the mapping from credit to price is complicated. In far too many cases credit pricing is not transparent and this is one of the main reasons for buyer pushback.

But the best companies do publish price per credit or it can be easily calculated from information provided. In this case there are two main patterns: varied prices across tiers and constant prices across tiers.

Companies that vary the price per credit across tiers

Companies that keep the price per credit constant across tiers.

At valueIQ.ai we keep the price per credit constant across tiers and make this machine readable using the Value Project JSON schema.

How to make this choice

The advantages of a fixed price are clear. Simplicity. One number to tune. Variations in value are managed through the credit weight table. For most companies this will be the right decision and you need to have very good reasons for doing anything else.

Why would you want to have a different price per credit at different tiers?

That depends on what other pricing levers you have and how functionality is fenced across packages.

This is turn depends on the role that packages play in your monetization approach. Let’s parse this a bit deeper.

Why have different packages?

The most common reasons for using packages are …

• Matching a package to a use case or job-to-be-done

• Adjusting for buyer scale

• Aligning to willingness to pay (WTP)

• Framing price using behavioural economics

Additionally, there are two different roles that tiered packages can play.

• Bring customers into the package that best suits their needs (and they would only change packages if their circumstances change)

• Provide an upsell path (bring people into an introductory package and upsell them)

Clarity on why one has packages and the role each package is supposed to play is the key to good package design.

When do you need to vary the cost per credit by package

The value per credit is significantly different across packages.

Why would that happen?

One reason is functionality fencing. The functionality that creates the most value is only available in certain packages. A unit of consumption (which is what a credit is) buys access to superior functionality (maybe a higher performance model) that generates more value.

Another possibility is more support at higher tiers. Some companies use the amount and mode of support as a fence.

We are starting to see more guaranteed capacity at higher tiers. Given the threat of compute scarcity (we will see if this is a real concern or something manufactured to stimulate demand) there could be some value to having secure access to compute and a higher price per credit is one way to capture this.

The other side is costs. Sometimes the cost to serve is higher for more premium tiers. Look at the three scenarios.

If the curve for cost to serve per credit (generally token costs these days) is radically different for each package there will be pressure to have a different price per credit. Before defaulting to this, do some diagnosis and look at two things:

• What is the margin for each package? — there is not necessarily a direct correlation as premium packages generally come with higher prices as they include more credits and may have other pricing mechanisms

• Why is the cost per credit higher in different tiers? — this implies that an error has been made in the credit weight table, if that is the case, then that is where it should be fixed

• Are credits more valuable in different packages? — this could happen if premium packages provide functionality that make the actions consuming credits more valuable

After the root causes are understood, look at different design options. The complexity, confusion and message dilution of having a different price per credit in different packages make it a design choice of last resort. Having different prices per credit for different things makes credits less fungible (you can’t use them in as many ways) erasing one of the main reasons for having credits in the first place.

In most cases, the solution to the the cost or value difference across packages is either a platform fee, one that goes up as functionality goes up, or a platform multiplier, which makes for better alignment but in most cases ads more complexity than most sales teams can explain or buyers will accept.

Recommended approach

In order of preference …

1. Have the same price per credit across all packages, tiers, etc.
   (Once can apply scaling algorithms to the price per credit so that buyers willing to commit to a large number of credits get a different price and one can blend in promotional and incentive credits, but these are all done in the context of a single base price per credit.)

2. Adjust for differences in cost and value per credit across packages with

   1. A platform fee (preferred approach)

   2. A platform x credits multiplier (makes it easier to model but is too much complexity in many situations)

3. If you feel you must have different prices or credit for different packages have a conversion mechanism to make the credits fungible

Looking to learn more about credit based pricing design? Michael Mansard, Wolfgang Ulaga and I go deep into this in our book Pricing for the Agent Economy: How to Design, Implement, and Scale Credit-Based Pricing in the Age of AI Agents. Email me at steven@patternmind.studio to get on the list for early buyers.

In my posts Pricing as exploration on a rugged landscape and Pricing design is fitness landscape engineering I speculated on a possible future for pricing as AI consumes the economy. In my intro I invited people to use their AIs to query and probe the two articles. I decided to do that myself, though in this case I asked for a review and critique. This was not always kind to my ego, but in the interests of transparency I thought I should share. This is a composite from a series of prompts using Perplexity Deep Research with Anthropic Claude Fable 5.

Direct Answer

“Pricing as exploration on a rugged landscape” and “Pricing design is fitness landscape engineering” — offer a useful reframing of pricing strategy as a search problem under complexity, with real practical value for practitioners thinking about AI-era monetization, even though the underlying NK-model machinery is imported loosely from evolutionary biology and complex adaptive systems and remains empirically untested.

Strengths and Insights

Reframing pricing as a search problem, not a static optimization, is useful. The core metaphor — that pricing decisions sit on a landscape of interacting choices where local optima can trap a firm below a much better distant configuration — captures something real about why companies get stuck with mediocre pricing architectures and fail to explore adjacent alternatives. This is a more dynamic and insightful picture than conventional pricing frameworks that treat metric selection or tiering as a one-time decision to “get right.”

The ruggedness-tunable-by-design idea is a useful diagnostic lens. Treating ruggedness as something a firm can dial up or down through choices like bundling, fencing, metrics, and credits gives practitioners a vocabulary for asking why their pricing landscape looks smooth (few interdependencies, easy to imitate) versus rugged (many interacting elements, harder for competitors to copy). Even without formal validation, this reframing helps explain observed patterns — e.g., why simple, transparent pricing sometimes gets rapidly matched by competitors while complex, bundled architectures persist longer.

The connection to AI-driven search and information capacity is timely and forward-looking. The claim that AI simultaneously increases a firm’s ability to search the pricing landscape (more experiments, faster iteration) and its ability to model value with more granularity (better information) points to a real and current shift in how pricing teams can operate. This is arguably the most original and practically relevant contribution of the two essays, since it connects an abstract landscape metaphor to concrete, observable capability changes happening in pricing organizations right now.

Explicit self-labeling as speculative is intellectually honest. Both essays frame themselves as “letters to the future” for “hardcore pricing geeks” rather than validated operating guidance, and the author openly admits he has not run these ideas on commercial data. This kind of disclosed uncertainty is a strength relative to a lot of business-strategy writing that presents unproven frameworks with false confidence.

The five-phase design process gives structure to an otherwise abstract theory. Turning the landscape metaphor into an actionable sequence (Terrain Report, Fitness Declaration, Coordinate Map, Architecture Brief, and iterative tuning) is a reasonable attempt to make a conceptual framework usable, even if the underlying metrics behind it (correlation length, legibility gap) are not yet operational in practice.

Most Important Criticisms

The core analogy is asserted, not demonstrated. Kauffman’s NK model was built to describe blind, unintentional genetic mutation and selection — a process with no foresight, communication, or intent. Pricing decisions are made by forward-looking, communicating actors who can observe competitors and plan ahead. The essays move from “pricing is like a fitness landscape” to “pricing can be modelled with NK-model mathematics” without establishing that the analogy preserves the properties that make the math meaningful.

Key metrics are undefined for real use. Concepts like correlation length, Hölder exponents of differentiability, and the “legibility gap” between a firm and its rivals sound precise but have no demonstrated way to be computed from ordinary commercial pricing and transaction data. The essays’ own hedge — that the author is unaware of anyone having tested this on real data — is an important admission that undercuts the practical rigor implied.

Collapsing pricing outcomes to a single fitness score oversimplifies real decisions. Real pricing choices serve multiple, often competing goals — customer trust, margin, regulatory exposure, sales-team usability, market share — and reducing all of this to one scalar metric (e.g., three-year margin-weighted contribution) elides tradeoffs that matter in practice.

(Note: I agree with this criticism and need work out ways to design pricing that serves multiple, often contradictory, goals.)

The academic literature the essays lean on is itself contested. Organizational-strategy applications of the NK model (via Levinthal and Rivkin) are not widely accepted and have been challenged.

The theory is framed as falsifiable but isn’t operationally testable. The author states the essays try to be “specific enough to be wrong,” which is an honest ambition, but the actual outputs (Terrain Reports, Architecture Briefs) are planning artifacts rather than predictions that could be confirmed or disconfirmed with data — making the “specific enough to be wrong” framing more aspirational than achieved.

Some supporting evidence is used in a legally and contextually risky way. The essays cite a real-world case of tacit algorithmic price coordination (a German gasoline duopoly) as illustrative of coupling dynamics, and flag it as “legally radioactive” even while using it — a combination that imports a legally sensitive example into practitioner-facing content without a strong enough caveat for the audience.

Where Strengths and Criticisms Intersect

Overall Assessment

Read as thought-provoking, practitioner-oriented speculation from an experienced B2B pricing consultant, the two essays succeed: they offer a fresh vocabulary for thinking about pricing complexity and correctly anticipate that AI will change both how fast companies can experiment with pricing and how much proprietary insight they can build into their value models. Read as a validated theoretical framework with “design laws,” the essays overreach — the mathematical apparatus is borrowed and not fully demonstrated, and several of its central claims (measurable ruggedness, durable information asymmetry, single-metric fitness) remain unverified assumptions rather than established results.

I spent part of the summer rereading Stuart Kauffman’s 1993 book The Origins of Order: Organization and Selection in Evolution. I first read this book in my 20s and rereading it now I realize it shaped a great deal of my thinking. The Origins of Order is directly relevant to how pricing will work in the future. This is the follow up to Pricing as exploration on a rugged landscape which should be read first.

This is the third in a series of technical deep dives into the conceptual foundations of pricing. Not many people will be interested in this, but I believe it sketches where pricing practice needs to go in the coming years. These are my letters to the future.

The first post was Price is Not a Number: It is a Probability Distribution. The second was Pricing as exploration on a rugged landscape. This post gives some guidance on what pricing designers should do, and tries to be specific enough to be wrong.

Fair warning: this is the longest and most speculative post in the series. It proposes a theory, derives design laws from it, and then lays out a process. Some of it is well supported by the strategy literature. Some of it is me extrapolating past where the evidence goes. I have tried to mark those places.

There is a glossary at the end of the previous post that is worth reviewing before diving in.

I encourage you to read this through the lens of your preferred AI and would appreciate it if you can share your prompts and results. If these are too long for the comments then email me at steven@patternmind.studio

TL;DR

The theory in one sentence

• Pricing design is the deliberate engineering of the fitness landscape that you and your competitors must both search.

• Pricing power derives from how well you can explore, then shape, then exploit the fitness landscape.

The two results the theory rests on

• The fitness landscape for any non commoditized solution is likely to be rugged with many local optima. Finding these requires more parallel searchers. Optimal ruggedness rises with search capacity.

• Complexity deters imitation, but it also deters your own replication. At moderate complexity a gap opens between the two if you hold better information than the imitator. The complexity that maximizes that gap rises with your informational advantage.

Six design dials

This is the

• N — how many pricing elements you set independently

• K — how much those elements interact (the ruggedness dial: bundling, fencing, credits)

• Q — the quotient: which price differences buyers actually perceive

• S — search capacity: parallel experiments per unit time

• C — external coupling: how much your fitness depends on rivals’ moves

• τ (tau) — repricing cadence

Seven pricing design heuristics

• Height of the peaks in the fitness landscape rises with K. Affordable K rises with S. Defensible K rises with your informational advantage I.

• Ruggedness is quotient-relative — smooth in your coordinates, rugged in theirs, is achievable and is the whole game.

• Landscapes have memory, so design sequences, not price points.

• Above a critical cadence in reactive markets, price-response gradients cease to exist.

• Voluntary coupling — price matching, indexation, MFN (Most Favoured Nation) clauses — imports your rivals’ ruggedness and hands them partial control of your fitness function.

The process: DECLARE, SURVEY, CARVE, TUNE, WALK

• Each phase has named artifacts. The Terrain Report is the one nobody currently produces and the one that changes the most.

What matters

• AI raises both S and I simultaneously and by orders of magnitude. Therefore optimal pricing architecture complexity is about to go up, not down.

• Two decades of “simplify your pricing” advice was correct for a world with three analysts and a spreadsheet. That world is ending.

Part One: The theory

The object of design is the landscape

Start with the mistake the first two posts were circling.

Pricing practice inherited its self-image from revenue optimization, where the deliverable is a number and the job is to find the best one. That framing survives even in sophisticated shops. We say “we set price,” and the artifact we produce is a price list, a rate card, a discount matrix. The number is the output.

Everything in the previous post says the number is not the important object. Prices sit on a landscape whose shape determines whether any particular price is findable, defensible, or stable. The landscape has more degrees of freedom than the price does, it changes more slowly, and it is far more the product of deliberate choice than we usually admit.

Here is the reframe the rest of this post builds on.

Pricing design is the deliberate engineering of the fitness landscape that you and your competitors must both search, subject to the constraint that you must be able to search it better than they can.

The first half is the ambition: you are not a searcher on given terrain, you are a terraformer. The second half is the constraint: a landscape you cannot navigate is worthless to you.

Result one: rugged landscapes are taller and have higher search costs

In Kauffman’s NK model, K (the number of other elements each element interacts with) tunes ruggedness. Skellett and colleagues showed in Maximally Rugged NK Landscapes Contain the Highest Peaks that the expected height of the global optimum rises with K. Under a Gaussian approximation, the maximally rugged case approaches roughly 0.84 as N grows, against 2/3 for the fully additive K=0 case. Interaction creates value. It does not merely obscure it.

But their experiments also show the cost. With N=8, a single hill climber does best at K=2, which is barely rugged. Push ruggedness higher and the lone climber does worse, even though the true peak is higher. As you increase the population of climbers, the ruggedness at which you achieve the best outcome moves upward. At maximal ruggedness the number of climbers needed to reliably find the global optimum approaches 2^N.

So: height is bought with with search capacity. The optimal ruggedness is a function of your search capacity.

Call that capacity S. This is the number of genuinely independent pricing experiments (explorations) you can run per unit time, times your ability to make sense of the results. A company running three sequential price tests a year has S near zero. A company running forty concurrent tests across segments, geographies, packages and metrics has a materially different S, and can therefore profitably inhabit a materially more rugged landscape.

Result two: complexity cuts both ways

Now the result that makes this a theory of pricing power rather than just a theory of search.

The strategy literature got to rugged landscapes long before pricing did. Levinthal’s Adaptation on Rugged Landscapes imported the NK structure into organization theory in 1997, showing that interaction among elements of organizational form produces multi-peaked landscapes, that a firm’s founding position persistently shapes which peak it finds, and that tightly coupled organizations suffer high failure rates in changing environments.

Then Rivkin, in Imitation of Complex Strategies, made the competitive argument formal. Strip out every conventional barrier to imitation — no patents, no scarce resources, no game-theoretic commitment — and complexity alone still deters copying. Finding the optimal configuration becomes intractable in the NP-complete sense, so rivals cannot compute their way to your position. They must fall back on heuristics and learning, and complexity undermines both: hill-climbing rivals get trapped on low local peaks, and rivals trying to mimic your whole configuration suffer large penalties from small errors. This is why, as Rivkin puts it, some winning strategies remain unmatched even when they are open to public scrutiny.

Read that last clause again if you have ever wondered why publishing your pricing page does not destroy your advantage.

But the keystone is Rivkin’s follow-up, Reproducing Knowledge: Replication Without Imitation at Moderate Complexity. Complexity affects two things at once: how easily rivals imitate you, and how easily you replicate yourself into new settings.

• Simple strategies are as easily imitated by rivals as replicated by you. No advantage.

• Highly intricate strategies resist imitation and replication about equally. You cannot scale your own architecture. Also no advantage.

• At moderate complexity, a gap opens between easy replication and difficult imitation — provided the replicator has better information than the imitator about what made the original work.

The level of complexity that maximizes that gap varies with the size of the replicator’s informational advantage.

That conditional clause is the most important sentence in this post. Complexity does not protect you. Complexity plus private information about your own landscape protects you. Complexity without that information protects your competitors from you as effectively as it protects you from them.

The central quantity: the legibility gap

Put the two results together and a single quantity falls out.

Let I be your informational advantage — how much better you understand your own value and pricing landscape than your rivals understand it. Let G(K,I) be the resulting gap between imitation difficulty and replication difficulty. Rivkin’s result says G is small at low K, small at very high K, maximized somewhere in between, and that the maximizing K rises with I.

Let H(K,S) be the height you can actually expect to reach: rising in K because rugged landscapes are taller, but falling off unless S is sufficient to search that ruggedness.

Then pricing design is choosing K to maximize something like

H(K,S)  +  λ G(K,I)

The whole theory is in the observation that S and I are not constraints. They are investments.

You can buy search capacity: experimentation infrastructure, segment-level instrumentation, willingness to hold variance. You can buy informational advantage: value models, win-loss discipline, usage telemetry, buyer research. And the moment you raise S and I, the optimal architecture complexity rises with them.

This gives a definition of pricing power:

Pricing power is the legibility gap: the difference between how well you can navigate your pricing architecture and how well anyone else can. Price level is a symptom. The gap is the asset.

This has two consequences.

Simplifying your pricing is disarming. Every simplification lowers K, which lowers the height of the peak you can reach and shrinks G toward zero. Sometimes correct — if your S and I are low, a complex architecture is a landscape you cannot search either, and you are better off on a modest, findable hill. But it should be an explicit trade against measured capability, not a reflex, and not a virtue.

Complexity you do not understand is worse than simplicity. The most dangerous state is high K with low I: a baroque pricing architecture accreted over a decade that nobody can model. You have all the navigational cost of ruggedness and none of the defensive benefit, because your rivals are not trying to imitate your architecture, they are competing against your outcomes, which are poor. The fix is not simplification. It is raising I until the existing K becomes an asset.

Where ruggedness comes from

If K (the number of interactions per N the number of modules) is a design variable, we should be concrete about the mechanisms. Every one of these is a deliberate choice that raises interaction among pricing elements:

Bundling. The right price for A depends on whether it is sold with B.

Fencing. Rules that restrict who gets which price — by segment, geography, commitment, channel. Fences create interaction between price and non-price attributes.

Multi-part tariffs (a form of hybrid pricing). Platform fee plus usage plus overage. Each part changes the optimal setting of the others.

Pricing metric selection. Whether you charge per seat, per workflow, per outcome, or per unit of compute determines the entire coordinate system. This is the single highest leverage decision in pricing design and it is usually made once, early, by someone who has since left. Pricing metrics are most often frozen accidents.

Credits and pooled entitlements. My own area of focus, and a rich source of deliberate connection making. Credit pools with cross-product fungibility, expiry rules, rollover, and tiered burn rates create dense interactions among elements that would otherwise be independent. A credit system is a connection machine.

Commitment and ramp structures. Multi-year deals with ramped minimums couple this year’s price to next year’s volume to the following year’s renewal.

Notice that all of these are things pricing teams already do. The theory does not ask you to invent new instruments. It asks you to recognize that when you reach for one of them you are turning the ruggedness dial.

Making terrain smooth for you and rugged for your competitors

Here is where I go furthest beyond the evidence, and where I think the biggest practical prize sits.

In the previous post I argued that price space is not a metric space. The distance between $9.99 and $10.00 is not one cent in any sense the buyer experiences; it is a threshold crossing. Meanwhile $10.00 and $10.05 are, to most buyers, the same price. What we actually search is not the real line but a quotient — price space with perceptually indistinguishable prices collapsed to single points.

Call that quotient Q. From the previous post: ruggedness is changes under change of quotient. A landscape that is discontinuous in dollars can be smooth in the right perceptual coordinates, and vice versa.

Now combine that with the legibility gap. Ruggedness is quotient-relative, and you choose the quotient, it is part of pricing design. Fences, tiers, packages, metrics and credit structures are literally the construction of equivalence classes over price space. So the target state is not “a rugged landscape.” It is:

A landscape that is smooth in your coordinates and rugged in your competitors’.

This is achievable for the reason Rivkin identified: you hold better information about your own value structure. You know which price differences your buyers actually perceive: because you have the value model, the win-loss data, and the usage telemetry. Your competitor observes your published prices and infers a landscape in dollar coordinates — which is the wrong space. You navigate in perceptual-value coordinates, where the same terrain is smooth and the gradient exists. If a gradient exists reinforcement learning can get purchase.

That is what I buys. Not knowledge of the right price. Knowledge of the right coordinate system. The system that you can explore faster than your competitors and shape to your own advantage.

I do not have this formalized and I would love to be argued out of it or helped to make it rigorous. But it is the cleanest account I have found of why two companies with visibly similar price lists can have wildly different pricing performance, and why value modelling — which looks like an expensive detour if you think the job is setting a number — is actually the acquisition of the coordinate system in which your landscape is navigable.

Coupling: the dial you should mostly turn down

Everything above is about your own offer and pricing architecture. Coevolution adds a dial that points outward.

Let C be the coupling between your fitness and your competitors’ moves — Kauffman and Johnsen’s NKC extension, where landscapes are coupled and one actor’s move changes another’s terrain, from Coevolution to the edge of chaos.

Most pricing discussion treats C as environmental. A significant amount of coupling is voluntary:

• Price-matching guarantees

• Competitive indexation and automated repricing against rival feeds

• Most-favoured-nation clauses

• Benchmarking your prices to a published market index

• Discount approval rules triggered by competitor quotes

Each of these hands a competitor partial control of your fitness function. Each imports their ruggedness into your landscape. And each shortens your correlation length, degrading the significance of your own experiments — which lowers S, which lowers the K you can afford, which shrinks your legibility gap.

Voluntary coupling is therefore not just a tactical concession. It is a structural transfer of pricing power. Levinthal’s finding that tightly coupled organizations fail at high rates in changing environments is the internal version of the same phenomenon.

High C with tacit algorithmic coordination can lift everyone’s plateau, as in the German gasoline evidence where duopoly market margins rose about 28% when both stations adopted algorithmic pricing. That is real. It is also legally radioactive in most jurisdictions, and it is a strategy that depends entirely on your rivals’ continued restraint. I would not build a pricing architecture on it.

Cadence

The last dial is τ or tau, how often you reprice.

At a critical repricing cadence, price-response gradients do not merely become noisy, they cease to exist. This comes from Wang, Herbert and Gao’s Fractal Landscapes in Policy Optimization, where a system whose Lyapunov exponent exceeds a threshold set by the discount factor yields an objective that is Hölder continuous with exponent below one: continuous, but nowhere differentiable. Remember, if it is not differentiable you cannot apply reinforcement learning, and reinforcement learning is the foundation of modern machine learning.

For design purposes, treat differentiability as a budget you can overspend. Higher C raises the effective Lyapunov exponent. Longer planning horizons push the threshold down. Faster τ samples the chaos more finely. Spend too much on any of the three and every elasticity number your team produces becomes an artifact of its own sampling scale.

The design implication is counterintuitive: there is an optimal repricing frequency and it is lower than your tooling permits. Dynamic pricing vendors sell cadence as pure upside. Past a threshold it destroys the differentiability of the objective the system is trying to climb.

Sequences, not points

One more property, then the process.

Landscapes with hysteresis have memory (hysteresis is the dependence of a system’s output not just on its current input, but also on its past history of inputs). Reference-price research consistently finds asymmetric, loss-averse response to gaps between observed and remembered prices (Krishnamurthi, Mazumdar and Raj), which means raising a price and then restoring it does not restore demand. The terrain depends on the path you walked.

For a pricing designer this converts the deliverable from a position to a trajectory. If the landscape has memory, then the object you are choosing is a sequence of prices and architectures. Price increase programs, migration paths between packaging generations, and grandfathering policies are not implementation details of a pricing decision. They are the pricing decision.

This also means the archive matters as much as the current position, which is where the process picks it up.

The seven laws

Part Two: A Future Process

This thinking can be used to design a pricing process that will be effective with AI and the agent economy. This one has five phases. The phases map onto the four lenses I use to understand and shape my own world: Design Thinking, Value Modelling, Scenario Planning, Concept Blending, Choice Cascade (Roger Martin).

Phase 1: DECLARE

Purpose. Name the fitness function.

This sounds trivial. It is the most commonly skipped step in pricing work and the source of the most expensive errors, because if you do not declare a fitness function you are still optimizing one, just not deliberately. In some ways to defining how to measure winning aspirations in Roger Martin’s strategic choice cascade.

Do this:

1. Write down the scalar you are maximizing, explicitly. Not “growth.” Something computable: three-year gross-margin-weighted contribution, or net revenue retention subject to a gross margin floor, or contribution per unit of scarce inference capacity.

2. Write down the constraints separately from the objective. Confusing them is why pricing committees deadlock.

3. Write down the horizon, and note that it sets γ (gamma) in Law 6. A long horizon is a commitment to a slower cadence, whether you intended that or not.

4. Name the proxies you will actually measure and write the reward-hacking failure mode. If the proxy is quarterly bookings, the failure mode is end-of-quarter discounting. Write it down before it happens, because population-based governance in Phase 5 is your defence and you need to know what you are defending against.

Artifact: the Fitness Declaration. One page. Objective, constraints, horizon, proxies, and the known hacks of each proxy. Signed by whoever owns the P&L, because half the value is forcing that person to choose.

Now that AI has made software a capital-intensive utility, I would add a specific note: if inference capacity is genuinely scarce for you, your fitness function is probably contribution per unit of capacity, not contribution per customer. Those two objectives produce very different landscapes and most AI companies have not yet noticed which one they are on.

Phase 2: SURVEY

Purpose. Measure the terrain you are actually on, before shaping it.

This is the phase nobody does, the one that requires no new data, and the one I think changes practice most. Every measurement below is computable from pricing and transaction history you already have.

1. Estimate correlation length. Take random walks through your historical price-outcome data and compute the autocorrelation of your fitness metric between neighbouring price configurations. Output: the distance over which fitness remains predictable. This is your extrapolation licence — the maximum price move for which a small test tells you anything. My prior, weakly held: most B2B software companies will find this shorter than the size of the price moves they routinely make from small tests.

2. Discover the local optima. Across segments, geographies and packages, find the configurations where every neighbouring configuration performed worse. Multiple well-separated peaks means rugged, and each peak is a candidate architecture you have already accidentally validated.

3. Test differentiability. Use the estimator from Wang, Herbert and Gao: sample your objective at decreasing perturbation scales and regress. If the slope indicates a Hölder exponent below one, your elasticity estimates are sampling artifacts and you should say so out loud in the next pricing review. I am not aware of anyone having run this on commercial pricing data. If you do it, please tell me what you find.

4. Probe hysteresis. Find historical cases where a price moved and came back. Measure whether demand recovered, and how long partial recovery took. Output: a hysteresis half-life. This number governs how reversible your experiments actually are, which most experiment designs assume without checking.

5. Audit coupling. Inventory every mechanism through which a competitor’s price change automatically affects yours: matching guarantees, indexation, MFN clauses, discount triggers. Estimate what fraction of your realized price is determined by rivals rather than by you. This is your CCC, and I expect most firms will be unpleasantly surprised.

6. Assess S and I. How many genuinely independent pricing experiments can you run concurrently, and how long until each reads out? Do you have a maintained value model, or a slide from two years ago? S and I determine what K you are entitled to, so guessing generously here is how you end up with high K and low I, the worst state in the theory.

Artifact: the Terrain Map. Correlation length, local optima census, Hölder exponent, hysteresis half-life, coupling coefficient, and honest SSS and III scores. Refreshed regularly (cadence will depend on the market), because Law 7 says the terrain moves.

This is the deliverable I would most like to see become standard. It is the pricing equivalent of a soil survey before you design the foundation, and right now the industry pours concrete first.

Phase 3: CARVE

Purpose. Choose the coordinate system. Construct the quotient.

This is where value modelling does its real work, and where the four-lens framing pays off: value modelling is landscape estimation, and fence design is quotient construction. An Economic Value Estimation model is not a justification tool. It informs the map of the terrain, which by Law 4 is the space in which your gradients exist.

1. Build or refresh the value model, in distributional form. Point estimates in an EVE model are broken by design, as argued in the first post in this series. Use a Monte Carlo approach to discover the distributions. What you want is not a number but the shape of value across your buyer population. Multimodality tells you where the natural equivalence classes are.

2. Find the perceptual thresholds. Where do buyers stop distinguishing prices? Where are the cliffs — budget authority boundaries, procurement thresholds, psychological round numbers, competitor reference points? These are the boundaries of your equivalence classes, and they are discoverable through research.

3. Design fences on the class boundaries, not across them. A fence that runs along a natural boundary in value perception is nearly free to enforce and reads as fair. A fence that cuts across one generates arbitrage, grey markets, resentment, and support tickets. Most fence design failures are boundary-placement failures.

4. Choose the pricing metric last, and treat it as the coordinate choice it is. The metric determines what “neighbouring price” even means. Get it wrong and every subsequent decision is made in a coordinate system where your landscape is needlessly rugged.

5. Check smoothness in the new coordinates. Re-run the Phase 2 correlation length estimate in the quotient you just built. If it is longer than in dollar coordinates, you have done real work: the terrain is now more navigable for you while remaining opaque to competitors reading your price page.

Artifact: the Coordinate Map. Value distribution by segment, identified perceptual thresholds, fence placements with their boundary rationale, chosen value metric, and the before-and-after correlation length. This is your I, written down.

Phase 4: TUNE

Purpose. Set the dials, to your measured capability rather than your ambition.

1. Set the epistasis budget K. Given S and I from the Terrain Report, decide how much interaction your architecture will carry, and spend it deliberately on the mechanisms with the best legibility-gap return. Bundling and credit structures give the most G per unit of navigational cost, because they are simultaneously high-interaction and highly instrumentable if you own the telemetry. Multi-part tariffs are next. Discount-rule complexity is the worst buy — it raises K while actively lowering I, because nobody can model a discount matrix that has been amended forty times.

2. Aim for moderate, not maximal. Law 3 is explicit: the gap is maximized at intermediate complexity, and intricate architectures resist your own replication as much as rivals’ imitation. If you cannot onboard a new region or product line onto your pricing architecture in a quarter, your K is above your replication capacity and you are paying for defence you are not receiving.

3. Set the external coupling budget C toward zero. Every voluntary coupling mechanism should have to justify its existence against Law 7. Price-matching guarantees in particular are usually sold internally as customer-friendly and are structurally a transfer of your pricing power to your least disciplined competitor.

4. Set the cadence τ (tau) below the differentiability threshold. Use the Hölder estimate from Phase 2. If you cannot compute it, err on the slow side. Separate the cadences: architecture changes should move far more slowly than price levels, which should move more slowly than promotional variation.

5. Fund S and I explicitly, as capability investments with a return. This is the step that makes the theory actionable rather than descriptive. The return on experimentation infrastructure is not “better tests.” It is a higher affordable K, which by Law 1 is a higher reachable peak. That is a defensible business case for pricing infrastructure spend, which pricing teams are chronically bad at making.

Artifact: the Architecture Brief. The chosen N, the K budget with its allocation across mechanisms, the target C, the cadence policy by change type, and the S and I investment plan.

Phase 5: WALK (EXPLORE)

Purpose. Search the landscape you built, without pretending it holds still.

1. Keep an archive, not a roadmap. Define a behavioural descriptor space for pricing architectures — value metric, fence structure, commitment shape, credit mechanics, expiry rules — and maintain the best-performing configuration in each cell, as MAP-Elites does with its niches. Include cells that currently underperform: those are the stepping stones to your next architecture. A roadmap that only advances the current winner is greedy hill climbing with a Gantt chart, and by Law 1 it converges on a low peak.

2. Spend a fixed fraction of experiments on novelty with no fitness argument. Deceptive landscapes are the ones where following the gradient leads away from the global optimum, and the only defence is search that ignores fitness — novelty search’s counterintuitive win. Budget it as a percentage so it survives finance review, in the way R&D budgets survive by being a line item rather than a per-project justification. Ten percent is a defensible starting point and I have no principled basis for that number beyond its being large enough to matter and small enough to approve.

3. Run deliberate, segmented price variance as a smoothing kernel. This is the strongest practical recommendation in the whole series. Variance is not sloppy governance; it is how you construct a differentiable objective, exactly as evolution strategies optimize a smoothed objective by sampling perturbations — the mechanism behind evolutionary strategy’s surprising performance at LLM scale. A single global list price is one sample of a non-differentiable function, and you cannot take a derivative at a point. Set a variance budget as an explicit policy, segmented deliberately rather than randomly, and defend it as instrumentation.

4. Patch the governance. Divide pricing authority into non-overlapping patches — by segment, region, product line, tier — let each optimize somewhat selfishly, and tolerate inconsistency at the seams. Kauffman’s patch procedure beats fully coupled global optimization because total coupling produces the frozen regime, and Levinthal’s finding that tightly coupled organizations fail in changing environments is the same result from the organizational side. Patch size is a real design variable: too small and patches thrash against each other, too large and you freeze. Nobody I know sets it deliberately, and every over-coordinated pricing committee is a patch-size failure.

5. Match your search algorithm to the measured terrain. Long correlation length means gradient methods and tight trust regions are correct and efficient. Short correlation length means you need populations, annealing, Bayesian surrogates and restarts. Bayesian optimization deserves special mention for pricing: expensive per step, very sample-efficient, which is exactly the right trade when each experiment costs real revenue. Bayesian Optimization is a smart search method used to find the highest or lowest point of a hidden, unknown function.

6. Balance speed against breadth according to your environment. Siggelkow and Rivkin’s Speed and Search finds that turbulent environments reward designs emphasizing speed, complex environments reward designs emphasizing broad search, and environments with both require balancing the two — with effects that often run contrary to intuition. Pricing in AI markets is currently both turbulent and complex, which is the hardest cell in their framework and an argument for parallel patches over a single fast central team.

7. Re-survey on a schedule, and treat transformation as expected. Your own moves, rivals’ responses, and buyer memory all reshape the terrain. Refresh the Terrain Report regularly (the cadence will depend on the speed with which your market is changing). This is where scenario planning belongs: not forecasting prices, but forecasting landscape transformation — how the terrain changes under different competitor and buyer-behaviour trajectories. Concept blending is the archive’s recombination operator, the mechanism by which two stepping stones in different niches produce an architecture neither contained.

Artifact: the Pricing Archive. A living record of configurations tried, by descriptor cell, with fitness, and explicit retention of the diverse-but-mediocre entries. Plus the variance policy, the patch map, and the novelty budget.

The four lenses, recovered

The mapping came out cleaner than I expected:

I did not design the lenses to fit this theory — they long predate it. That they map this cleanly is either evidence the theory is on to something or evidence that I am pattern-matching onto my own prior commitments. I genuinely cannot tell.

Part Three: Consequences, ethics, and predictions

The ethics of illegibility

A theory that recommends manufacturing complexity owes an account of where that becomes indefensible. The distinction I would defend is between fencing and obfuscation.

Fencing creates equivalence classes that align price with value. A fence says: buyers who obtain more value contribute more. Fences raise K, create a legibility gap, and leave the buyer able to determine what they are paying and why. Airline fare classes, academic pricing, and volume tiers are all fences. They are legitimate even when complex, because the complexity carries value information.

Obfuscation creates complexity whose function is to prevent the buyer from computing what they are paying for. Non-comparable units, hidden burn rates, expiry rules designed to be forgotten, and drip pricing raise K while destroying buyer I. They generate a legibility gap by lowering the other side’s information rather than raising your own.

Both produce a gap. They are not equivalent, and the difference is not primarily legal. Obfuscation’s returns depend on the buyer’s continued failure to understand, so the gap decays as the buyer learns, and it decays fastest for your best customers. It is a short-duration asset that consumes trust to produce margin. Fencing’s returns depend on the value structure being real, so they persist under scrutiny.

Credit-based pricing sits precisely on this line, which is why I keep writing about it. Credits are the most powerful instrument available in software pricing and also the easiest to abuse. A credit system where the buyer can compute their effective unit cost, forecast their consumption, understand what drives burn, and correlate all of this to the value they will receive, is a fence. A credit system where they cannot is obfuscation. The mechanics can appear to be similar. The test I would apply: can a competent buyer, given your public materials, estimate the value they will receive and compute their expected cost within 20%? If not, you have obfuscation, whether or not you meant to.

And there is a self-interested reason to care beyond ethics. Obfuscation destroys your own I too. Pricing architectures that buyers cannot model are usually architectures the vendor cannot model either — the accreted discount matrix again. High K, low I, on both sides of the table.

The punchline: optimal complexity is about to rise

Now the part that made me want to write this post.

Two decades of pricing advice has converged on simplify. Fewer tiers. Clearer packaging. One pricing metric. That advice was correct, and the theory above explains why: for a firm with three analysts, quarterly test cycles and a stale value model, S and I are low, so affordable K is low, and a complex architecture is a landscape nobody can search. Simplification was the right response to a real capability constraint.

But S and I are binding constraints. AI relaxes both. Simultaneously and not marginally.

S rises because experimentation becomes cheap and parallel: many concurrent tests, agent-run analysis, continuous readout instead of quarterly. Recall Law 2 — the ruggedness at which you do best moves upward with the population of searchers. Skellett’s climbers were a metaphor for pricing teams; now they are almost literal.

III rises because value modelling, usage telemetry, buyer research synthesis and win-loss analysis are exactly the tasks where current AI is strongest. And Law 3 says the complexity that maximizes your legibility gap rises with informational advantage.

Both dials move up together.

The optimal complexity of pricing architecture is going up, not down. The simplification orthodoxy was a capability-constrained result, and AI is melting the constraint.

I expect this to be unpopular. The firms that will have pricing power in five years are not the ones with the cleanest three-tier page. They are the ones that built S and I first and then spent the resulting budget on architecture their competitors cannot navigate.

Buyers are acquiring agents too. An agent buyer searches your landscape at machine cadence with machine patience, which raises their S enormously and collapses the perceptual quotient Q — an agent does not experience $9.99 and $10.00 as different equivalence classes, it experiences them as one cent apart. If Q collapses toward the real line, Law 4 stops working, correlation length shortens toward zero, and the legibility gap has to be rebuilt on something other than perception. I think it gets rebuilt on contract structure and information asymmetry about value delivered rather than on price perception.

Falsifiable predictions

A theory that cannot be wrong is not worth the reading time. Here are predictions I would have to abandon it, or substantially revise it, if they failed. Each is testable with data that exists.

1. Firms with higher experimentation capacity sustain more complex pricing architectures profitably. Measure concurrent-experiment capacity against a complexity index of pricing architecture, controlling for size and category. Law 2 predicts a positive relationship. If complexity is uncorrelated with experimentation capacity, or negatively correlated among successful firms, Law 2 is wrong for pricing. Anthropic is a place to look for this.

2. The relationship between architecture complexity and pricing performance is non-monotonic, peaking at intermediate complexity. Law 3 predicts an inverted U. A monotonic relationship in either direction falsifies the borrowing from Rivkin.

3. Firms with strong value models tolerate more complexity than firms without. The interaction term between value-model maturity and complexity should be positive in explaining margin. This is the sharpest test of Law 3’s information condition, and the one I would most like to see run.

4. Correlation length measured in perceptual-value coordinates exceeds correlation length in dollar coordinates for firms with mature segmentation. This is the direct test of Law 4, the most speculative law. If the quotient does not smooth the terrain, the coordinate-system argument collapses.

5. Firms with high voluntary coupling show shorter correlation lengths and worse elasticity-forecast accuracy. Law 7. Testable within any firm that has both matched and unmatched product lines.

6. Above a computable cadence threshold, the Hölder exponent of the pricing objective drops below one, and elasticity estimates become scale-dependent. Law 6, and the most directly falsifiable of the set, using Wang, Herbert and Gao’s own estimator on repricing logs. If elasticity estimates prove scale-invariant in fast-repricing reactive markets, the fractal argument does not transfer from control theory to pricing and I will drop it.

I would rather this theory be tested and found wrong in specific places than admired and left alone. If you have the data for any of these, I would like to hear about it, including and especially if the answer is no. Email me at steven@patternmind.studio.

Takeaways

Price is a probability distribution, not a number. That distribution lives on a landscape which is rugged, coevolving, and partly of your own making. Pricing design is the engineering of that landscape and of your differential ability to navigate it.

Value is the landscape. Price is the walk. Pricing power is knowing the coordinates.

References

Assad, Stephanie, Robert Clark, Daniel Ershov and Lei Xu (2020) “Algorithmic Pricing and Competition: Empirical Evidence from the German Retail Gasoline Market.” Queen’s Economics Department Working Paper No. 1438.

Ethiraj, Sendil K. and Daniel Levinthal (2004) “Modularity and Innovation in Complex Systems.” Management Science, 50(2), pp. 159–173.

Frenken, Koen (2006) “A fitness landscape approach to technological complexity, modularity, and vertical disintegration.” Structural Change and Economic Dynamics, 17(3), pp. 288–305.

Kauffman, Stuart (1993) The Origins of Order: Self Organization and Selection in Evolution. Oxford University Press.

Kauffman, Stuart (1995) At Home in the Universe. Oxford University Press. Source of the patch procedure.

Kauffman, Stuart A. and Sönke Johnsen (1991) “Coevolution to the edge of chaos: coupled fitness landscapes, poised states, and coevolutionary avalanches.” Journal of Theoretical Biology, 149(4), pp. 467–505.

Krishnamurthi, Lakshman, Tridib Mazumdar and S. P. Raj (1992) “Asymmetric Response to Price in Consumer Brand Choice and Purchase Quantity Decisions.” Journal of Consumer Research, 19(3), pp. 387–400.

Levinthal, Daniel A. (1997) “Adaptation on Rugged Landscapes.” Management Science, 43(7), pp. 934–950.

Nordmoen, Jørgen, Frank Veenstra, Kai Olav Ellefsen and Kyrre Glette (2021) “MAP-Elites Enables Powerful Stepping Stones and Diversity for Modular Robotics.” Frontiers in Robotics and AI.

Phillips, Robert L. (2005) Pricing and Revenue Optimization. Stanford Business Books.

Qiu, Xin, Yulu Gan, Conor F. Hayes, Qiyao Liang, Yinggan Xu, Roberto Dailey, Elliot Meyerson, Babak Hodjat and Risto Miikkulainen (2025) “Evolution Strategies at Scale: LLM Fine-Tuning Beyond Reinforcement Learning.” arXiv:2509.24372.

Rivkin, Jan W. (2000) “Imitation of Complex Strategies.” Management Science, 46(6), pp. 824–844.

Rivkin, Jan W. (2001) “Reproducing Knowledge: Replication Without Imitation at Moderate Complexity.” Organization Science, 12(3), pp. 274–293.

Siggelkow, Nicolaj and Jan W. Rivkin (2005) “Speed and Search: Designing Organizations for Turbulence and Complexity.” Organization Science, 16(2), pp. 101–122.

Skellett, Benjamin, Benjamin Cairns, Nicholas Geard, Bradley Tonkes and Janet Wiles (2005) “Maximally Rugged NK Landscapes Contain the Highest Peaks.” GECCO ‘05.

Stadler, Peter F. (1995) “Landscapes and Their Correlation Functions.” Santa Fe Institute.

Sutton, Richard S. and Andrew G. Barto (2018) Reinforcement Learning: An Introduction, 2nd Edition. Bradford Books.

Wang, Tao, Sylvia Herbert and Sicun Gao (2023) “Fractal Landscapes in Policy Optimization.” NeurIPS 2023.

Zou, Feng, Debao Chen, Hui Liu, Siyu Cao, Xuying Ji and Yan Zhang (2022) “A survey of fitness landscape analysis for optimization.” Neurocomputing, 503, pp. 129–139.

The second of a series of technical deep dives into what I see as the key conceptual issues in pricing. This post is a first exploration of some critical ideas from biology and evolution plus reinforcement learning. with their applications to pricing. It is a step towards thinking through value and pricing as a complex adaptive system. The next post, also published today, is Pricing design is fitness landscape engineering: A theory of pricing power with a process for building it. The second post is my guess on where pricing design will go in the next decade in response to the market changes and new capabilities brought by AI. It is highly speculative.

This post is for hardcore pricing geeks. The first post in this series was Price is Not a Number: It is a Probability Distribution. That post was about the need to change how we think about pricing from point numbers (scalars) to distributions. This is part of the larger change being asked of us by them move to generative AI, which is probabilistic in nature and not deterministic.

I would read this and the next post with the help of an AI. Load it into your agent or provide it as context and have a conversation with your AI about it. Share your prompts in the comments!

TL;DR

The core claim

• Pricing optimization assumes a smooth fitness landscape with one peak. Most real pricing landscapes are rugged. The act of pricing transforms the fitness landscape you are searching.

• You should not want a smooth landscape. A smooth pricing landscape means your competitors can find your peak by walking uphill themselves from anywhere on the landscape. Smoothness signals a commodity.

Ruggedness is where the value is

• In Stuart Kauffman’s NK framework (see below), ruggedness is tuned by NKC, the number of interactions between components. In pricing, NKC is set by packaging, fencing, bundling, and metric choice. It is a design variable, not a fact about the market.

• Maximally rugged landscapes contain the highest peaks. The catch is that you need enough parallel searchers to find them. Optimal ruggedness rises with your experimental capacity.

Smooth landscapes are usually an artifact

• Aggregation is a low-pass filter. Averaging across segments smooths rugged landscapes into tidy demand curves. The smooth curve is a measurement artifact, not a market property.

• Price space is not a metric space. The distance between $9.99 and $10.00 is not one cent; it is crossing a threshold. Ruggedness depends on which space you measure in.

What to do instead of hill climbing

• Inject deliberate, segmented price variance — not to find the optimum, but to construct a differentiable objective. This is what evolution strategies do, and why they now beat policy-gradient RL (Reinforcement Learning) on jagged, sparse, outcome-only rewards.

• Replace the pricing roadmap with an archive. MAP-Elites, not gradient ascent: maintain a portfolio of high-performing pricing models across a behavioural descriptor space and treat each as a stepping stone. (MAP-Elites stands for Multi-dimensional Archive of Phenotypic Elites, an artificial intelligence search and optimization algorithm.)

• Use Kauffman’s patch procedure on pricing governance. Slightly selfish, loosely coupled pricing patches outperform a fully coupled global optimization. Kauffman's patch procedure means giving specific product lines or agents the freedom to optimize their own pricing. These loosely coupled local strategies compete and adjust to boundary conflicts that will actually generate higher total revenue and faster adaptation than trying to rigidly control everything from a centralized headquarters.

The reframe

• Shaping willingness to pay is landscape engineering (pricing and packaging shape the fitness landscape). Optimizing to willingness to pay is hill climbing on terrain you could have built yourself.

• Value is the landscape. Price is the walk. Both are moving.

Key Concepts from Complex Adaptive Systems for Pricing

(see the Glossary after the References for a complete list)

Fitness. How well something does. In biology, expected reproductive success. In pricing, whatever you are actually trying to maximize.

Landscape (fitness landscape). A map from every possible configuration to the fitness of that configuration. Picture a terrain: horizontal position is what you can change (price, packaging, metric, fences), height is how well you do.

Peak (local optimum). A point where every immediate neighbour is worse. Standing on one feels exactly like success, which is the whole problem.

Global optimum. The highest peak on the entire landscape. There is only one, and you generally cannot tell whether you are on it.

Valley. A low-fitness region between peaks. To get from one peak to a higher one you usually have to cross a valley, which means deliberately accepting worse performance for a while. Very few organizations will fund this.

Search. The process of moving across the landscape looking for higher fitness. Every price test, packaging change and experiment is a search step. “Optimization algorithm” and “search strategy” are the same thing said twice.

Smooth landscape. One peak. Small changes produce small, predictable changes in fitness. Walking uphill from anywhere gets you to the top.

Rugged landscape. Many peaks separated by valleys. Small changes can produce large, unpredictable jumps in fitness. Walking uphill gets you to a top, usually not the best one.

Basin of attraction. The set of starting points from which simple uphill walking leads to a particular peak. A large basin around the global optimum means forgiving terrain.

N — the number of components in the system. In pricing, the number of things you can independently set: price points, tier boundaries, metrics, fences, discount rules.

K — the number of other components each component interacts with. This is the ruggedness dial.

NKC (also written NKCS). Extension of NK to coevolution. C is the number of components in another actor’s system that affect your fitness. Multiple NK landscapes are coupled together, so a move by one species transforms the landscape of the others. This is the formal model behind the entire “pricing actions change the landscape” section.

Coevolution. Two or more populations evolving in response to each other, where each one’s adaptation changes the selective environment of the others. The landscape is not terrain you walk on; it is terrain that reshapes as you and everyone else walk on it. Competitive repricing is coevolution. So is portfolio cannibalization — a firm coevolving against itself.

Most pricing optimization is trying to answer the wrong question.

“Given a landscape of prices and payoffs, where is the peak?”

The unchecked assumption is that there is a peak, singular, and that you can get to it by local improvements. Raise price 2%, watch volume, adjust, repeat. This works on a smooth fitness landscape. It is worse than useless on a rugged one, because on a rugged landscape local improvement can be a trap.

Many people in pricing are focused on pricing optimization. This generally means the price point that maximizes revenue, or profit, or capacity utilization and load management — the last of these is about to matter more now that AI has made software a capital-intensive utility. Sometimes it means setting prices as close as possible to customer willingness to pay (WTP). This is generally a mistake. The goal is to shape willingness to pay, not to optimize against it. Mark Stiving puts this well in Buyer Insight: Willingness to Pay Isn’t About Your Product. “Willingness to pay is not stable. It changes across buyers, across situations, and even within the same deal. That’s because: The real driver is value, specifically value as the buyer sees it.”

Shaping willingness to pay is not a better search strategy. It is a refusal to treat the fitness landscape as a given.

Smooth versus rugged

The vocabulary comes from evolutionary biology, mostly from Stuart Kauffman’s NK model, which he described as a “tunably rugged” fitness landscape (NK model). N is the number of components. K is the number of other components each one interacts with. At K=0K = 0K=0 every component contributes to fitness independently and you get a smooth, single-peaked landscape. As K rises, contributions become interdependent, and the landscape erodes into what Kauffman called the badlands: many peaks, deep valleys, no reliable path uphill.

A smooth pricing landscape looks like this. Every 2% price increase costs you roughly the same 3% of volume. Profit against price is a single clean hump. Your price changes do not summon competitor responses. A $0.50 test predicts a $5.00 move. Moving from $9.99 to $10.05 barely registers.

A rugged one looks like this. Moving from $19.99 to $20.00 drops volume 40% overnight. A few cents triggers a cascade of automated competitor repricing. You make excellent profit at $45, terrible profit at $55, excellent profit again at $75. If you raise price and then put it back, sales do not return — the landscape remembers the path. Tweaking Product A’s price sends chaotic spikes and drops through Products B and C.

Which one describes your business?

How to measure ruggedness

There is already research on this in academic circles. Zou and colleagues survey it in A survey of fitness landscape analysis for optimization. The foundational work on correlation structure is Stadler’s Landscapes and Their Correlation Functions. Three families of measurement matter for value and pricing.

Statistical and correlation measures. Run a random walk across the landscape and compute the autocorrelation function of fitness. High correlation between consecutive steps means neighbours resemble each other, which means a smooth landscape. The correlation length derived from that function tells you how far you can move before the landscape forgets where you were. Smooth landscapes have long correlation lengths. The roughness-to-slope ratio measures how far the landscape deviates from a purely additive linear model — lower is smoother and more predictable.

Correlation length is the single most useful of these metrics for pricing; almost nobody computes it. It answers a question every pricing team should be able to answer: how big a price move can I extrapolate from a small test? That number can be estimated from your own historical price and volume data.

Topological and structural features. Count local optima — points where every immediate neighbour is worse. One peak means smooth. Then measure the basin of attraction: what fraction of random starting prices leads to the global peak under simple uphill improvement? Large basins mean a forgiving structure.

Path-based and dynamic metrics. Count selectively accessible paths — monotonically improving routes from a start point to the global maximum. Track adaptive walk length, the average number of steps before a searcher gets stuck. Smooth landscapes have many accessible paths and long walks, because nothing interrupts the climb.

If your landscape is smooth, the classic pricing toolkit is correct and efficient: gradient ascent, Newton-Raphson, hill climbing, Nelder-Mead simplex, quadratic regression solved for its vertex. Robert Phillips’ Pricing and Revenue Optimization is essentially the mature engineering of this case, and where it applies it applies well.

If your landscape is rugged, that toolkit will deliver you into a local trap. What you need instead uses randomness, memory, and parallelism: genetic algorithms, simulated annealing, particle swarm optimization, Bayesian optimization, tabu search, random-restart hill climbing. Terry Jones’ Evolutionary Algorithms, Fitness Landscapes and Search is the clearest account of why landscape structure and algorithm choice are the same question.

Notice the asymmetry in that last row. On a smooth landscape you fail by being slow. On a rugged landscape you fail by being certain. The second failure is far more expensive and far harder to detect, because a local optimum looks like a global optimum from where you are standing. Every immediate neighbour is worse. Your dashboard is green.

You should want to operate on a rugged landscape

Here is where I part company with most of pricing optimization practice.

Skellett and colleagues have an important result that people in pricing should understand: Maximally Rugged NK Landscapes Contain the Highest Peaks. As K rises toward N−1, the expected height of the global optimum rises too. Under a Gaussian approximation the most likely global optimum in the maximally rugged case approaches roughly 0.84 as N grows, against 2/3 for the fully additive K=0 case. Rugged landscapes are taller.

The catch is who can reach those peaks. In their experiments with N=8, a single hill climber does best at K=2 — barely rugged. Push ruggedness higher and the lone climber’s expected result degrades, even though the true peak is higher. But as you increase the population of climbers, the ruggedness at which you achieve the best result moves upward. At maximal ruggedness the number of climbers needed to reliably find the global optimum approaches N the entire landscape. In SaaS world this would have been interesting to know but impossible to action. In the agent economy exploration strategies will dominate.

The optimal ruggedness is a function of search capacity.

A smooth pricing landscape is a landscape where a single competitor with one analyst and a spreadsheet finds the same peak you did. There is no informational advantage in a smooth market. Everyone climbs, everyone arrives, margins compress, and the peak height is 2/3 or what it could be in a rogher market with more local optmia. Commodity pricing is not caused by commodity products. It is caused by smooth landscapes.

A rugged landscape has higher peaks and hides them. Whoever can afford more parallel search captures the difference. If you can run forty simultaneous pricing experiments across segments, using different versions of your agents, testing value metrics and price levels, and your competitor can only run three, then ruggedness becomes your moat.

And we know how to manufacture it, because we do it accidentally all the time. Bundling creates local peaks. Fencing creates local peaks. Multi-part tariffs, commitment tiers, credit pools with expiry rules, cross-product entitlements, usage metrics that interact with seat counts, all of these increase K. Each makes the landscape harder for you to search, harder for everyone to search. Frenken’s fitness landscape approach to technological complexity, modularity, and vertical disintegration works the same logic through industry architecture: how you modularize determines the landscape everyone then has to search.

The uncomfortable corollary is that most pricing simplification advice is advice to flatten your own landscape. Sometimes that is right, because you cannot search what you cannot afford to search. But it should be an explicit tradeoff, priced out, not a reflex.

Your smooth landscape is probably an artifact

Before anyone concludes their landscape is genuinely smooth, consider how smoothness is manufactured by measurement.

Aggregation is a low-pass filter. Add together many segment-level demand responses, each with its own thresholds, reference prices and cliff edges, and the cliffs cancel. What survives is a smooth curve that describes no actual buyer. This is the same machinery as Simpson’s paradox, which I wrote about in the first post in this series: an aggregate trend that reverses inside subgroups always has a lurking variable. A smooth aggregate demand curve over rugged segment landscapes has one too. It is called segmentation.

So the tidy elasticity curve in your consultant found is not evidence of a smooth landscape. It is evidence that you averaged over the structure you needed to see.

There is a deeper problem.

A fitness landscape requires two things: a scalar fitness and a metric on the space of variants, so that “neighbour” means something. Biology gets the second one nearly free — mutation defines adjacency. Pricing does not. We casually assume price space inherits the metric of the real numbers, so that $9.99 and $10.00 are one cent apart and therefore neighbours. Buyers do not experience it that way. In perception, $9.99 and $10.00 sit in different equivalence classes, while $10.00 and $10.05 sit in the same one.

Ruggedness is not invariant under change of space. A landscape that is discontinuous in dollars may be smooth in the perceptual quotient: the “cliff” at $20 is simply the boundary between two adjacent classes and the walk across it is one clean step. The reverse also happens. So the honest version of “is my landscape rugged” is “rugged with respect to which metric?” The pricing analyst’s job includes choosing, and sometimes constructing, that metric. Fences, tiers and packaging are literally the construction of equivalence classes. Do it well and you smooth the terrain you have to walk while leaving it rugged for everyone else.

Pricing actions shape the landscape

The fitness landscape metaphor smuggles in a static terrain. Pricing has no such thing. Every price action is simultaneously a search step and an edit to the search space. Here are five ways in which pricing reshapes the fitness landscape.

Competitor feedback loops alter ruggedness. Find a peak at $49 on a static landscape and you stay there. In a live market your move causes rivals to change their own pricing. A smooth landscape deforms into a hyper-rugged one, with new valleys where you are undercut and new peaks where bundling or niche positioning becomes the only profitable move.

Psychological anchors alter the slope. Price signals quality. Drop a tool from $500/month to $50/month and buyers read it as cheap or broken. Reference-price research consistently finds asymmetric, loss-averse response to gaps between observed and remembered prices, as in Krishnamurthi, Mazumdar and Raj’s work on asymmetric response to price in consumer brand choice. The landscape develops a fitness cliff and raising the price back to $500 does not restore the old peak. The terrain depends on the path you walked across it.

Algorithmic response flattens or steepens peaks. When multiple firms run learning pricing systems, each adjustment is an environmental shock to the others. Calvano, Calzolari, Denicolò and Pastorello showed in Artificial Intelligence, Algorithmic Pricing, and Collusion that Q-learning agents “consistently learn to charge supracompetitive prices, without communicating with one another,” sustained by punishment-and-forgiveness strategies they were never taught. The field evidence points the same way: Assad, Clark, Ershov and Xu found in the German retail gasoline market that adoption raised station margins by about 9%, and in duopolies where both stations adopted, market-level margins rose roughly 28%. Tacit collusion fills in the valleys and builds an artificial shared plateau. A price war does the opposite and erodes the mountain into a zero-margin desert.

Portfolio interactions creates local traps. Lower the price of the base model and you steal from your own premium model. This is self-inflicted coevolution, and it injects roughness directly into your own pricing model. A single smooth peak fractures into a maze of local optima where maximizing Product A collapses Product B.

Purchase-timing fatigue sinks the global peak. If buyers notice prices moving hourly, they stop buying impulsively and start timing the market, or leave for a fixed-price competitor. (In SaaS we saw something similar, where smart buyers waited unto the end of quarter to commit.) This does not move you on the landscape. It lowers the height of every peak. The pricing action bred distrust, and the whole hill slides down to a lower terrace.

Put those together and “pricing optimization” is revealed as a category error. You are not optimizing on a landscape. You are in a coevolutionary process where your search reshapes the space, your competitors’ searches transforms it further, and your buyers’ memories make things rough. Kauffman’s Origins of Order and McGhee’s Geometry of Evolution are both, in the end, about this: the landscape and the population that walks it are one system.

What to do about it

This is where reinforcement learning becomes more than an analogy, because the RL community has spent a decade discovering that its landscapes are rugged too, and has built things that work. And our current Large Language Models are all built with reinforcement learning.

Inject variance to construct a gradient. Evolution strategies treat the policy as a black box, sample a population of parameter perturbations, and move toward the better ones. The subtle point is that these strategies do not optimize the true objectives; they optimize a smoothed version, the expected reward under a perturbation distribution. Noise is a convolution kernel. It manufactures differentiability where none existed (reinforcement learning requires measurements that can be differentiated, that is, a slope can be defined). This is why Qiu and colleagues at Cognizant AI Lab were able to report in Evolution Strategies at Scale that ES fine-tunes full billion-parameter LLMs and beats established RL implementations on tolerance to long-horizon and delayed rewards, stability, and resistance to reward hacking.

Deliberate, segmented price variance is not sloppy governance. It is a smoothing kernel. In the first post in this series I argued that deliberate segmented variance is a sensing mechanism while random variance is just noise. I would now put it more strongly: you randomize prices in order to have a differentiable objective at all. A single global list price is a single sample of a non-differentiable function, and you cannot take a derivative at a point.

Reward hacking has an exact pricing analogue, too. Optimize a revenue proxy and your sales organization will find the trajectory that maximizes the proxy while destroying what it stood for — end-of-quarter discounting, multi-year prepays that mortgage next year, usage-metric gaming. That population-based methods resist reward hacking better than gradient methods is not a technical footnote. It is an argument for portfolio-based pricing governance.

Keep an archive, not a roadmap. Quality-diversity algorithms like MAP-Elites abandon the single objective and maintain a grid of the best solution found in each cell of a behavioural descriptor space. The diverse archive functions as stepping stones to regions a greedy search would never reach. Novelty search goes further and rewards behavioural dissimilarity while ignoring fitness entirely, which is how it escapes deceptive gradients. Surprise search rewards divergence from predicted behaviour rather than from past behaviour; Gravina, Liapis and Yannakakis showed it matching novelty search and beating objective-based search in maze navigation.

Build the pricing equivalent. Define a descriptor space — value metric, fence structure, commitment shape, prepayment mechanics, expiry rules — and maintain the best-performing pricing model in each cell, including cells that currently underperform. Those are your stepping stones for the next architecture. A pricing roadmap that only advances the current winner is greedy hill climbing and will not win in the long run.

Take the deceptive-gradient point seriously. Sometimes the right move is to fund a pricing experiment because it is unlike anything you have tried, with no fitness argument. That is nearly impossible to get through a finance review, which is why it is a source of advantage.

Patch your governance. Kauffman’s patch procedure: take a hard, conflict-laden problem where many parts interact, divide it into non-overlapping patches, and let each patch optimize selfishly. Under the right patch size the whole system finds better solutions faster than a fully coupled global optimization — because total coupling means every local improvement breaks something elsewhere, and the system freezes.

Most pricing organizations are over-coupled. Every price change routes through a committee that must reconcile all interactions, which produces the frozen regime: nothing moves because everything is connected to everything. The fix is not more coordination. It is choosing patch boundaries — by segment, region, product line, customer tier or use case — and letting each patch climb its own hill with tolerated inconsistency at the seams. Patch size is the design variable. Too small and patches thrash around and nver optimize; too large and you freeze. Nobody I know sets this deliberately.

Match the algorithm to the measured terrain, not to the fashion. Measure correlation length first. If correlation length is long, gradient methods and tight trust regions are right, and trust-region policy methods work for the same reason: the local surrogate tracks the true objective. If correlation length is short, you need annealing, populations, Bayesian surrogates, restarts. Some methods now use reinforcement learning to select mutation strategies based on estimated ruggedness. This is the pattern to copy: estimate the terrain, then set your exploration rate.

The fold

The first post in this series argued that price is not a number but a probability distribution, and that our job is to shape distributions rather than set points.

This post adds the second half. That distribution lives on a landscape, the landscape is rugged, the ruggedness is partly your own design, and the landscape transforms as you walk on it — reshaped by competitors, by buyer memory, by your own portfolio, and by the measurement itself.

Which means the objective of pricing practice is not a price, and not even a distribution. It is a distribution over a landscape that your sampling reshapes. Value is the landscape. Price is the walk. Both are moving, and the walk changes the ground.

Two positions to close on, both of which I hold loosely.

First: if your pricing landscape is smooth, that is not good news. Either you have aggregated away the structure, or you are in a commodity market with 2/3-height peaks that anyone can climb. Go looking for the roughness and variation you have been trying to eliminate.

Second: stop asking what the optimal price is. Ask what K (level of connectedness) you can afford. That number — how much interaction complexity your search capacity can profitably support — is the pricing decision that determines all the others.

Next in this series: what happens to all of this when the buyer is an agent, searching the same landscape at machine cadence, and the correlation length collapses.

References

Assad, Stephanie, Robert Clark, Daniel Ershov and Lei Xu (2020) “Algorithmic Pricing and Competition: Empirical Evidence from the German Retail Gasoline Market.” Queen’s Economics Department Working Paper No. 1438.

Calvano, Emilio, Giacomo Calzolari, Vincenzo Denicolò and Sergio Pastorello (2020) “Artificial Intelligence, Algorithmic Pricing, and Collusion.” American Economic Review, 110(10), pp. 3267–97.

Frenken, Koen (2006) “A fitness landscape approach to technological complexity, modularity, and vertical disintegration.” Structural Change and Economic Dynamics, 17(3), pp. 288–305.

Gravina, Daniele, Antonios Liapis and Georgios N. Yannakakis (2016) “Surprise Search: Beyond Objectives and Novelty.” GECCO ‘16.

Jones, Terry (1995) “Evolutionary Algorithms, Fitness Landscapes and Search.” Santa Fe Institute.

Kauffman, Stuart (1993) The Origins of Order: Self Organization and Selection in Evolution. Oxford University Press.

Kauffman, Stuart (1995) At Home in the Universe. Oxford University Press. (Source of the patch procedure.)

Krishnamurthi, Lakshman, Tridib Mazumdar and S. P. Raj (1992) “Asymmetric Response to Price in Consumer Brand Choice and Purchase Quantity Decisions.” Journal of Consumer Research, 19(3), pp. 387–400.

Manokhin, Valeriy (2026) Mastering Modern Time Series Forecasting: A Comprehensive Guide to Statistical, Machine Learning, and Deep Learning Models in Python.

McGhee, George (2007) The Geometry of Evolution: Adaptive Landscapes and Theoretical Morphospaces. Cambridge University Press.

Nordmoen, Jørgen, Frank Veenstra, Kai Olav Ellefsen and Kyrre Glette (2021) “MAP-Elites Enables Powerful Stepping Stones and Diversity for Modular Robotics.” Frontiers in Robotics and AI.

Phillips, Robert L. (2005) Pricing and Revenue Optimization. Stanford Business Books.

Qiu, Xin, Yulu Gan, Conor F. Hayes, Qiyao Liang, Yinggan Xu, Roberto Dailey, Elliot Meyerson, Babak Hodjat and Risto Miikkulainen (2025) “Evolution Strategies at Scale: LLM Fine-Tuning Beyond Reinforcement Learning.” arXiv:2509.24372.

Skellett, Benjamin, Benjamin Cairns, Nicholas Geard, Bradley Tonkes and Janet Wiles (2005) “Maximally Rugged NK Landscapes Contain the Highest Peaks.” GECCO ‘05.

Stadler, Peter F. (1995) “Landscapes and Their Correlation Functions.” Santa Fe Institute.

Stiving, Mark “Buyer Insight: Willingness to Pay Isn’t About Your Product.”

Sutton, Richard S. and Andrew G. Barto (2018) Reinforcement Learning: An Introduction, 2nd Edition. Bradford Books.

Wang, Tao, Sylvia Herbert and Sicun Gao (2023) “Fractal Landscapes in Policy Optimization.” NeurIPS 2023.

Zou, Feng, Debao Chen, Hui Liu, Siyu Cao, Xuying Ji and Yan Zhang (2022) “A survey of fitness landscape analysis for optimization.” Neurocomputing, 503, pp. 129–139.

A pricing geek’s glossary of fitness landscapes

Terms from evolutionary biology, optimization theory and reinforcement learning, with their pricing translations.

I am using a lot of borrowed concepts and vocabulary. Fitness, epistasis, correlation length, basin of attraction, NKC, mollification. None of this language was built for pricing, which is why it is useful. It comes from fields that have spent decades on problems structurally identical to ours and have vocabulary we lack.

So here are the terms, in plain language, each with its pricing translation where one exists.

Two notes on how to read this. First, the entries are grouped rather than alphabetized, because these concepts only make sense in relation to each other — reading straight through is a reasonable way to absorb the argument. Second, several entries make claims rather than just definitions. Where a definition carries an argument I have left the argument in. A glossary that pretends to be neutral is usually hiding its assumptions.

The basic picture

Fitness. How well something does. In biology, expected reproductive success. In pricing, whatever you are actually trying to maximize — profit, revenue, contribution margin, net revenue retention, capacity utilization. The discipline that matters here is naming your fitness function out loud, because if you do not, you are optimizing something by accident.

Landscape (fitness landscape). A map from every possible configuration to the fitness of that configuration. Picture a terrain: horizontal position is what you can change (price, packaging, metric, fences), height is how well you do. Introduced by Sewall Wright in the 1930s to visualize evolution. In pricing, the landscape is every price and packaging combination you could choose, each with a profit attached.

Peak (local optimum). A point where every immediate neighbour is worse. Standing on one feels exactly like success, which is the whole problem.

Global optimum. The highest peak on the entire landscape. There is only one, and you generally cannot tell whether you are on it.

Valley. A low-fitness region between peaks. To get from one peak to a higher one you usually have to cross a valley, which means deliberately accepting worse performance for a while. Very few organizations will fund this.

Search. The process of moving across the landscape looking for higher fitness. Every price test, packaging change and experiment is a search step. “Optimization algorithm” and “search strategy” are the same thing said twice.

Neighbour / adjacency. Which configurations count as one step away from where you are. Biology gets this free from mutation. Pricing does not — whether $9.99 and $10.00 are neighbours is a question about buyer perception, not arithmetic.

Smooth versus rugged

Smooth landscape. One peak. Small changes produce small, predictable changes in fitness. Walking uphill from anywhere gets you to the top. Kauffman called this a Fujiyama landscape — a single symmetrical mountain.

Rugged landscape. Many peaks separated by valleys. Small changes can produce large, unpredictable jumps in fitness. Walking uphill gets you to a top, usually not the best one. Kauffman called the extreme version badlands.

Ruggedness. How much fitness changes between neighbouring configurations. A measurable property, not a vibe, and the central quantity in this post.

Epistasis. When the contribution of one component depends on the settings of others. From genetics: the effect of one gene depends on which other genes are present. In pricing, epistasis is bundling, fencing, tiering, cross-product entitlements — anything where the right price for A depends on what you did with B. Epistasis is the cause of ruggedness. More interaction, more peaks.

Correlation length. How far you can move across the landscape before fitness stops resembling where you started. Long means smooth and extrapolable. Short means a small test tells you nothing about a large move. This is the metric I most wish pricing teams computed.

Autocorrelation function. The tool used to estimate correlation length: take a random walk across the landscape and measure how correlated fitness is between consecutive steps.

Basin of attraction. The set of starting points from which simple uphill walking leads to a particular peak. A large basin around the global optimum means forgiving terrain.

Adaptive walk. A path of successive improving steps until no improving step exists. Adaptive walk length is how many steps you get before being stuck; longer walks indicate smoother terrain.

Hysteresis. Path dependence. The system’s current state depends on how it got there, not just where it is. In pricing: raise a price then lower it back, and demand does not return, because buyer reference prices have moved. The landscape remembers your walk.

The NK family of models

NK model. Stuart Kauffman’s model of a “tunably rugged” fitness landscape, and the source of most of the vocabulary above. Two parameters:

• N — the number of components in the system. In pricing, the number of things you can independently set: price points, tier boundaries, metrics, fences, discount rules.

• K — the number of other components each component interacts with. This is the ruggedness dial.

At K=0 every component contributes independently and the landscape is smooth with a single peak. As K rises the landscape becomes progressively more rugged. At K=N−1 everything depends on everything, ruggedness is maximal. The central claim of this post is that K in pricing is a design choice, not a fact of nature.

NKC (also written NKCS). Kauffman’s extension of NK to coevolution. C is the number of components in another actor’s system that affect your fitness. Multiple NK landscapes are coupled together, so a move by one species deforms the landscape of the others. This is the formal model behind the entire “pricing actions change the landscape” section — you and your competitors are coupled landscapes, and C is the coupling strength. Worth knowing that the co-evolutionary extension is NKC, not any other three-letter arrangement.

Coevolution. Two or more populations evolving in response to each other, where each one’s adaptation changes the selective environment of the others. The landscape is not terrain you walk on; it is terrain that reshapes as you and everyone else walk on it. Competitive repricing is co-evolution. So is portfolio cannibalization — a firm co-evolving against itself.

Red Queen dynamics. The consequence of co-evolution: everyone runs hard and nobody gains ground, because every improvement is matched. Named for the Red Queen in Through the Looking-Glass. Price wars are Red Queen dynamics.

Patch procedure. Kauffman’s practical trick for hard, highly coupled problems. Break the system into non-overlapping patches, let each optimize selfishly, tolerate inconsistency at the boundaries. Counterintuitively this beats fully coupled global optimization, because total coupling freezes the system.

Frozen regime. What happens when coupling is too high: every local improvement breaks something else, so nothing moves. The failure mode of over-coordinated pricing committees.

Search strategies

Hill climbing. Test nearby points, step to the best one, repeat. The simplest search. Optimal on smooth landscapes, reliably trapped on rugged ones.

Gradient ascent / descent. Hill climbing with calculus — compute the local slope and move along it. Requires the landscape to be differentiable, which this post argues is sometimes not the case.

Gradient. The direction and steepness of the local slope. An elasticity estimate is a gradient estimate.

Exploitation. Doubling down on the best thing you have found. Exploration. Trying things that are probably worse, to learn what is out there. The exploration/exploitation tradeoff is the core tension in all search. On a genuinely smooth landscape there is no tradeoff, because local improvement is globally correct.

Simulated annealing. Search that initially accepts bad moves readily and gradually becomes pickier, borrowed from cooling metal slowly to remove defects. The early randomness lets it escape valleys.

Genetic algorithm. Maintain a population of candidate solutions, keep the better ones, recombine and mutate them, repeat. Search as breeding.

Evolution strategies (ES). A population-based method that treats the system as a black box: sample many random perturbations of the current configuration and move toward the ones that performed better. It never computes a derivative. Crucially it optimizes a smoothed version of the objective — average fitness under random perturbation — which is why noise can manufacture a usable gradient where none exists.

Particle swarm optimization. Send many searchers across the landscape at once and let them share what they find.

Bayesian optimization. Build a probabilistic model of the landscape from the points sampled so far, use it to predict where high peaks are likely to hide, sample there, update. Expensive per step, very sample-efficient — the right choice when each experiment costs real money.

Tabu search. Keep a memory of where you have already been and forbid returning, which prevents cycling.

Random restart. Run simple hill climbs from many random starting points and keep the best result. Crude, parallel, and surprisingly effective on rugged terrain.

Trust region. A bound on how far a single step may go, on the logic that your local model of the landscape is only credible nearby. TRPO and PPO in reinforcement learning are trust-region methods. A policy of “no more than 7% price change per year” is an informal trust region.

Niching / speciation. Enforcing local competition among similar candidates so several distinct lineages survive rather than one taking over. Deliberately slows convergence, which often speeds up finding the global optimum.

Quality-diversity and novelty

Quality-diversity (QD). A family of algorithms that refuse to return a single answer, instead maintaining a collection of high-performing solutions that are meaningfully different from one another.

MAP-Elites. The best-known QD algorithm. Divide a descriptor space into cells, keep the fittest solution found in each cell, use the whole archive as raw material for further search.

Behavioural descriptor space. The dimensions along which you consider solutions different — not their fitness, but their character. For pricing: value metric, fence structure, commitment shape, expiry rules.

Stepping stone. A solution that is not itself good but leads somewhere good. QD’s core insight is that archives of mediocre-but-different solutions are the raw material for breakthroughs.

Deceptive landscape. A landscape where following the fitness gradient leads actively away from the global optimum. Not merely rugged — misleading. The reason novelty search exists.

Novelty search. Search that ignores fitness entirely and rewards being behaviourally different from everything tried before. Sounds absurd; outperforms objective-driven search on deceptive problems.

Surprise search. A variant that rewards divergence from predicted behaviour rather than from past behaviour. It rewards violated expectations rather than mere difference.

Reinforcement learning terms

Reinforcement learning (RL). Learning to act by trying actions and observing rewards, rather than by being shown correct answers.

Policy. The rule mapping situations to actions. A pricing policy in the ordinary business sense is literally a policy in the RL sense.

Reward / objective. What the learner is trying to maximize. The same role as fitness.

Policy gradient. Adjusting the policy in the direction that increases expected reward — gradient ascent applied to behaviour.

Surrogate objective. A proxy you can actually compute, standing in for the thing you care about. Works only while it tracks the real objective.

Reward hacking. When a learner maximizes the stated reward while destroying the thing the reward was meant to represent. Every discount-driven end-of-quarter revenue pull-forward is reward hacking.

Discount factor (γ). How much future reward counts relative to immediate reward. γ near 1 means patient and long-horizon; near 0 means myopic. Note this is nothing to do with commercial discounting.

Sparse / delayed reward. Feedback that arrives rarely, or long after the action. Enterprise pricing is a sparse, delayed reward problem — you learn whether the price was right at renewal, quarters later.

Flat maximum / flat minimum. A peak that is broad rather than sharp, so nearby configurations perform nearly as well. Flat optima are robust; sharp ones are fragile. Usually you want the broad hill, not the spire.

The fractal landscape result

Lyapunov exponent. A measure of how fast small differences amplify in a dynamical system. Positive means chaotic — nearly identical starting points diverge exponentially, so long-run prediction fails. A market where competitors reprice automatically in response to each other has a positive Lyapunov exponent.

Differentiable. Having a well-defined slope at every point. Gradient methods require it. Elasticity estimates assume it.

Hölder continuity. A graded way of describing how rough a function is. A function is Hölder continuous with exponent α if ∣f(x)−f(y)∣≤C∣x−y∣α. At α=1 it is well behaved and essentially differentiable. Below 1 it is continuous but not differentiable — no slope exists anywhere, no matter how closely you look.

Fractal. Structured at every scale. A fractal landscape is rugged when you zoom in, and still rugged when you zoom in further. This is worse than ordinary ruggedness, because there is no scale at which it looks locally smooth, and therefore no scale at which a gradient exists.

Mollification / smoothing kernel. Deliberately blurring a rough function by averaging it over a small random neighbourhood, producing something differentiable. This is the mathematical content of “inject deliberate price variance.”

Metric space / quotient space. A metric space is a set with a well-defined notion of distance. A quotient space is what you get when you declare certain points equivalent and collapse them to a single point. The speculative claim in this post is that pricing landscapes should be defined over the quotient of price space by buyer-perceived equivalence, not over the real numbers — and that fences and tiers are how you construct those equivalence classes.

Most value models are built/designed/generated by vendors trying to convince buyers of the value of whatever they are selling. Modern models are based on Tom Nagle’s Economic Value Estimation^(tm) or EVE^(tm) (the phrases are trademarks of Deloitte who acquired them when it purchased Monitor, who acquired them when it purchased the Strategic Pricing Group). They are mostly used to understand, track and communicate the value of differentiated products and services. But is there another way to think about this?

The power of EVE style value models is

• They are relative to an alternative (the reference value)

• They decompose value into value drivers that estimate the impacts on the buyers profit and loss statement (or in rare cases the balance sheet)

• The value drivers are represented as equations

• The equations form an interacting system with emergent properties

Value models are generally not shared directly. They are translated into value stories or used to inform ROI (Return on Investment) and NPV (Net Present Value) calculations. The actual value models are only seen by the value engineers who created them and a few other people who can appreciate and put to work the technical power of a system of equations.

Value models have the peculiar property of being internal artifacts used by people on the outside (the seller) looking in (to a buyer). That tension is one reason that adoption of value models has been slow.

What happens if we flip this and generate the value model beginning with the buyer?

Doing this one starts not with a product or solution, but with the buyer’s challenge.

Their are several ways to frame this.

• As a use case

• As a Job-to-be-Done (in Clayton Christensen’s sense)

• A KPI (Key Performance Indicator) or explicit business goal

• As a business opportunity to be exploited

One can begin with any of these as a starting point and generate a family of value models that set out what a solution needs to do in order to create value for a buyer.

Then, if there are value models available for different products and solutions, these can be searched and combined to find the best solution for a specific buyer.

The mapping between the buyer’s value model and the seller’s value model can be used to inform price and commercial terms.

This does not need to be limited to one buyer. The solution that best solves for the buyer can combine multiple products, services or agents.

A value model process for buyers

Here is a simple process for generating an EVE style value model starting with the buyer’s challenge or business opportunity.

Start from the challenge, not the catalogue. The steps below generate a buyer value model before any seller is in the room.

1. Name the Job-to-be-Done or business opportunity. State it as a functional job (the underlying process the buyer is trying to execute), not a feature request. Include the emotional and social dimensions of the job, since these often show up later as risk or optionality drivers.

2. Anchor the reference state. Ask what the buyer does today to get this job done — including “nothing,” internal workarounds, or a competitor. This becomes the reference value in the EVE sense, the baseline every driver will be measured against.

3. Identify the affected P&L and balance sheet lines. Walk the buyer’s income statement and, where relevant, balance sheet, and ask where success or failure on this job shows up: revenue, cost, working capital, capital investment, risk, optionality.

4. Draft (or generate) value drivers as equations, not adjectives. For each affected line, write a driver equation using three variable types: customer variables (who they are, how big, how they operate), improvement claims (how much better the job could be done), and market variables (external factors like rates, competitive intensity, or regulation). At this stage the improvement claims are placeholders or targets — ranges, not vendor promises.

5. Build the KPI bridge. Connect each value driver to a KPI the buyer already tracks (net revenue retention, cost per unit, days sales outstanding, risk-adjusted return). This makes the model meaningful to a CFO without translation.

6. Stress test with distributions, not point estimates. Represent uncertain variables as ranges or distributions rather than single numbers, since buyer-first models are built before a specific solution has supplied evidence.

7. Publish the model as a want, not a want-list. The output is a “buyer value model” — a solution-agnostic specification of what any offering, service, dataset, or agent would need to deliver in order to create value for this buyer, on this job, at this scale.

To research - can the Value Project JSON (an open source schema for value models) be used for this?

The search and configuration algorithm

And here is an algorithm for matching a buyer’s EVE value model with seller side value model(s).

Once buyer value models and seller value models exist as computable objects — the direction the Value Project schema is pushing the field — matching becomes a search problem over equations rather than a sales conversation over slide decks.

How it works. The buyer model BBB specifies a set of target value drivers {b₁, b₂, … b_n}, each with a KPI, a variable range, and a weight reflecting how material that driver is to the buyer. Each candidate seller model S_k​ for a product, service, dataset, or agent. This specifies a set of claimed value drivers {​S_k1, S_k2 … S_km} expressed in the same variable and unit space. The algorithm’s job is threefold: align drivers on shared semantics, score each seller against the buyer’s weighted targets, and then search over combinations of sellers (since one agent may cover a cost driver and another may cover a risk driver) to find the composition that maximizes net differentiation value for the buyer at the lowest aggregate price.

ALGORITHM MatchAndCompose(BuyerModel B, SellerModels S[1..K])

1. NORMALIZE
   for each driver b in B.drivers:
       map b to a canonical driver taxonomy code
       (Revenue Enhancement | Cost Reduction | Working Capital |
        Capital Deferral | Risk Reduction | Optionality)
   for each seller S_k in S:
       for each driver s in S_k.drivers:
           map s to same canonical taxonomy code
           align units and variable definitions to B's schema
           (resolve currency, time horizon, population size, etc.)

2. FILTER
   candidates = { S_k in S : overlap(S_k.taxonomy_codes, B.taxonomy_codes) > 0 }
   discard S_k if reference_value(S_k) is not comparable to B.reference_state
   discard S_k if S_k.risk_drivers exceed B.risk_tolerance

3. SCORE (single seller fit)
   for each S_k in candidates:
       fit_score(S_k) = 0
       for each b in B.drivers:
           s = best_matching_driver(S_k, b)
           if s exists:
               delta = evaluate(s.equation, B.customer_variables)
                       - evaluate(b.reference_equation, B.customer_variables)
               coverage = confidence(s) * overlap(s.variables, b.variables)
               fit_score(S_k) += b.weight * delta * coverage
       cost_adjusted_score(S_k) = fit_score(S_k) - price(S_k)

4. COMPOSE (multi-seller search)
   uncovered = B.drivers
   portfolio = {}
   while uncovered is not empty and candidates is not empty:
       S_best = argmax over candidates of
                marginal_value(S_k, uncovered) / price(S_k)
       portfolio.add(S_best)
       uncovered = uncovered - covered_drivers(S_best)
       candidates.remove(S_best)
       check for negative interaction effects between S_best and portfolio
       (e.g., overlapping cost claims, integration risk, redundant coverage)

5. RANK AND RETURN
   total_value(portfolio) = sum(driver-level net differentiation value)
   total_price(portfolio) = sum(price(S_k) for S_k in portfolio)
   value_capture_ratio = total_price(portfolio) / total_value(portfolio)
   return portfolio ranked by total_value(portfolio) - total_price(portfolio),
          subject to value_capture_ratio within buyer's acceptable range

The normalization step is what makes this work. Without a shared taxonomy and shared variable definitions, no comparison across seller models is meaningful, which is exactly the interoperability problem the Value Project schema exists to solve. The scoring step is a constrained matching problem — closer to a weighted bipartite matching between buyer drivers and seller drivers than to keyword search. The composition step is a greedy cover algorithm (with an interaction check) because most real buyer problems are not solved by a single product; they are solved by a bundle of product, service, data and agent, each covering a different value driver. The final step turns the whole search into a pricing decision by folding in the Value Capture Ratio, the used to judge whether a seller is capturing a fair share of the value it creates.

An ecology of buyer and seller value models

Picture four layers operating continuously rather than episodically.

At the base sit buyer value models — computable, published or privately held representations of a specific job, opportunity, or KPI target, expressed in the buyer’s own P&L terms.

Above that sit seller value models — one per product, service, dataset, or agent, each published in the same schema so it is legible to both humans and machines.

Between them sits a matching layer, running the search-and-compose algorithm above, continuously re-scoring as either side’s model changes (new pricing, new evidence, a shift in the buyer’s KPI targets).

On top sits a composition layer, which assembles the winning portfolio of sellers into a single deliverable — a bundle that might mix a SaaS platform, a data feed, a professional service, and two or three specialized agents — and expresses the combined economics as one net differentiation value and one blended price.

Feedback loops connect all four layers: realized outcomes (did the buyer actually get the promised value) flow back to update both the buyer’s model (refining KPI targets) and the seller’s model (recalibrating improvement claims), which is the same value-capture feedback loop Forth describes for the Value Project vision.

Market implications

Today’s B2B buying process runs on asymmetric information, one-off negotiation, and static packaging — a buyer compares a handful of vendor pitches, each built to be persuasive rather than comparable, and settles for a package assembled well before the deal, not for the specific job at hand. An ecology of computable buyer and seller value models attacks each of those weaknesses directly.publications.

• Information asymmetry collapses because both sides publish models in the same schema, so price can be checked against value rather than taken on faith.

• Search cost falls because matching is computational, not manual — a buyer’s model can be run against hundreds of seller models in the time it takes a human to read three vendor decks.

• Packaging becomes adaptive rather than fixed, since the composition layer assembles exactly the mix of product, service, data and agent that covers the buyer’s actual uncovered drivers, instead of forcing the buyer into a pre-built tier.

• Value capture becomes a measured, continuously tuned variable instead of a one-time negotiating outcome, closing the loop between what is promised and what is delivered.

• Competition shifts from marketing and relationship strength to model quality — sellers who can prove their driver equations against real customer data will out-compete sellers who cannot, which raises the overall honesty of the market rather than just its speed.

The market that results looks less like a sequence of negotiated deals and more like a live, navigable graph of buyer needs and seller capabilities, continuously re-matched as either side changes. The result is a genuinely computational market rather than an episodic one.

Over the past two weeks I have put up two simple polls on LinkedIn.

One asked the following question and gave the following options for responses (LinkedIn polls only allow for four options).

“Credit-based pricing is getting a lot of attention lately. Some love it, some hate it. A number of pricing experts have said it is just a fancy way to do cost plus pricing. Some buyers find it opaque and hard to predict. Some of the fastest growing and most successful companies in the AI and agent economy use it to price.”

Credit based pricing is …

• Flexible and connects to value

• Opaque and hard to predict

• A way to track costs

• Other

I put separate polls across my personal feed, the Professional Pricing Society (PPS), Design Thinking (DT), SaaS and Artificial Intelligence Exchange (AIX) groups. There were a total of 120 responses at time of writing.

Almost 50% of respondents feel that credit based pricing is opaque and hard to predict. Not a good positioning. Diving into the comments on G2, Reddit and other social media confirms this impression. There are many complaints about not understanding what the credits are, how they are consumed, what happens at the end of a period and so on. To be honest, I am tempted to add to these comments for a couple of sites that I depend on and where I am burning through a scary amount of tokens.

Looking at the differences between groups, I compared the percent who said that credits are opaque.

• Personal - 44%

• PPS - 29%

• DT - 60%

• SaaS - 43%

• AIX - 56%

The people most likely to be using agents and applications priced in credits are also the ones most likely to find them opaque!

A number of people who clicked on other commented that it is really ‘all of the above’ including well known pricing experts like Mark Stiving and Ulrik Lehrskov-Schmidt. Fair enough, but most people have one dominant impression and for almost half of the respondents that impression is “opaque and hard to predict.’ Why is that was the theme of the other poll.

“Credit based pricing is emerging as the standard way to price AI agents and is often being used as an additional pricing metric for AI enabled applications.

Many buyers and users experience credit based pricing as opaque and unpredictable. They are not sure how many credits they will need, how they are consuming the credits they have and the fate of the credits they have not yet used.

Is this a result of (i) the nature of credit based pricing, (ii) poor design, (iii) the intentions of the vendors or (iv) some other reason (one may disagree with the position that credit based pricing is opaque and unpredictable).”

Credit based pricing is opaque and unpredictable because of

• Its nature

• Poor design

• Intention

• Other

I pushed this to the same groups. There were a total 181 responses.

The two most negative responses dominated.

Almost 32% feel that credit-based pricing is inherently opaque and unpredictable.

Even more concerning, 30% of people of people thought that the opacity and predictability issues are intentional, something that has been designed in.

Having participated in numerous conversation on the design and implementation of credit-based pricing I have to admit that there are companies who intentionally implement what I would consider to be anti-patterns. They curtail roll overs, pooling and credit transfer, they don’t invest in credit wallets or credit prediction, and some even consume credits so that the most recently acquired credits are consumer first leaving the rest to expire. These design choices give all credit-based pricing systems a bad name.

If fact though, I think that most of the concern about opacity and predictability is actually the result of poor design. Here is the QA checklist from the upcoming Pricing for the Agent Economy book that I am writing with Michael Mansard and Wolfgang Ulaga. Hopefully it will help people both design and evaluate these models.

Appendix B: Credit-Based Pricing QA

A credit model is not just a price list. It is a value model, meter, wallet, policy system, and buyer trust architecture. Before launch or a material change, test the following.

A complete checklist will be available on the book’s website.

1. Value and unit

• Define the target segment and its next-best alternative; do not price for an imaginary average customer.

• Validate the core relationship: customer value > effective price > variable cost for representative actions and usage mixes.

• Choose a buyer-legible unit—normally an action, output, workflow, or verified outcome—not a hidden cost unit such as tokens.

• Make it possible to explain in one sentence what a credit buys and why different actions use different numbers of credits.

• Keep a versioned credit-weight register. Every billable action needs a trigger, weight, rationale, effective date, and owner.

• Separate the two pricing dials: credits per action express relative value; price per credit sets the overall commercial level. Do not use one to conceal changes in the other.

2. Metering and failure fairness

• Prefer charging when a successful output is confirmed. “No output, no charge” is the most comprehensible default.

• Define success, partial completion, technical failure, vendor error, and buyer-input error in machine-testable terms.

• Prevent duplicate debits from retries, timeouts, concurrency, and resumed workflows.

• Refund or avoid charging for vendor-caused failures; price expected failure rates into unit economics rather than charging buyers for unusable work.

• Maintain an auditable ledger that can recreate every debit, refund, expiry, adjustment, and invoice line.

3. Lifecycle and buyer controls

• Design overage, on-demand credits, rollover, pooling, and incentives as one connected system.

• Avoid hard caps that kill stateful agent workflows midstream. Make overage rates, alerts, and approval rules visible before spend occurs.

• Make auto-top-up opt-in, with thresholds, spend limits, notifications, and cancellation controls.

• Use explicit rollover and expiry rules by credit type; show upcoming expiry and monitor unused-credit waste as a renewal-risk signal.

• Pool credits at account or team level where workload variance warrants it; use budgets and roles for governance rather than per-seat silos.

• Use a clear, buyer-friendly draw order—normally first-expiring-first-out—and show which credit bucket funded each debit.

4. Operational readiness

• Ensure the product UI, pricing page, quote, contract, invoice, and support scripts use the same definitions and rules.

• Give buyers dashboards, forecasts, anomaly alerts, budgets, approvals, and usage-to-value reporting.

• Reconcile product events, ledger balances, invoices, and finance records; test period boundaries, version changes, currency/tax, and manual adjustments.

• Version and govern every change to weights, prices, lifecycle rules, and terms; preserve historical calculation integrity.

• Test normal flow plus failures, retries, partial work, zero balance, overage, top-up, rollover, expiry, plan changes, cancellation, and migration before release.

• Confirm accountable sign-off from pricing, product/engineering, finance, legal, GTM, and support.

The final test is simple: can a buyer predict, control, and explain their spend—and can the vendor demonstrate that every credit charge corresponds to delivered, defensible value?

Most CFOs and procurement groups want to make sure that there is a business case for any investment, especially one that is meant to have a major impact on strategy, positioning, or basic operations. This describes most future investments in AI.

We are at the tail end of a period of exploration and experimentation in which companies were willing to test AI solutions and agents for many purposes. That is a normal and healthy part of any new wave of innovation. You have to try different things to figure out what will work for you. If you insist on economic returns too early in the process you are likely to miss the real opportunities to improve and then transform your business.

But at some point one has to move from exploration to execution. More resources need to be applied, solutions scaled, integrations worked out, and governance put in place. To commit organizations need to be convinced that they are making good use of scarce resources (money, people’s time, compute, relational capital, energy and water …).

Traditionally, these decisions have required a business case that all of the key decision makers can buy into. At the heart of the business case is an analysis that sets out how value will be created, delivered, sustained.

Four of the standard ways to do this are ROI (Return on Investment), NPV (Net Present Value), TCO (Total Cost of Ownership) and of course my favourite, the value model (which I generally build using Tom Nagle’s EVE or Economic Value Estimation framework). valueIQ makes it easy to generate a high quality business case based on a value model and it is extending this to ROI and NPV.

How are these different approaches used? What are their strengths and weaknesses. How do they connect to support (or occasionally work against) each other?

ROI: The Language Executives Speak

ROI is the workhorse of the business case. It answers a blunt question: for every dollar invested, how many dollars come back, expressed as (Net Benefit ÷ Investment Cost) × 100. For AI investments specifically, net benefit has to capture both direct effects — cost savings and revenue increases — and quantified indirect effects like productivity gains and risk reduction, while cost has to capture the full stack: technology, data preparation, model or agent development, integration, training, and ongoing maintenance.

Strengths. ROI is simple, universally understood, and comparable across wildly different types of investment. It’s the number a CFO or budget owner can hold in their head and defend in a board meeting. Practitioners studying SaaS purchase justification found ROI is the most commonly used approach among the three (TCO, ROI, value) precisely because it collapses a messy investment case into one comparable figure.

Weaknesses. ROI ignores the time value of money and the timing of cash flows — a project that pays back everything in year three looks identical to one that pays back steadily from month one, even though the second is far less risky. It also tends to be gamed: benefits get inflated and costs get understated, especially for AI projects where “productivity improvement” claims are notoriously soft unless tied to a documented baseline. ROI also says nothing about affordability or cash constraints — a 300% ROI project that requires more capital than the company has is still not fundable.

Who it’s for. ROI is the CFO’s and procurement’s native language, and it’s what business buyers use to sell a project upward. All that decision-makers actually read is three-year TCO, three-year value capture, ROI ratio, and payback period presented as ranges, not point estimates. For agentic AI procurement specifically, the metric that unlocks executive attention tends to be “ROI percentage with a timeline — anything above 200% within 12 months,” provided it rests on hard, documented savings rather than vague productivity language.

NPV: The Capital Allocator’s Discipline

NPV takes the ROI logic and adds discipline for time and risk: it discounts each period’s net benefit back to today’s dollars using the company’s cost of capital and a risk adjustment, so a dollar of value five years from now is worth less than a dollar of value next quarter. This matters increasingly for AI, because many AI and agent initiatives have a J-curve profile — heavy upfront cost, slow initial adoption, and value that compounds only after data, workflows, and trust are built.

Strengths. NPV is the only one of the four that properly accounts for the opportunity cost of capital, which is why finance teams use it to rank competing projects against each other or against simply investing the money elsewhere. It forces explicit assumptions about discount rate, time horizon, and the shape of the benefit curve — assumptions that ROI often hides.

Weaknesses. NPV is the least accessible of the four to a non-finance audience; a “positive NPV of $2.3M at an 8% discount rate” doesn’t land the way “300% ROI” does. Some practitioners go further and argue NPV is essentially unusable for typical technology decisions because the discount rate and multi-year cash flow forecasts required are too speculative for anything beyond mature, well-understood capital projects — it has even been argued that NPV cannot be used to assess a technology initiative as the future is too uncertain. For fast-moving AI investments, where the underlying technology, competitive landscape, and even the vendor’s product may change within 6 months, forecasting cash flows five to seven years out is often closer to fiction than finance.

Who it’s for. NPV lives with the CFO, finance/FP&A, and the capital allocation committee — it’s the tool used when an AI investment is competing against other strategic uses of capital (a new plant, an acquisition, a buyback) rather than against “doing nothing.” It rarely appears in a pitch to a business buyer or a technical buyer; it’s a portfolio-level, not a project-level, conversation.

TCO: The Cost-Side Reality Check

TCO totals every cost of owning and operating a solution over its useful life — not just the license or subscription price, but implementation, integration, data preparation, training, change management, ongoing maintenance, compute and inference costs, governance overhead, and eventual replacement or decommissioning. In some cases even risk is included (though this is not a common practice). For AI and agent deployments, this list is longer than for traditional SaaS: it needs to include the “coordination tax” of managing human-AI handoffs, human transition costs, governance infrastructure, and failure reserves for when the agent gets something wrong.

Strengths. TCO is the only one of the four metrics that reliably surfaces the long-tail costs that both ROI and NPV tend to omit — the maintenance, retraining, model drift management, and compute cost creep that erode value years after go-live. It’s essential for comparing architecturally different options (build vs. buy, cloud vs. on-prem, a single large model vs. a fleet of specialized agents) where sticker price is a poor guide to real cost.

Weaknesses. TCO tells you the cheapest option, not the best one — it has nothing to say about benefits, so a rigorous TCO exercise can accidentally steer a company toward the cheapest AI tool rather than the one that actually solves the business problem. Used alone, it systematically favors incumbency and under-investment, because it makes visible every cost of change and none of the cost of staying still.

Who it’s for. TCO is procurement’s and IT/CTO’s home turf. It’s what a technical buyer uses to negotiate vendor contracts, compare architectures, and protect the budget from underestimated implementation and run costs. CFOs use it alongside ROI to sanity-check whether a headline return survives once the “hidden” costs are added back in.

The Value Model (EVE): Selling and Buying on Impact

The value model — built using Tom Nagle’s Economic Value Estimation (EVE) framework — starts from a different question than the other three: not “what will this cost us” or “what do we get back,” but “how much economic value does this create for this specific customer, relative to their next best alternative?”. An EVE model decomposes value into a reference value (what the customer’s next-best alternative costs or delivers), a positive differentiation value (the extra economic benefit your offering creates), a negative differentiation value (switching costs, training, or anything the customer gives up), and a net differentiation value — the range within which a defensible value-based price sits. Note that in practice many (most?) EVE models do not include a reference price.

The underlying value drivers are organized into six categories that map directly onto a customer’s income statement and balance sheet: increase revenue, decrease operating costs, decrease operating capital, decrease or defer capital investment, decrease risk, and increase flexibility/optionality. This is what makes EVE fundamentally different from ROI, NPV, and TCO — it isn’t a financial appraisal technique applied after the fact; it’s a value architecture built collaboratively, that becomes the shared language buyer and seller use to negotiate price and scope.

Strengths. The value model is the most holistic of the four, because it forces explicit segmentation — different customers get different amounts of value from the same offering, which is exactly why one-size-fits-all pricing under- or over-charges most segments. It’s also the only one of the four designed from the outset to be a joint artifact between buyer and seller rather than an internal-only calculation: a well-built EVE model gives the seller a defensible basis for value-based pricing and gives the buyer independent verification that the price is justified by real economic impact rather than list-price anchoring or negotiation leverage.

Weaknesses. EVE models are harder to build and require far more customer-specific data than a generic ROI or TCO template — you need real numbers from the customer’s own operations, which means access, trust, and time. They are also easier to dispute: because the model quantifies benefits that haven’t happened yet, a sceptical CFO can always argue the value driver assumptions (adoption rate, error reduction, cycle-time improvement) are optimistic. Value models age fastest of the four and need to be updated and maintained as part of customer success — an AI agent’s differentiation value against “next best alternative” can shrink within a single product release cycle as competitors close gaps or the market redefines what’s table stakes.

Who it’s for. The value model is most effective with the actual business buyer and executive sponsor who owns the P&L impact — a VP of Operations, a Chief Revenue Officer, a business-unit CEO — because it speaks directly in the currency of their targets (revenue, margin, working capital, risk). It’s an essential tool for the seller: without an EVE model, a sales team is reduced to competing on price or features rather than economic impact. CFOs engage with it as a validator of the ROI case’s assumptions, not usually as the primary artifact they sign off on — the CFO wants the compressed ROI/TCO number; the value model is what justifies that number’s inputs.

How the Four Frameworks Connect

These four systems of measurement are not competitors so much as inputs into each other. The value model generates the benefit-side numbers — the revenue lift, cost reduction, risk mitigation — that feed directly into the numerator of the ROI calculation and into the future cash flows that NPV discounts. TCO, in parallel, generates the denominator: the fully loaded cost base that ROI divides into, and that NPV’s outflows are built from. In a well-built business case, EVE supplies “what value looks like,” TCO supplies “what it really costs,” and ROI/NPV are simply different ways of compressing those two streams into a decision-ready number.

Where they work against each other is mostly political rather than mathematical. A seller’s EVE model, built to demonstrate maximum differentiated value, can produce optimistic benefit assumptions; a buyer’s TCO exercise, built by procurement to protect the budget, naturally produces a maximalist cost base including every conceivable hidden cost. Put those two together unreconciled and you get an ROI number that neither side actually believes — which is exactly why the strongest business cases are co-built, with the value model and TCO validated jointly by both parties rather than handed across the table as competing artifacts. There is also a structural tension between NPV’s discipline and ROI’s simplicity: a project can show an attractive year-one ROI while destroying value on an NPV basis if the benefit curve declines sharply after an initial spike. This is why value over time is emerging as a key part of value modelling and analysis.

Data Requirements

Each framework reqiores a different data diet, and mismatched data is the most common reason business cases fall apart under CFO scrutiny.

ROI needs a documented baseline of current-state cost and performance (hours spent, error rates, throughput, unit costs) captured before the AI solution is deployed, plus an all-in cost estimate covering software, implementation, integration, training, and ongoing operation.

NPV requires everything ROI needs, period by period, plus two additional inputs: the company’s weighted average cost of capital (or hurdle rate) and a defensible multi-year forecast of how benefits and costs will evolve — including how quickly AI value ramps, plateaus, or decays, which is the value over time mapping that is emerging as a key issue.

TCO requires a comprehensive cost taxonomy: license/subscription fees, implementation and integration labour, data preparation and cleansing costs, training and change management, ongoing compute/inference costs, model retraining and governance overhead, support and maintenance contracts, and end-of-life/replacement costs, ideally sourced from vendor contracts, IT asset management systems, and finance’s cost-center actuals rather than estimated.

The value model (EVE) is the most data-intensive to build correctly, because it requires customer-specific operational data mapped to the six value drivers: current revenue and margin structure, operating cost baselines by process, working capital metrics, capital expenditure plans, risk exposure (compliance, downtime, error costs), and a credible profile of the “next best alternative” the customer would use instead. This data typically comes from a mix of customer interviews, the customer’s own financial statements, industry benchmarks, and — increasingly — instrumented usage data from a pilot or trial deployment, which is why the strongest EVE models today are built jointly during a proof-of-concept rather than purely from pre-sales discovery calls.

Validating Models Over Time

Building the business case is the easy half; validating it after go-live is where most organizations under-invest.

ROI validation requires re-measuring the same baseline metrics post-deployment on a fixed cadence, and a “post-audit” comparing actuals to the original business case line by line, typically at 12 months. A staged review cadence — a day-0 baseline, a day-30 adoption check, a day-60 quality check, and a day-90 scale-or-kill decision — has become the emerging standard specifically for AI workflows, because early enthusiasm metrics (usage, sentiment) are poor predictors of durable value.

NPV validation is harder because it requires tracking actual cash flows against forecast ones over multiple years and periodically re-running the discounted model as the cost of capital, risk discount or the benefit trajectory shifts — few organizations do this rigorously, which is part of why NPV is more often used to approve than to audit AI investments.

TCO validation means reconciling budgeted versus actual spend across every cost category quarterly, watching in particular for the categories that tend to blow past estimate in AI projects — data preparation, integration rework, and ongoing compute/inference costs as usage scales — and feeding overruns back into future TCO templates so the estimation error shrinks over time.

Value model validation is the most operationally demanding and, done well, becomes an ongoing governance discipline rather than a one-time exercise. It requires instrumented tracking of the actual value driver metrics named in the original EVE model — the specific revenue lift, cost reduction, or risk metric promised — against the baseline, ideally through a dashboard with defined owners, targets, and review cadences, sometimes formalized as a “Benefits Register” or “Results Chain” that traces AI activity through to business outcomes. Because AI value has a value over time curve rather than a flat, constant profile, validation needs to revisit the value model itself periodically — not just check actuals against a static forecast — to confirm the shape of the curve (how value appears, grows, plateaus, and eventually decays as the market catches up) still matches reality. This is also the framework most naturally suited to renewal and expansion conversations: a validated EVE model becomes evidence for the next negotiation, closing the loop between the initial business case and the ongoing commercial relationship.

Matching Frameworks to Decision-Makers

No single framework wins every stakeholder, which is why a complete business case for a significant AI investment typically presents at least three of the four together, translated for the audience in the room.

• CEO — cares about strategic positioning and competitive advantage; responds best to the value model’s framing of differentiated economic impact plus a headline ROI/payback figure, not a spreadsheet of assumptions.

• CFO — wants one clear number with a timeline, typically ROI and payback, but will demand the TCO be added back in to stress-test whether the headline return survives full costing, and may ask for NPV when the investment competes against other capital uses.

• CTO/technical buyer — lives in TCO territory: architecture cost, integration burden, ongoing maintenance and compute cost, and vendor lock-in risk, because they own the operational consequences long after the business case is approved.

• Procurement — uses TCO to negotiate contract terms and compare vendors on total cost, and increasingly cross-checks vendor ROI claims against independently modelled TCO and risk-avoidance figures.

• Business buyer / executive sponsor — is the natural home of the value model, because EVE speaks directly in the P&L and operational metrics they’re accountable for, and gives them ammunition to defend the investment internally.

• Seller/vendor — needs the value model as the foundation of a value-based pricing conversation; without it, they default to feature or discount-based selling that erodes margin and mutual trust.

The organizations that move fastest and most successfully from AI experimentation to AI execution are the ones that stop treating these four frameworks as competing templates to fill in for different stakeholders, and start treating them as one connected system: the value model defines what “winning” looks like, TCO defines what it really costs to get there, ROI and NPV translate that into the language of capital allocation, and disciplined post-implementation reviews close the loop by holding all four accountable. That loop — build, price, deploy, measure, revalue — is the real business case for AI. It’s also the positive-sum structure that lets buyer and seller keep negotiating in good faith long after the ink is dry.

See note at end for how AI was used in this post.

There is a lot of uncertainty swirling about the agent economy these days. Many questions are unresolved and the technology is moving forward faster and in ways that are difficult to imagine. Many of you will have seen the video from OpenAI on the Hugging Face hack. This is only the tip of the iceberg and our agents are up to many things in the background that we don’t even suspect.

“The future is here, it is just not evenly distributed.”
Vancouver science fiction writer William Gibson.

Given this level of change and uncertainty, how do we design packaging and pricing for the solutions we are bringing to market?

The classic answer to this is with scenario planning — one needs to design approaches that will be resilient over more than one possible future scenario.

The complementary answer is with adaptive pricing — one needs to design pricing systems that can adapt to and take advantage of change.

This rather long post I focus on pricing and scenario planning for the agent economy. Adaptive pricing will be a theme for early in the fall.

What is scenario planning?

Scenario planning accepts that the future is uncertain and that there is more than one possible future. But it is not defeatist. It gives us tools to get early warnings of which futures are unfurling, how to prepare for them, and even how to shape them and tilt the paying field toward the future we want.

A great example of this are the Mont Fleur scenarios developed for South Africa with Nelson Mandela. When Mandela was released from prison in 1990 South Africa faced an uncertain and possibly disastrous future. The three critical uncertainties were whether there could be a negotiated settlement or would the country descend into civil war, would the transition to a new order be decisive, and would the policies of the new government be sustainable.

These uncertainties were used to structure four possible futures. 1. (lower left) an autocratic government in terminal decline (the ostrich), 2. (lower right) a democratic government with an economy that continued to struggle (lame duck), 3. (top left) an autocratic government that soared and then crashed (Icarus after the character in Greek myth who flew too close to the sun), 4. (top right) a diverse and successful democratic economy (flight of the flamingos). Being able to imagine and discuss these alternative futures helped people negotiate a transition to a democracy, though South Africa has struggled with its economic policies.

For more detail on this fascinating story see Reos Partners Learning from Experience: The Mont Fleur Scenario Exercise.

Another important touch point for scenario planning is Shell’s work. Shell has a 50+ year track record in developing and applying scenarios and keeps its scenarios updated. You can study their work here.

Here is a simple version of scenario planning that we used at Ibbaka (the company where I did pricing consulting).

1. Identify trends about which there is already meaningful certainty

Examples are demographic trends, demand trends, sustaining innovations, events that we know will occur but are unsure when they will occur (like pandemics).

2. Identify critical uncertainties

A critical uncertainty is where more than one future could emerge. These uncertainties are critical because they will lead to different outcomes that require different actions that have important consequences. In most cases, limit this to two or three possible outcomes. Even if there is a continuum of outcomes or more than three outcomes, it is easier for humans to manage a limited set of scenarios. Trying to account for all possible scenarios can lead to ‘analysis paralysis.’ It will be interesting to see if this changes with the use of generative AI, perhaps that is also a critical uncertainty.

3. Combine two critical uncertainties

This is a powerful exercise. Pick several different different critical uncertainties and try combining them in different ways. Look the the patterns that emerge. Which generate futures that will require different actions?

4. Select the critical uncertainties and construct four scenarios

The common practice is to limit oneself to two critical uncertainties and four scenarios. All four scenarios should be seen as possible. It is not necessary that all the scenarios be desirable, or that one be the most desirable. In some advanced applications, it is helpful to use multiple states for each critical uncertainty. This allows one to model neutral outcomes and generate six, nine or more scenarios. One can also use more than two critical uncertainties. If you are going to use more than three you will need a software tool to manage all the interactions. But this approaches lead to complexity that can actually make it more difficult to understand and prepare for scenarios. Start with a 2 x 2 matrix of four scenarios. This is enough to get you preparing for alternate futures.

5. Name each scenario

Give each scenario a name so that it becomes memorable and you can refer to it easily.

6. Analyze the implications of each scenario

Investigate questions such as
- Who is impacted
- How long will the impact last
- How will the impact change beliefs about the world
- How will the impact change behaviours
- How will the impact change decision making
For pricing scenarios, consider the impact on
- Supply and demand
- Market dynamics
- Value drivers (economic, emotional, community)
Consider the impact on people, the skills they will need, the roles they will play

7. Create stories about each scenario

Turn each scenario into a story about that future. Stories are one of the most powerful ways to promote understanding and memory. A scenario is not complete without a story.

8. Identify early indicators for each scenario

Ask what the early indicators are for each critical uncertainty. What will suggest how each uncertainty will resolve? Do this first for each critical uncertainty used for your scenarios and then for each scenario.

9. Decide on actions for each scenario (in this context pricing actions)

What are the critical actions you will take under each scenario? How will your pricing model need to evolve? It is often useful to divide these into three time frames: at the beginning of the scenario, in the midst of the scenario, at the end of the scenario.
Apply best practices for decision making and make it clear what will trigger the action, what resources are needed to execute the action, what information is needed to execute the action, what outcomes are expected.

10. Establish a review mechanism

Periodically (usually quarterly or annually) review the other critical uncertainties that you identified in Step 2. See if any of the critical uncertainties have resolved so that there is no longer uncertainty. When you do this you may identify new critical uncertainties. Decide if you need to refresh your scenarios.

Use scenario planning for pricing to do three different jobs.

• To be prepared for rapid action — by knowing what to prepare for, having early warning systems in place, and plans prepared.

• To build resilience and adaptability — by designing pricing that works across more than one future scenario (resilience) and that can adapt to the unexpected (adaptability)

• To shape the future — by helping people to imagine different paths and to choose the path that leads to the more desired future (as was done with the Mont Fleur scenarios)

Agile scenario planning

During the Covid 19 pandemic (2020 to 2023) the shortcomings of classic scenario planning became obvious. There were very few organizations that had scenarios for how to operate during a global pandemic and once the pandemic began events moved so quickly that critical uncertainties were being resolved and new emergencies emerging faster than scenarios could be developed.

My colleague Karen Chiang and I were asked to help a large quasi-government organization to develop a set of scenarios for operating under Covid 19 (we had previously helped them with their customer journey map and applied this to their pricing). Rather than create a set of formal 2 x 2 scenarios we came up with what we called agile scenario planning.

A Simple Process for Agile Scenario Planning

The process for agile scenario planning is different from classic scenario planning. Whereas the latter is focussed on creating durable scenarios and telling stories that will prepare people for change, agile scenario planning is much more about exploration and preparation of rapid response.

1. Define the purpose (be prepared, explore potential, generate change)

2. Set cadence (daily, weekly, monthly)

3. Identify an initial set of critical uncertainties (start with three to seven but be open to more)

4. Map dependencies between critical uncertainties (to deepen your understanding and manage the combinatorial explosion)

5. Generate combinations of critical uncertainties (based on the dependencies identified in step 4, but include some ‘random’ combinations that could surprise you; note that you do not need to develop these or go deep, you often want to regenerate combinations and have fresh conversations)

6. Prime your early warning system (what data, sensing, conversations will help you know early how each critical uncertainty is resolving)

7. Prepare your initial responses (this should be done for both critical uncertainties and for scenarios generated by combining critical uncertainties)

8. Have cadence meetings - at each meeting make sure to

• Look at early warning status for all critical uncertainties

• Consider generating (or swapping out) new critical uncertainties

• Review 3-5 combinations from the set of possible combinations (choose scenarios based on critical uncertainties that may be resolving)

• Review how to respond to these 12 to 20 different scenarios

• Identify scenarios where response would be inadequate

• Review cadence (does it need to be accelerated, can it be slowed down)

That may seem like a lot of work, but ask yourself, what is the cost of being blind sided.

The current pace of change is such that agile scenario planning will be a better approach than traditional/formal scenario planing for many packaging and pricing scenarios.

More background on agile scenario planning is available here.

Scenarios for the agent economy and credit based pricing

The emerging agent economy could develop in many different directions and we are trying to navigate through a lot of uncertainty. Let’s try to identify some critical uncertainties and combine them into scenarios. But first let’s see if we can make some projections about the future that we can be reasonably sure of.

What we can be sure of (projections)

• Models will become more capable (as a result of neural scaling laws)

• Token costs will come down (as a result of Huang’s law)

• Operational decision cadences will accelerate (although strategic decisions may drag out longer)

• Total inference spend will keep rising even as unit cost falls (a Jevons-paradox effect)

• Agent commerce and payment protocols proliferate before they consolidate (we are already seeing this)

• Regulatory compliance burden for autonomous decision-making rises in the near term regardless of how the “autonomy vs. regulation” uncertainty ultimately resolves

• Governance and auditability tooling moves from differentiator to baseline expectation

• Multi-agent orchestration complexity increases, independent of which model or protocol wins

The third point, “Operational decision cadences will accelerate (although strategic decisions may drag out longer) “ may require some additional explanation.

The Operational Tier: Automated Compression (Milliseconds to Hours)

At the operational layer, decision time collapses completely. AI removes the human bottleneck from data-dense, high-frequency choices.

• Hyper-Speed Execution: Tasks like credit risk scoring, fraud detection, and algorithmic supply chain adjustments shift from days to milliseconds.

• Continuous Optimization: Real-time telemetry feeds directly into automated machine learning pipelines, enabling continuous tactical adaptation.

• Playbook Automation: In an Agile Scenario Planning framework, AI monitors quantitative triggers and instantly deploys pre-written operational playbooks without waiting for executive meetings.

The Strategic Tier: The “Analysis Paralysis” Paradox (Weeks to Months)

Counter-intuitively, the adoption of AI can increase the time required to make major strategic, long-term decisions. This occurs because the bottleneck is no longer data processing, but human cognitive bandwidth and alignment.

• The Noise Avalanche: AI makes it incredibly easy to generate massive volumes of alternative scenarios, data models, and synthetic market projections. Executives are flooded with more plausible variations, leading to evaluation fatigue.

• Evaluating Long Tail Risks: Because AI can rapidly calculate complex probabilities, strategic teams spend significantly more time debating extreme, low-probability “black swan” events surfaced by the models.

• Validating the “Black Box”: Trusting an AI-driven projection requires extensive auditing. High-stakes choices (like M&A or structural pivots) require lengthy human validation phases to verify data origins and combat algorithm hallucination or bias.

The critical uncertainties

I got a bit carried away here, but there is a lot happening …

1. Differentiation — Specialist agents sustain defensible differentiation OR frontier models continually catch up and erase the gap

2. Compute cost exposure — Inference and advanced-function usage drive compute costs up, making variable cost a major pricing factor OR compute costs keep falling enough that variable cost becomes negligible in pricing

3. Autonomy vs. regulation (speed) — Autonomous decision-making is commercially adopted rapidly OR regulation delays, limits, or prevents its acceptance

4. Value attribution — Attribution is solved and outcome-based pricing is adopted rapidly OR attribution stays hard and outcome-based pricing adoption stays low

5. Model openness — Dominant models stay closed-weight, making agents captive to a few frontier vendors OR dominant models go open-weight, giving agents model choice and switching freedom

6. Model scale vs. specialization — General foundation models dominate as the best solution for most agents OR many small specialist models (e.g., Hugging Face-style) outperform for most use cases

7. Credit adoption — Buyers resist credits and adoption stays limited OR buyers demand credits and adoption becomes general and rapid

8. Credit fungibility — Credits stay narrow, usable only within one agent or system OR credits become fungible across broad ecosystems

9. Regulatory shape — A globally interoperable compliance standard for autonomous agents emerges OR regulation fragments sharply by jurisdiction, forcing multiple governance configurations

10. Liability allocation — Liability for autonomous agent harms falls primarily on the deploying enterprise OR liability shifts toward, or is shared with, model/agent vendors

11. Identity and trust infrastructure — Agent identity and trust-registry standards converge into an interoperable layer OR identity verification stays siloed by network, platform, or vendor

12. Vendor landscape structure — A small number of hyperscale agent platforms capture most enterprise spend OR a long tail of specialist vendors continues to thrive alongside them

13. Context portability — Customer context and interaction history become portable across vendors OR context becomes a proprietary moat that locks customers in

14. Outcome measurement standardization — An industry-wide standard for measuring and auditing agent outcomes emerges OR each vendor keeps defining outcome metrics on a proprietary, non-comparable basis

15. Capital cycle — AI infrastructure and agent-startup investment continues at current pace OR a funding contraction/valuation correction slows the buildout and shifts budgets toward proven ROI

16. Workforce response — Organizations redeploy humans into supervisory/orchestration roles alongside agents (centaur pattern) OR agent capability substitutes directly for knowledge work, shrinking seat-based headcount

Mapping Dependencies Between the Uncertainties

Critical uncertainties do not need to be independent of each other (orthogonal) and there are often dependencies between them such that if one resolves it changes the probability that another will be resolved in a certain way.

Here is a preliminary mapping and clustering of dependencies between these critical uncertainties.

This is important as it helps us know how to combine uncertainties to create scenarios.

Constructing the base scenarios

To provoke thought and conversation, here are three sets of scenarios worth considering as you plan for the agent economy and credit based pricing. The time frame for these scenarios is three years.

The three pairs were selected from the sixteen-uncertainty set to maximize strategic relevance while minimizing redundancy. Each pair was chosen from a different cluster so the three sets probe distinct layers of the system: the core pricing mechanism itself, the competitive/technical architecture beneath it, and the regulatory/infrastructure layer around it. Together they generate twelve scenarios spanning the most consequential combinations for credit-based pricing design.

Set A: Pricing Mechanism Scenarios

Axes: Value attribution (Solvable vs. Hard) x Credit adoption (Buyers Demand vs. Buyers Resist)

Outcome Rush (Solvable x Demand)

Causal ML matures fast enough to push Outcome Attribution Rates past the 30–40% threshold that is the tipping point for migration from usage credits to outcome pricing. Buyers, having already grown comfortable with credit-based billing, actively pull vendors toward outcome-layered pricing because it demonstrably ties spend to value. Vendors that invested early in EVE-anchored value models and machine-readable credit weight tables capture disproportionate share, since they can reprice into outcomes.

Pricing action: build outcome-attribution instrumentation now, even before OAR crosses the threshold, so the credit-to-outcome bridge is ready when demand arrives.

Blind Faith Credits (Hard x Demand)

Attribution remains stubbornly difficult — multi-agent workflows blur which agent or step actually produced the result — but buyers demand credits anyway, because credits still solve the governance, auditability, and granularity problems that seat-based and flat pricing never addressed. Usage-based and action-based credits (not outcome-based) dominate, and vendors compete on transparency, predictability, and governance tooling rather than on provable ROI.

Pricing action: double down on predictability and governance since these become the primary basis of competition when outcome pricing cannot yet be trusted.

Silent Ledger (Solvable x Resist)

Attribution technology matures and vendors and buyers can measure outcome value precisely, but buyers resist the exposure and complexity that comes with credits or outcome pricing, preferring the comfort of flat subscriptions or per-seat models even where they demonstrably overpay or underpay relative to value received. Vendors sit on rich attribution data with no commercial mechanism to monetize it, creating pressure for a slow, education-led transition rather than a rapid repricing.

Pricing action: use attribution data internally to inform packaging decisions even while formally billing on legacy models, and invest in buyer education to close the gap between technical readiness and commercial readiness.

Frozen Metrics (Hard x Resist)

Neither the technical problem nor the market pull resolves — attribution stays unreliable and buyers actively resist credit-based billing, perceiving it as unpredictable or vendor-favoring. Legacy per-seat and subscription pricing persists as the dominant model for the foreseeable future, and credit-based pricing remains a niche pattern used mainly by AI-native challengers rather than the incumbent majority.

Pricing action: maintain credit-readiness as a latent capability (weight tables, wallets, calculators built but not fully exposed) so the organization can move quickly the moment either uncertainty resolves, without repricing trauma.

Set B: Competitive Architecture Scenarios

Axes: Model openness (Closed-Weight vs. Open-Weight) x Differentiation (Specialist Defensible vs. Frontier Catches Up)

Walled Gardens of Excellence (Closed x Specialist Defensible)

A small number of frontier model vendors dominate, but specialist agents still sustain defensible differentiation on top of them by owning proprietary context, workflow integration, and governance layers that the frontier vendors do not replicate. Pricing power concentrates in agents that can demonstrate a genuine “context moat,” and credit pricing becomes a tool for capturing that differentiated value rather than a pass-through of model access.

Pricing action: anchor credit weights explicitly to workflow and context value, not to underlying model capability, since the model itself is a commodity input in this world.

Frontier Monopoly (Closed x Frontier Catches Up)

Closed frontier models absorb capability gains fast enough that most specialist agents lose their differentiation, becoming thin orchestration wrappers around a handful of dominant model vendors. Agents become captive clients, margins compress toward the frontier vendors’ own compute-plus-margin economics, and credit pricing risks drifting toward the cost-anchored, token-markup pattern.

Pricing action: resist the drift toward cost-plus credit design even under margin pressure; where genuine differentiation is thin, compete on governance, trust, and packaging rather than trying to defend an eroding technical moat.

Cambrian Explosion (Open x Specialist Defensible)

Open-weight models proliferate, echoing the diversity already visible on Hugging Face, and specialist agents thrive by fine-tuning, combining, and orchestrating many small models for specific tasks, sustaining differentiation through domain expertise and integration rather than exclusive model access. Credit fungibility becomes commercially attractive in this world, since customers want to move value freely across a diverse ecosystem of interoperable, open-model-based agents.

Pricing action: prioritize interoperable credit-weighting schemes and machine-readable pricing schemas early, since the ecosystem’s diversity rewards vendors that make switching and combining agents easy rather than punishing it.

Commodity Soup (Open x Frontier Catches Up)

Open-weight models become widely capable, but this widespread capability makes it easy for anyone to replicate agent functionality, collapsing differentiation to price, UX polish, and distribution rather than technical capability. Margins compress across the board, and credit-based pricing becomes a race toward the lowest sustainable price per credit, testing the Value > Price > Cost rule at its tightest margin.

Pricing action: shift value narrative toward speed of iteration, integration depth, and trust/governance credentials, since technical capability alone stops being a defensible pricing anchor.

Set C: Infrastructure and Governance Scenarios

Axes: Regulatory shape (Harmonized vs. Fragmented) x Credit fungibility (Narrow vs. Broad Ecosystem)

Global Credit Commons (Harmonized x Broad Fungibility)

A GDPR-like global compliance baseline for autonomous agents emerges alongside converged identity and trust-registry standards, enabling credits to become genuinely fungible across vendors and ecosystems. Agent-to-agent commerce reaches the machine-negotiable pricing stage within the three-year horizon, and cross-vendor credit wallets become standard commercial infrastructure rather than an experimental edge case.

Pricing action: invest early in interoperable APIs and standardized credit denomination logic, since first movers in this scenario capture the network effects of a genuinely portable credit ecosystem.

Orderly Silos (Harmonized x Narrow Fungibility)

Global regulatory harmonization succeeds, giving vendors a single, predictable compliance framework to design against, but commercial fragmentation persists because credit systems remain vendor-specific by design choice or competitive strategy rather than by regulatory necessity. Compliance costs stay low and predictable, but customers still juggle multiple, non-portable credit wallets across their agent stack.

Pricing action: compliance simplicity frees resources to compete on packaging and bundling within a single-vendor ecosystem — invest in agent family and system-level pricing (bundles, volume discounts across a vendor’s own agent portfolio) rather than cross-vendor interoperability.

Gray Market Credits (Fragmented x Broad Fungibility)

Identity, trust, and commerce protocols converge technically faster than regulation can harmonize across jurisdictions, so cross-vendor credit fungibility becomes technically possible while remaining legally ambiguous — credits earned or purchased under one jurisdiction’s rules flow into agent ecosystems governed by different, sometimes conflicting, regulatory regimes. This creates arbitrage opportunities alongside genuine compliance risk, and enterprises face pressure to build compliance abstraction layers on top of otherwise-portable credit infrastructure.

Pricing action: build jurisdiction-aware compliance tagging into the credit and wallet architecture now, so the same fungible credit infrastructure can be selectively constrained where local regulation demands it.

Balkanized Agents (Fragmented x Narrow Fungibility)

Regulatory fragmentation across the EU, US state patchwork, and divergent Asian frameworks combines with vendor-specific, non-portable credit systems to produce a highly regionalized, high-friction agent economy in which multinational buyers must maintain separate credit relationships, governance configurations, and pricing structures for each jurisdiction and vendor. This is the most operationally expensive scenario for both buyers and vendors, and it slows overall agent economy growth relative to the other three quadrants.

Pricing action: build regional pricing and governance modularity as a core design requirement rather than an afterthought, since a single global credit architecture will not survive contact with this environment; prioritize being the vendor that reduces this friction for multinational buyers as a differentiated value proposition.

Cross-Set Observations

Several structural relationships link scenarios across the three sets.

Outcome Rush (Set A) is most plausible alongside Walled Gardens of Excellence or Cambrian Explosion (Set B), since defensible differentiation is what makes vendors trust enough in their own value models to reprice into outcomes; it is least plausible alongside Commodity Soup, where margin compression makes outcome-pricing experimentation risky.

Global Credit Commons (Set C) is close to a technical prerequisite for the broad credit fungibility assumed in Cambrian Explosion (Set B) — a vendor cannot build a fungible, cross-ecosystem credit product in a Balkanized Agents regulatory environment, regardless of how favorable the competitive architecture looks.

This suggests the three sets should not be read as fully independent: when constructing a composite view of the future for internal planning, cross-check that the combination selected across all three sets is jointly plausible rather than assuming any combination of one scenario from each set is equally likely.

Using The Twelve Scenarios

The next steps for each of the twelve scenarios are to identify early indicators (for example, OAR crossing 30–40% signals movement toward Outcome Rush; EU AI Act enforcement patterns and US state-law convergence or divergence signal movement toward Orderly Silos versus Balkanized Agents), and to define the beginning-, middle-, and end-of-scenario pricing actions the framework calls for.

Given the pace of change already discussed, an agile scenario planning cadence — reviewing three to five of these twelve combinations at each cadence meeting rather than committing to a single formal roadmap — is likely more resilient than treating any one scenario as the base case.

Early Indicators for each of Twelve Scenarios

Set A: Pricing Mechanism — Early Indicators

Value attribution axis indicators (Solvable vs. Hard): Vendor-published Outcome Attribution Rate (OAR) crossing 30–40% is the single most direct signal named in the source material as both metric and milestone; watch for causal ML attribution tooling appearing in vendor product roadmaps and case studies, and for third-party audit or certification services for outcome attribution emerging as a market category.

Credit adoption axis indicators (Demand vs. Resist): Track RFPs and procurement templates that explicitly request credit-based pricing versus those that request flat/subscription-only options; watch renewal and expansion conversations for buyer-initiated requests to move from seats to credits; monitor analyst commentary (Gartner, Forrester) on credit-pricing adoption rates across SaaS and AI-native vendors.

Set B: Competitive Architecture — Early Indicators

Model openness axis indicators (Closed vs. Open Weight): Track the release cadence and capability parity of open-weight model families (e.g., Llama-successor releases, DeepSeek, Mistral, Qwen) against closed frontier labs; watch enterprise procurement policies for stated preferences on data residency and model auditability that favour one path; monitor pricing and API-access changes from closed frontier vendors that signal tightening or loosening of ecosystem lock-in.

Differentiation axis indicators (Frontier Catches Up vs. Specialist Defensible): Track whether frontier model release notes increasingly claim parity with narrow specialist agents (a catch-up signal) versus specialist agents publishing benchmarks showing sustained leads in domain-specific tasks; monitor M&A activity, since frontier labs acquiring specialist agent startups signals catch-up dynamics, while specialist agents raising growth-stage funding on defensibility claims signals the opposite.

Set C: Infrastructure and Governance — Early Indicators

Regulatory shape axis indicators (Fragmented vs. Harmonized): Track whether other jurisdictions begin mirroring EU AI Act provisions (a harmonization signal) after the August 2026 enforcement deadline, versus whether US states continue passing divergent AI liability and governance laws beyond California’s AB 316 and Colorado’s AI Act; monitor whether international bodies (OECD, UN, ISO) succeed in publishing a reference framework that multiple jurisdictions formally adopt.

Credit fungibility axis indicators (Narrow vs. Broad Ecosystem): Track adoption and interoperability claims across A2A, AP2, MCP, and competing protocols (UCP, ACP, Visa TAP, Mastercard Verifiable Intent); watch for the first commercially live cross-vendor credit wallet or credit-transfer product, and for major platform vendors (Salesforce, Microsoft, Google, Anthropic) announcing mutual credit-acceptance or clearing agreements.cloud.

Tactics for the Twelve Scenarios

Building on the twelve scenarios and their early indicators already established, this report translates each scenario into concrete tactics an AI agent vendor should consider adopting, consistent with Step 9 of the scenario-planning process (”decide on actions for each scenario”). Tactics are organized into beginning, midst, and end-of-scenario actions where the distinction adds value, and are anchored throughout to the book’s core Value > Price > Cost rule and its seven-phase credit design process.

Set A: Pricing Mechanism Tactics

Outcome Rush (Solvable x Demand)

Vendors should move quickly to formalize outcome-layered pricing on top of existing credit infrastructure rather than replacing it, since the book’s own guidance is that credits are “how you get there without repricing trauma”.

Early action: publish OAR methodology transparently to build trust ahead of competitors, since governance and explainability become a trust premium once outcome pricing goes mainstream.

Mid-scenario action: build tiered contracts that blend a credit floor with an outcome-based upside, protecting margin while capturing willingness to pay for provable value.

Late action: renegotiate legacy usage-credit customers into outcome tiers proactively, before competitors use outcome pricing as a wedge to displace incumbents.

Blind Faith Credits (Hard x Demand)

Since buyers want credits despite unreliable attribution, vendors should double down on Phase 5 and 6 of the design process, predictability and governance, as the primary axis of competition.

Early action: invest in usage estimators and failure/refund policies that make bills forecastable even without outcome guarantees.

Mid-scenario action: build audit dashboards and anomaly alerts as a visible trust feature, marketed explicitly as compensating for attribution uncertainty.

Late action: avoid the temptation to overclaim outcome linkage prematurely; vendors that quietly build attribution capability in the background will be positioned to migrate customers smoothly once the technical problem resolves.

Silent Ledger (Solvable x Resist)

With attribution solved but buyers resistant, vendors should use internal value data to inform packaging without forcing a pricing-model change buyers are not ready for.

Early action: keep pricing on familiar subscription or per-seat terms while quietly instrumenting outcome data for internal tiering and expansion decisions.

Mid-scenario action: introduce outcome-based pricing as an optional, opt-in tier for sophisticated buyers only, letting early adopters self-select rather than forcing migration.

Late action: use accumulated case studies and proof points from opt-in customers to gradually shift buyer sentiment, treating this as a multi-year education campaign rather than a pricing sprint.

Frozen Metrics (Hard x Resist)

In the least favorable quadrant for the book’s central thesis, vendors should preserve credit-readiness as a latent capability without forcing adoption.

Early action: keep legacy per-seat or subscription pricing as the primary commercial model while maintaining credit weight tables and wallets in a dormant, ready-to-activate state.

Mid-scenario action: compete primarily on product capability and service quality rather than pricing innovation, since the market is not ready to reward pricing sophistication.

Late action: monitor the axis indicators closely (OAR movement, RFP language) so the organization is not caught flat-footed if either uncertainty resolves faster than expected elsewhere in the market.

Set B: Competitive Architecture Tactics

Walled Gardens of Excellence (Closed x Specialist Defensible)

Vendors should anchor credit weights explicitly to workflow and context value rather than model access, since the model itself is a commodity input in this scenario.

Early action: document and market the specific context moat (proprietary integrations, accumulated customer context) that justifies premium credit pricing independent of the underlying frontier model.

Mid-scenario action: build switching-cost-reinforcing features (deep workflow integration, accumulated agent memory) that make the specialist layer, not the model layer, the sticky asset.

Late action: negotiate favourable long-term terms with frontier model vendors while differentiation is strong, since bargaining leverage may erode if the market shifts toward Frontier Monopoly.

Frontier Monopoly (Closed x Frontier Catches Up)

Vendors should resist the drift toward cost-plus, token-markup credit design even under margin pressure, since this is the exact anti-pattern the book warns against.

Early action: identify and double down on the few genuinely defensible differentiation vectors remaining (vertical-specific compliance, data privacy posture, service-level guarantees) rather than competing on raw capability.

Mid-scenario action: pivot value proposition toward governance, trust, and packaging simplicity as the frontier vendor’s own agent offerings become commoditized alternatives.

Late action: consider consolidation or exit strategies for product lines where genuine differentiation has fully eroded, redirecting resources toward areas of the portfolio where a moat still exists.

Cambrian Explosion (Open x Specialist Defensible)

Vendors should prioritize interoperable credit-weighting schemes and machine-readable pricing schemas early, since ecosystem diversity rewards easy switching and combination rather than punishing it.

Early action: publish open, well-documented APIs and standardized credit denomination logic ahead of competitors to capture first-mover advantage in an interoperable ecosystem.

Mid-scenario action: build orchestration and multi-model routing capabilities as a core product feature, since customers will value agents that intelligently combine multiple open-weight models.

Late action: pursue partnerships or credit-acceptance agreements with complementary specialist vendors to build network effects around a shared, portable credit standard.

Commodity Soup (Open x Frontier Catches Up)

Vendors should shift the value narrative toward speed of iteration, integration depth, and trust credentials, since technical capability alone stops being a defensible pricing anchor.

Early action: compress the credit price per unit toward the cost floor while protecting margin through packaging and bundling rather than per-unit pricing power.

Mid-scenario action: invest disproportionately in customer success, onboarding speed, and governance certifications as the primary differentiators buyers can still perceive and pay for.

Late action: consider strategic pivots toward adjacent categories (data, workflow orchestration, vertical specialization) where commoditization has not yet fully arrived.

Set C: Infrastructure and Governance Tactics

Global Credit Commons (Harmonized x Broad Fungibility)

Vendors should invest early in interoperable APIs and standardized credit denomination logic, since first movers capture outsized network effects in a genuinely portable credit ecosystem.

Early action: join or help shape emerging cross-vendor credit and identity standards (building on A2A, AP2, and MCP-adjacent protocols) rather than waiting for consensus to form without vendor input.

Mid-scenario action: build credit-acceptance partnerships with adjacent, non-competing agent vendors to expand the effective size of the customer’s usable credit pool, increasing switching costs into the ecosystem as a whole rather than into any single vendor.

Late action: compete on breadth of ecosystem partnerships and interoperability credentials as a primary sales differentiator once cross-vendor fungibility becomes a buyer expectation.

Orderly Silos (Harmonized x Narrow Fungibility)

With compliance simplified but fungibility absent by design or strategy, vendors should invest freed compliance resources into agent family and system-level pricing within their own portfolio.

Early action: build bundle pricing and volume discounts across the vendor’s own agent family to capture the full value of orchestrated workflows, following the book’s guidance on agent-system-level EVE capture.

Mid-scenario action: use predictable, harmonized compliance requirements to expand confidently into new geographies without redesigning governance for each market.

Late action: monitor whether competitive pressure or customer demand eventually forces a shift toward cross-vendor fungibility, and maintain optionality to open the ecosystem if the market moves that direction.

Gray Market Credits (Fragmented x Broad Fungibility)

Vendors should build jurisdiction-aware compliance tagging directly into credit and wallet architecture, since technical portability is outpacing legal clarity.

Early action: build a compliance abstraction layer that can selectively constrain or flag credit flows based on the jurisdiction of origin and destination, treating this as core infrastructure rather than a bolt-on.

Mid-scenario action: engage proactively with regulators and industry bodies to help shape the eventual harmonization that will resolve the ambiguity, positioning the vendor as a responsible actor rather than an arbitrageur.

Late action: be prepared to rapidly restrict or reconfigure cross-border credit flows if regulatory enforcement catches up suddenly, avoiding the position of being made an example of during an enforcement wave.

Balkanized Agents (Fragmented x Narrow Fungibility)

Vendors should build regional pricing and governance modularity as a core design requirement, since a single global credit architecture will not survive contact with this environment.

Early action: design the credit and governance system with a modular, region-configurable architecture from the outset rather than attempting a one-size-fits-all global rollout.

Mid-scenario action: position the vendor as the partner that reduces multinational friction for buyers, explicitly marketing simplified multi-jurisdiction compliance and credit management as a premium differentiator.

Late action: consider selective market exit or partnership-based delivery (through local partners who absorb jurisdiction-specific compliance burden) in the most fragmented or costly regions, rather than bearing the full compliance cost directly everywhere.

Cross-Cutting Tactical Principles

Several tactics recur across multiple scenarios and are worth adopting as no-regret moves regardless of which future materializes.

• Maintaining credit-readiness (weight tables, wallets, usage estimators) even when not fully commercially exposed appears in Frozen Metrics, Silent Ledger, and Orderly Silos, making it a broadly resilient default posture.

• Investing in governance, auditability, and explainability tooling appears as a primary competitive lever in Blind Faith Credits, Frontier Monopoly, and Commodity Soup, suggesting this investment pays off across a wide range of futures even when the specific pricing mechanism or competitive structure remains uncertain.

• Building interoperable, standards-based APIs is valuable in Cambrian Explosion and Global Credit Commons and merely low-cost optionality in the other ten scenarios, making it a strong candidate for early, low-regret investment regardless of which scenario ultimately unfolds.

Monitoring Cadence Recommendation

Given the agile scenario planning approach already described for high-uncertainty, fast-moving environments, these twelve indicator sets should be reviewed on at least a quarterly cadence, with the OAR threshold, EU AI Act enforcement follow-through, and protocol interoperability announcements treated as the three highest-priority signals to monitor between formal reviews, since each sits at the intersection of two or more scenario sets and therefore carries outsized information value for the overall twelve-scenario map.

How AI was used for this post

This is preliminary work for the chapter The Future of Credit Based Pricing for the book Pricing for the Agent Economy by Steven Forth (author of this post), Michael Mansard and Wolfgang Ulaga.

Perplexity Deep Research with Anthropic Mythos was used for this post.

The opening sections on scenario planning were written by hand (using earlier writing I have done on this theme). Initial sets of projections and critical uncertainties were researched and documented.

These were bundled with the current draft of the Pricing for the Agent Economy book and provided to Perplexity Deep Research using Anthropic Mythos as the model. I would probably use the Council of Experts for this in a larger project and may do so when I work on the futures chapter of the book next week.

I set the time horizon as three years and the key issue to explore as the role of credits on the agent economy.

The followed a series of prompts to

1. Expand the projections

2. Expand the critical uncertainties
   These were then winnowed to the ones I felt were key to packaging and pricing decisions

3. Map the relationships between critical uncertainties and create clusters

4. Combine critical uncertainties to generate the full set of possible scenarios

5. Eliminate scenarios that are unlikely or redundant
   I then reviewed and selected the three sets used in this post

6. Used Perplexity to generate the three images

7. Used Perplexity to suggest early indicators for each of the sixteen scenarios
   Winnowed and edited the early indicators

8. Used Perplexity to generate tactics for each of the sixteen scenarios
   Winnowed and edited the tactics

(This updates an older post that originally appeared May 2022 on the old Ibbaka blog.)

Gerald Smith is one of a small number of people who has shaped how we understand pricing and pricing strategy. His book Getting Price Right is one of the best syntheses of behavioral economics and pricing available. He also worked with Tom Nagle on a series of important articles that put value maps (a standard tool used in pricing strategy) in context (more on that below).

At the Professional Pricing Society’s Spring 2022 conference in Chicago, Smith gave a compelling keynote. One of the themes was the Four Cs of Pricing and the importance of understanding how each of these four Cs impacts pricing. The four Cs of pricing are:

• Customer Value

• Customer Willingness to Pay

• Competition

• Costs

Note that Customer Value and Customer Willingness to Pay (WTP) are NOT the same thing. Confounding these two very different concepts, as some unfortunately do, is the source of much confusion and poor pricing decisions. Three years on I still hear people (including pricing experts) confuse ‘value metrics’ and ‘pricing metrics’ and even mash them together into ‘value pricing metrics.’ And there are still people who think WTP is the same thing as value. Sigh.

Pricing and Customer Value

This is the foundation for pricing innovative and differentiated offers. It is based on developing a deep understanding of how your solution provides value to a customer relative to the alternative. A quantified value model is needed for value-based pricing. The variables in the value model become the candidate pricing metrics (there are generally more variables than one would want to use as pricing metrics, complexity is NOT a virtue for pricing models).

Back in 2022, when this post was first written, building a quantified value model was still a hard thing to do. Generative AI has changed this and there are now agents like valueIQ that will help you to generate a value model, customise it for a customer, and keep it relevant.

Pricing and Customer Willingness to Pay

Willingness to Pay (WTP) is NOT the same as value. Vendors and consultants that take this approach are confused and will not be able to design an effective pricing model.

Willingness to Pay is important though, as it determines pricing levels and the final price paid.

WTP is not a static metric. It is highly contextual and depends on a number of factors:

• The value to the customer (see above)

• Ability to pay

• Competitive alternatives

• Other forms of value including emotional value and social value

Willingness to pay is something that can and should be shaped. That is one of the key jobs of product marketing and what a good sales person does instinctively.

Pricing and the Competition

Value is always relative to the alternative. Buyers will consider alternatives. These are sometimes as simple as doing nothing, always an option if not a good one, or solving the problem internally. In the summer of 2026, many software companies are finding that the alternative is a combination of Claude Code and vibe coding. See Can any agent compete with Claude?

One important decision in designing a price model is how easy it should be to compare price with the alternatives. In mature markets direct price comparison is unavoidable. Part of the definition of a mature market is that there is a common understanding of value and shared pricing mechanisms.

This is not the case with innovation, especially disruptive innovation or category creation. Here one may well want to use pricing metrics that precisely align with one’s own value and the way the target segment(s) see value. Finding the pricing metrics that create this alignment is a key goal.

Generative AI in the buying process is making it easier and easier for buyers to compare even very different models, and there is move towards open standards for representing value models and pricing models in formats that are easy for AIs to parse. See The Value Project.

Even in mature markets there can be opportunities for pricing innovation. A company that comes up with a new pricing metric, one that does a better job of tracking value and moving risk to the vendor and away from the seller, can often come to dominate an established market. This is what is happening with the move to subscription models and usage based pricing.

Pricing and Costs

Cost plus pricing is generally regarded as the least effective way to price (with certain exceptions where the customer is in control of the deliverables or it is very difficult to forecast effort). That does not mean that costs are irrelevant to pricing.

A fundamental concern is whether value to customer (V2C) is higher than cost to serve. If the answer is no, then there is no business to be had. More accurately, is V2C higher than the vendor’s opportunity cost. If the answer is ‘no,’ then there is no business opportunity.

This is not the only consideration though. In some cases one can design pricing to guide users into usage patterns that lower the cost to serve. This can be a very effective pricing tactic and can have a big impact on gross profit.

In some businesses, growing capacity and capacity utilization is a critical issue. In this type of business (many manufacturing and infrastructure companies are like this and it may be that compute falls into this category) growing overall volume and maintaining capacity can be a critical business consideration. Amazon AWS, Microsoft Azure, and the foundation model vendors can be thought of as infrastructure companies and growing capacity (to drive down unit costs) and maintaining utilization are key pricing considerations.

Interactions between the Four Cs

The four Cs are not independent of each other. Looking at two of the Cs together can provide new insights.

Customer Value and Competition

Value is relative to the alternatives, and in competitive situations this means the competition. What functionality is commoditized, where do you have the advantage, what does your competitor do better than you?

Customer Value and Customer WTP

Value is the foundation of willingness to pay. One should not pay more than the value received. When trying to determine willingness to pay, unpack how the different value drivers shape the customer’s response and ask how to communicate value more effectively.

Customer Value and Cost

One has to generate more value for customers, a lot more value, than it costs to create and deliver that value. In early stage markets the ratio of vendor cost to customer value is often very high. Assuming that one wants the ratio of 10X V2C to LTV (typical in growth markets) and a gross margin of 70% (also typical) then the costs to value ratio is 3%, in other words, one must deliver more than 33X more value to the customer than one incurs in variable costs!

Competition and Customer WTP

The lower the cost of the alternative the lower the willingness to pay. This is another way of saying that value is always relative to the alternatives, or in classic Economic Value Estimation (EVE) language, value is relative to the next best competitive alternative.

Competition and Cost

Understanding competitor cost to serve can inform pricing strategy and tactics. One will have more freedom to operate in segments where competitive alternatives have a relatively higher cost to serve, and one will generally want to avoid segments where competitors have a cost advantage. This is especially true where a young company is trying to enter a well established space. Pick a segment where you have a cost advantage.

Customer WTP and Cost

Sustainable companies need to be able to create and deliver value at a cost lower, much lower, than the customer’s willingness to pay. Before creating an offer this is both the fixed and variable costs. But once the offer is created it is the variable costs that are most important. Many bad pricing decisions are driven by finance’s desire to recover sunk costs. Sunk costs are just that, sunk. The time to worry about the implication of sank costs for pricing is before they are committed. Variable costs are the costs that matter when making pricing decisions.

Tom Nagle and Gerald Smith on Value Maps

One tool often used in pricing strategy is value maps. Value maps can be deceptive though. As Nagle and Smith have pointed out in two important articles, value maps tend to overstate the impact of value on WTP at the lower end of the market and to understate value and pricing power at the higher end of the market.

On the value map, at the lower end of the market most of the value comes from commoditized functionality where price is set by the market. As one moves to the right, up the value curve, more and more of the value comes from differentiated functionality. Pricing power comes from differentiated value and not from commodity value.

There is a value waterfall where Value in Use is (hopefully) larger than the Value in Exchange, which is (often) higher than the Perceived Value, which is always higher than Willingness to Pay.

See “A question of Value” and “Pricing the Differential” by Gerald Smith and Tom Nagle, published in Marketing Management in the May/June 2005.

Key Insights

Start to develop a defensible moat with one of these two tactics

• Gather outcome data across multiple customers - this is something the foundation models cannot do effectively and if the model cannot do it the do-it-yourself in Claude + Vibe Coding approach doesn’t work

• Integrate with other applications to deepen data gathering and build context that is not available from the LLMs

This is a start but it is not enough. A strong defence has depth and combines several types of differentiation.

Once you have established one (or both) of these two foundations build one of the four strong differentiation patterns described below

• Underwrite the outcome - provide guarantees or insurance that an outcome will be achieved (you need resources to do this)

• Become the embedded authority - this requires data, integrations, context and frameworks for interpretation

• Build an independent intelligence layer - leverage and compare multiple models in a ‘council of experts’ approach, develop small highly focussed models to complement or connect the large language models, train reasoning techniques specific to your domain

• Enable the edge to expert loop (and back) - take advantage of access to real-time data from the edge of the system, where the actions take place, that the large models cannot access or process in a timely manner, help your customers accelerate their OODA loop (Observe, Orient, Decide, Act)

A company with limited resources to build only one moat first should build D8 embedded context or D3 outcome data not because either is individually the strongest differentiator, but because each has the most leverage for adding the others later.

The best defence is a defence in depth. Not one moat, but multiple moats, that defend from attacks in different directions.

In my previous post, Can any agent compete with Claude, I identified eight possible moats for agents trying to compete with the universal solvent of generative AI, the frontier models, and vibe coding. This post looks at how they can be combined.

Let’s begin by looking at the eight moats again.

Lock-ins

1. Risk transfer and accountability

2. Accumulated authority

3. Cross-customer outcome data — model execution as the asset

4. Position in transaction networks

Game changers

5. Be structurally adversarial to the platforms

6. Perishable, private, real-time information at the edge

7. Scarce complementary assets

Market shifts

8. Design so model improvement is a complement, not a substitute
(This one is not really a moat though, see below.)

It is worthwhile understanding these independently but they really gain traction when combined. Combinations can take two forms: layering, where each differentiator acts independently of the others, and if one is neutralised the others are still active (stacked strategies); integrations, where two or more differentiators work together to reinforce each other, but if one goes there is a risk that other connected integrations will fail as well (connected strategies).

In Can any agent compete with Claude? I argued that four traditional differentiators — process, public data, customer data, and UX — no longer hold against Claude Code, ChatGPT, and vibe-coding tools like Lovable and Replit. I then proposed eight moats as replacements, organized as Lock-ins (1–4), Game changers (5–7), and a Market shift (8). I closed with the thesis this analysis tests: “the best defence is depth, and agents that combine two or more of these strategies are likely to build the strongest positions.” I use Design Structure Matrices (DSMs) to look at the ways these eight differentiation tactics can be combined.

A DSM is a compact grid tool used to map, analyze, and optimize complex component relationships and to find the clusters. It is used in designing modular product architectures, to see how sets of equations interact (its original purpose) and anyother time you need to understand dependencies. I use it quite often to analyse value and pricing models. See the website DSMWeb for background and a rich collection of resources.

Two different matrices are required because “layering” and “synergy” are not the same question. The layering matrix is used to build up a layered defence. A synergy (or reinforcement) matrix asks “does having both moats together make each one stronger than either alone.” A pattern (combination of tactics) can score high on one and low on the other.

Validating the Eight Differentiators

Let’s start by doing some testing of the eight proposed differentiators to see how they stand up against the four-question moat test proposed in the previous post.

• Does the advantage strengthen with each additional customer? (data, network, actuarial)

• Does the next model release strengthen or weaken your differentiation? (complement vs. substitute)

• Are you stacking strategies? (Combining two or more strategies)

• To replicate it, would the buyer have to accept risk, acquire authority, or build a market — rather than write code? (structural vs. informational)

Closer examination surfaces one differentiator that is misclassified, one that has a blind spot, and one gap that needs to be filled.

#8 “model improvement as a complement” is a test, not a moat. This should have been obvious to me when I wrote as one of the tests “does the next model release strengthen or weaken your differentiation?” The examples I gave — Cursor’s model-agnostic harness, Cognition/Devin’s routing across labs — are architectural choices in service of other moats not sources of value in their own right. A buyer does not pay for “model-agnosticism”; they pay for the risk transfer, authority, network position, or data that model-agnosticism makes durable. It is not used in the below DSMs.

Blind spot: #3 conflates two different data assets. There is a difference between a context moat — “proprietary interaction histories, workflow-specific decision logs, and domain-specific outcome data” accumulated within a single account, which “compounds with use and is very hard for competitors to replicate” — and population-level statistics. Differentiator #3 as originally written (”a vendor running the same agent across 1000s of deployments knows the distribution of outcomes”) is a horizontal asset: cross-customer, portable, and the fuel for actuarial pricing. This is not the same as a vertical asset — one customer’s ten years of firm-specific precedent, embedded in a single relationship and non-transferable. This is structurally different and is the explicit moat source for the Domain Oracle archetype (Harvey, Abridge) and, in integration form, the Process Automator archetype (”the switching cost isn’t the AI capability — it’s the integration web”). This should be a separate moat.

The working set for the two DSMs below is therefore:

D1 Risk transfer & accountability,

D2 Accumulated authority

D3 Cross-customer outcome data

D4 Position in transaction networks

D5 Structurally adversarial to platforms

D6 Perishable/private/real-time edge data

D7 Scarce complementary assets

D8 Embedded context & integration depth

DSM 1 — Structural Dependency (Layering) Matrix

A moat is a true layering candidate — a stackable, independent defense — only if it keeps functioning when a different moat is neutralized. This DSM records, for each row, whether its continued operation depends on the column moat also being intact. A populated cell means “row cannot survive column’s removal without significant degradation.” Strong and Moderate cells indicate defences that need to be layered to be effective.

Freestanding moats — the safe layers. D2 (Authority), D7 (Scarce Assets), and D8 (Embedded Context) have empty rows: nothing else in the set has to be intact for them to work. A SOC 2 registration, a licensed balance sheet, and eighteen months of integration history are each real on their own terms, regardless of what happens to any other moat. These three are the foundation of a pure layering strategy — remove any one and the other two are unaffected.

Derived moats — conditionally independent. D3 (Cross Customer Outcome Data) and D6 (Real-Time Edge Data) each carry one moderate dependency on D8 (Embedded Context & Integration Depth): cross-customer outcome data and live edge telemetry both need to be bootstrapped through deep integration (you cannot observe outcomes or capture machine telemetry you are not wired into). Once the data asset exists, though, it persists even if the integration relationship with any single account changes, so these are “independent once achieved” — good layers for a mature business, weaker for early-stage.

Not standalone defenses: D1 (Risk Transfer) and D5 (Structurally Adverserial). These two differentiators fail as standalone defenses. Risk transfer without D7 (in the form of real underwriting capital) is an unbacked promise — indemnification a vendor cannot actually pay is worse than no indemnification, because it invites the very liability claim it was meant to prevent. Risk transfer without D3 (loss-history data) is guesswork, exposed to adverse selection the moment a sophisticated buyer notices. Symmetrically, being “structurally adversarial to the platforms” without D3 (Cross Customer Outcome Data) or D6 (Real-Time Edge Data) is an unsubstantiated claim — a self-declared “neutral router” with no independent benchmark data (D3) or live telemetry (D6) to prove neutrality is trivially copyable by anyone willing to make the same claim, including the platforms themselves. Both D1 ( and D5 are strategically real and valuable, but the DSM shows they are integration plays, not layering plays: they should never be deployed as a company’s only moat.

Strategic reading. A defense-in-depth architecture should always secure at least one of D2 Accumulated Authority, D7 Scarce Assets, D8 Embedded Context & Deep Integration first. These are the moats that survive an attack on any other single moat. Establish one or more of these before spending on D1 Risk Transfer or D5 Structurally Adversarial, which amplify an existing foundation rather than substitute for one.

DSM 2 — Synergy (Reinforcement) Matrix

This is the complement to DSM 1: it scores how much each pair, combined, reinforces the value of both (0 = negligible, 1 = mild, 2 = moderate, 3 = strong), regardless of whether one structurally requires the other.

The strongest pairs (score 3), and why they matter:

• D1 Risk Transfer × D3 Cross Customer Data and D1 Risk Transfer × D7 Scarce Assets — the vendor’s loss history and actuarial data on agent failure modes become proprietary; and no risk transfer is credible without capital behind it. These two pairings are the entire mechanism of AIUC, Armilla, and Klaimee.

• D2 Accumulated Authority × D4 Position in Transaction Networks, D2 Accumulated Authority × D7 Scarce Assets, D2 Accumulated Authority × D8 Embedded Context & Integration Depth — accumulated authority is the most synergistic node with three high-scoring partners. Authority is what turns a network position into something of real value (Mastercard, Okta), turns a scarce human asset into an accountable one (Basis’s signing CPA), and turns integration depth into something the buyer cannot casually re-permission (Bretton AI’s regulator-facing “Trust Infrastructure”).

• D3 Cross-Customer Data × D5 Structurally Adversarial, D3 Cross-Customer Data × D6 Real-Time Data, D3 Cross-Customer Data × D8 Embedded Context and Integration Depth — cross-customer outcome data is the second most connected node. It is what makes an “adversarial” referee credible (Vals AI, Tropic), what makes live telemetry predictive rather than merely descriptive (Dragos, CrowdStrike’s “closed-loop system that gets smarter with every engagement”), and it is largely generated by deep integration (D8) in the first place.

• D5 Structurally Adversarial × D6 Real-Time Data and D6 Real-Time Data × D8 Embedded Context and Integration Depth— the freshest, most perishable data and the most adversarial/neutral positioning reinforce each other because being the router or auditor requires seeing what is happening right now, not what a training run captured months ago; and neither is possible without being deeply wired into the systems generating that signal.

Reading the graph, not just the cells. D8 embedded context and D3 outcome data are the two most central nodes — each has four or more strong (score-3) connections. This is the single most useful strategic fact in the matrix: a company with limited resources to build only one moat first should build D8 embedded context or D3 outcome data, not because either is individually the strongest differentiator, but because each has the most leverage for adding the others later. D5 structurally adversarial and D7 scarce assets are the least connected nodes outside their one or two strongest partners — consistent with the finding that D5 structurally adversarial is a derived, amplifying moat rather than a hub, and confirming that D7 scarce assets is a genuinely independent resource that reinforces others without needing much reinforcement itself.

Key Combinations vs. Claude Code and Vibe Coding

Four patterns emerge from combining the highest-synergy clusters with the dependency structure. Each is scored against the four-question moat test and the complement filter, then assessed specifically against the DIY threat: a buyer who has gotten a working demo from an agent vendor, then goes to try recreating it with Claude Code (or ChatGPT/Perplexity) and Lovable/Replit/Bolt.

The Underwritten Outcome — D1 + D3 + D7

Risk Transfer + Cross Customer Outcomes + Scarce Assets

Mechanism. Population-level outcome data prices the risk; a scarce complementary asset (insurance capital, balance sheet) backs it; the vendor sells accountability, not just software. Examples: AIUC’s certification-plus-insurance bundle, Armilla AI’s Lloyd’s-backed warranties, Klaimee’s parametric claims, ElevenLabs putting AIUC-1-backed insurance behind its voice agents.

Moat test: Strengthens with every customer (more claims data improves pricing) — yes. Improves with better models (a smarter Claude increases the volume of consequential agent actions needing insurance, which grows the addressable underwriting pool) — yes. Stacking — yes, three differentiators at once. Replication requires accepting risk, not writing code — this is the cleanest possible pass: a vibe-coded agent cannot self-indemnify by definition.

Effectiveness vs. DIY. Very high, and it is the pattern DIY is structurally unable to touch at any stage — a Lovable app has no balance sheet and no loss history, no matter how good the underlying model is. Its weakness is not against DIY but against time: attribution and actuarial infrastructure take years to build, so it is a poor answer to a buyer stalling today.

The Embedded Authority Graph — D2 + D8 + D4

Mechanism. Deep, scoped permissions; workflow embeddedness that compounds; a registered position in a network of counterparties. Examples: Bretton AI’s ACV growth from $25k to $201k as authority compounded inside regulated banks, Norm Ai’s supervising-attorney agents, Catena Labs’ verified agent identities under a bank charter, Okta extending IAM to agents as non-human identities (Pricing Innovation).

Moat test: Strengthens with scale — yes, authority and integration compound with tenure. Improves with better models — yes, a smarter agent operating under the same authority graph does more without re-permissioning. Structural replication barrier — strong; re-granting a web of permissions is “expensive, slow, and politically fraught,” exactly what the article claims.

Effectiveness vs. DIY. This pattern is asymmetric across the buying funnel in a way the other three are not. At the point of a first proof-of-concept, a buyer’s own Claude Code instance starts with zero authority and zero integrations too — so B does not obviously beat DIY on day one. Its power is entirely in the second mile: once a vendor’s agent has genuinely earned six months of scoped access and eighteen months of integration, “let me see if I can do it myself” means re-earning every one of those grants from scratch, which is precisely the point the manuscript’s Process Automator archetype makes about integration depth. Effectiveness should be read as low-to-moderate at acquisition, very high at renewal and expansion — the exact stage where the article says buyers “stall.”

The Independent Intelligence Layer — D3 + D5 + D6

Mechanism. Neutral, multi-model positioning, backed by both population-level benchmark data and live, model-comparison telemetry. Examples: OpenRouter routing ~25 trillion tokens/week across hundreds of models with the tagline “the era of picking a single model is over,” Vals AI’s independent lab benchmarks, Tropic’s buyer-side price intelligence exposed via MCP directly into Claude and ChatGPT (Pricing Innovation).

Moat test: Strengthens with scale — yes, more routed traffic means better routing data. Improves with better models — this is close to a perfect pass by construction: every new frontier release is simply one more option the router can offer, which is the manuscript’s own Cursor/Devin example of “model-agnostic by design.” Counter-positioning — genuine, in Hamilton Helmer’s sense that “the moat is that the incumbent’s business model forbids imitation”: Anthropic cannot credibly become the vendor that tells buyers when not to use Claude.

Effectiveness vs. DIY. This is the pattern most directly aimed at the specific competitive threat the article names, because it attacks the article’s other named problem — “the frontier models are eating through budgets” — head-on, and its value proposition (lower cost, better routing, independent quality data) is demonstrable in a single sales conversation rather than requiring months of accumulated trust. Where Pattern B is weak at the top of the funnel, Pattern C is strong there: a buyer who has just watched their AI spend balloon on one vendor is receptive to “we route across models and cut your bill” immediately, which makes it the best candidate for arresting the “let me see if I can do it myself” stall the article describes, rather than only defending against it after the fact.

The Edge-to-Expert Loop — D6 + D8 + D7

Mechanism. Live, private telemetry the labs structurally cannot see; deep technical embedding to capture it; a scarce, licensed human or balance-sheet asset held in reserve for the cases that need it. Examples: Dragos’s 5+ petabytes of daily OT/ICS telemetry, Altana’s live 140-million-node supply-chain graph with customs recognition, Augury’s Industrial Context Graph, CrowdStrike’s closed-loop threat telemetry, paired with Crosby’s registered-law-firm liability model and Basis’s CPA-signed returns (Pricing Innovation).

Moat test: Strengthens with scale — yes, more sensors and more cases sharpen both the telemetry and the expert triage. Improves with better models — yes, a smarter model applied to private real-time data is strictly better, never a substitute for it, which is the manuscript’s clean test for a context moat: “if OpenAI or Anthropic released a foundation model tomorrow that matched your domain capability exactly, how much of your competitive advantage would survive? Most of it.”

Effectiveness vs. DIY. Highest absolute defensibility of the four patterns — Claude Code and vibe coding have no path to a customs authority’s trust, a licensed attorney’s malpractice exposure, or petabytes of live OT telemetry, regardless of model quality. The limitation is scope, not strength: it only exists where a real-time, private, physical or regulated signal exists at all, which excludes most generic knowledge-work agents — precisely the category where Claude Code and vibe coding are currently doing the most damage to third-party agent vendors, per the article’s own framing (”buyers... taking the ideas and going away to see if they can do something themselves”).

Synthesis: Sequencing, Not Choosing

None of the four patterns is uniformly best, and the article’s own diagnosis — traction at top and middle of funnel, then a stall — points to a sequencing answer rather than a single winner. Pattern C is the only one whose value proposition is demonstrable immediately, which makes it the right lead against the specific “let me try it myself” objection; Patterns A and B are not weaker moats, but they are slower ones, built during the relationship rather than pitched at its start. A vendor building for defense in depth should treat C as the wedge that keeps the deal from stalling in the near term, then use the engagement it buys to accumulate B (authority and integration depth) and, where the vertical supports it, D (edge data plus a scarce professional or balance-sheet backstop) or A (once enough outcome data exists to underwrite). This sequencing is itself a form of layering across time rather than across mechanisms — the vendor is never dependent on any single pattern being sufficient at every stage of the buyer relationship.

Pricing Implications

Every pattern implies a distinct pricing architecture from the manuscript’s Layer Cake (Role, Access, Usage, Output, Outcome) and archetype framework, consistent with the article’s closing note that all eight original moats are “monetizable only through outcome- and credit-based structures, not seats or subscriptions — the moat and the pricing model are the same design problem.”

This connects directly back to Tom Nagle’s original insight that pricing must anchor to the customer’s economic value relative to their next-best alternative, not to cost — for every pattern above, the “next-best alternative” a buyer is now comparing against is explicitly Claude Code plus a vibe-coding tool, at close to zero marginal cost. The four patterns above are the structural conditions under which that comparison stops being apples-to-apples: DIY has no balance sheet (A), no accumulated authority graph (B), no cross-model routing incentive of its own (C), and no access to live, private, regulated signal (D).

I get to speak with many people building and commercialising agents. The most common objection people are getting from buyers these days is …

“That makes sense. Good job. Very impressive. Let me see if I can do it myself.”

The combination of Claude Code (and in 90% of cases it is Claude Code with ChatGTPT and, surprisingly, Perplexity distant runners up) with vibe coding (Lovable and Replit come up most often) have empowered buyers with a new confidence that they can do an awful lot on their own. In many cases, third party agents are seen as being superfluous.

The other issue is budgets. The frontier models are eating through budgets. Every dollar that can be made available is going to buy tokens on one or another of the platforms (but mostly Anthropic). Even sophisticated users, who know they can get as good or better performance at lower price by mixing and matching models, are expending their time and energy with the foundation models.

People taking agents to market are getting traction at top of funnel, and even to middle of funnel, but many buyers are then stalling. They are taking the ideas and going away to see if they can do something themselves.

Is this a phase of the market or is it the new steady state?

Is there space above the foundation models for companies building agents to create economically meaningful differentiation?

No one knows the answer to these questions. They form a critical uncertainty.

‘Critical uncertainty’ is a concept from scenario planning. They are the axes that scenarios are built from. In a later post I will share more of the critical uncertainties that will determine the paths taken by the agent economy as they resolve.

What we can do at this point is sketch some of the things agents will need to do to carve out space to build a scalable business.

“If we want to know what a business is, we have to start with its purpose. And its purpose must lie outside the business itself. In fact, it must lie in society since a business enterprise is an organ of society. There is only one valid definition of business purpose: to create a customer." Peter Drucker in his 1954 book The Practice of Management.

You create a customer by providing something of value that cannot easily be found elsewhere. Today, many agents struggle with both ‘create something of value’ and ‘be easily found elsewhere.’ For agents, the ‘elsewhere’ is what can be done by a potential customer with the foundation model and vibe coding.

It is not all that hard to build a set of deep contexts and linked prompts that does something the underlying AI struggles to do. But wait a few months, or weeks, and the model is likely to have caught up. It can access the context and learn the prompts. In many cases, advanced reasoning will come up with something as good or better than what a group of human experts can achieve. This is a classic Red Queen Game.

A Red Queen Game

As the Red Queen said in Through the Looking-Glass, and What Alice Found There (Lewis Carroll 1871) …

"Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!"

In economics (and evolutionary biology) a Red Queen Game is one in which one has to continually innovate just to maintain a position and sustaining innovation (in the Clayton Christensen sense) does not get you ahead.

To win in a Red Queen Game one has to

• Anticipate Shifts: Predict rival moves rather than just reacting to them.

• Change the Game: Introduce disruptive business models that break the existing cycle.

• Focus on Lock-in: Build high switching costs through deep ecosystem integration.

‘Lock-in’ is also referred to as ‘building a moat.’ How can agents build a moat against the constant improvements to the foundation models, which are moving faster than any innovation in history? And this is not shallow innovation, transformer models and the Large Language Models built on them are one of the defining innovations of our species, on a par with writing.

Four ways agents cannot build moats

Four ways agents cannot build moats are processes, public data, customer data user experience.

Your deeply thought, validated in practice, proprietary process or methodology is not a sustainable moat. The AIs will discover, replicate and extend any process in ways that we cannot imagine and that will be better than what any human can do. Even if you build in the loops to use AI to improve your process it will catch up and overtake you. This is a Red Queen game where you can’t even run fast enough to stay in the same place.

Most agents make some use of public data, either directly or through an LLM. The AI’s spiders are likely to be better than yours, to move faster, and go deeper. Public data is getting wider and wider, and this is why it is so hard to keep up with the AIs.

Some companies are trying to use their user’s own data to build a moat. This is mostly legacy vendors, who feel some sort of proprietary right to the data they have collected or generated for their users. They are increasingly trying to put tolls on the use of this data and access to their APIs. Will users put up with this? I suppose this is another critical uncertainty. Will the large vendors have the clout to make this stick or will users push back and demand unfettered access to what they see as their own data and that they want to use for their own AI built applications

There was a period from about 2005 to 2025 where user experience was a critical differentiator. No more. AI’s are establishing a new set of design patterns and sucking everything into them (see The AI Aesthetic by Jim Nielsen). One of the most provocative comments I heard in 2025 was from the CEO of a growth stage company with about 500 employees. “We have downgraded our CRM to the most basic subscription. We see it as no more than a fancy database. We are vibe coding our own UIs on top of it to get the functionality we want.” The collision of AI native UX and vibe coding has erased UX as a differentiator.

How to build a moat

So what can agents do to build a moat? Here are eight ideas.

Lock-in Moats

1. Risk transfer and accountability. A buyer who vibe-codes their own agent owns 100% of the downside. An independent vendor can sell indemnification, warranties, SLAs, audit trails, and errors-and-omissions coverage — the agent as a counterparty with skin in the game, not a tool. Anthropic will never accept liability for what Claude does in your workflow; that refusal is structural, and it’s the vendor’s opening. In value-model terms this is a pure risk-reduction driver, and it’s one DIY can never match because you cannot indemnify yourself. It also compounds: the vendor’s loss history and actuarial data on agent failure modes become proprietary.

Examples

• AIUC — the “SOC 2 for AI agents”: a certification standard (AIUC-1) bundled with insurance underwriting, explicitly sold as a way to shorten enterprise procurement (AIUC).

• Armilla AI — Lloyd’s-backed MGA writing affirmative AI liability coverage and AI performance warranties, backed by Swiss Re and Chaucer; raised $25M in January to cover agent failures and EU AI Act defence costs (FinTech Global).

• Klaimee — YC-backed, $5.5M seed for insurance-backed warranties on autonomous agents, with parametric claims triggers pulled from system logs (The Insurer).

• ElevenLabs — first agent vendor live with AIUC-1-backed insurance on its voice agents, after 5,000+ adversarial simulations; insurance as a sales-cycle weapon (PR Newswire).

2. Accumulated authority. Agents act, and acting requires permission: signing authority, payment credentials, delegated approvals, standing access to counterparties’ systems, regulatory licenses, certifications (SOC 2, FINRA, HIPAA, FDA). This maps to the “access” and “actions” layers of your six-metric hierarchy — the moat isn’t the intelligence, it’s the accumulated, scoped, audited right to act. Re-granting that web of permissions to a homegrown replica is expensive, slow, and politically fraught inside the buyer’s own organization. Compliance officers are the vendor’s best friends.

Examples

• Bretton AI (ex-Greenlite) — AML agents running inside OCC/FDIC/Fed-regulated banks; its “Trust Infrastructure” embeds regulatory guidance, and authority compounds into price: ACV grew $25k → $85k → $201k (Business Wire).

• Norm Ai — operates its own AI-native law firm with supervising attorneys, and builds agents that supervise other agents; $120M Series C at $1.2B (TechCrunch).

• Catena Labs — “AI-native bank” giving agents verified identities, accounts, spending caps, and a human kill switch; has filed for a National Trust Bank charter (Catena).

• Okta — extending IAM to agents as first-class non-human identities (Agent Gateway, privileged credential management, universal logout), riding 8,200+ integrations (Okta IR).

This is part of the strategy we are taking at valueiQ.ai. We are building and validating the world’s largest collection of economic value models and defining the connections between them.

3. Cross-customer outcome data — model excution as the asset. The derived layer is different from the raw data: a vendor running the same agent across 1000s of deployments knows the distribution of outcomes — what works, what fails, what an outcome is worth, at what degree of confidence. No single buyer and no foundation model has that. This is what lets the vendor price on outcomes, offer guarantees (see #1), and benchmark. The vendor with the best empirical model applied to a large amount of relevant data can price to value, and the pricing capability itself becomes the moat.

Examples

• Intercom Fin — a public outcome price list: $0.99 per resolution, $9.99 per qualification, refunded if the customer returns — only underwritable with resolution-rate data across the installed base (Intercom).

• Sierra — “you pay only when the software achieves specific, valuable outcomes”; unresolved conversations are mostly free (Sierra).

• Tropic — benchmarks from 14,000+ suppliers and $21B+ of pooled spend, exposed via MCP into Claude and ChatGPT — the data, not the model, is the product (Tropic).

This is the other part of valueIQ.ai’s strategy.

4. Position in transaction networks. An agent that sits between parties — matching, clearing, escrowing, negotiating — has network effects that intelligence can’t substitute for. A smarter model makes a marketplace participant better; it doesn’t conjure the other side of the market. Liquidity, counterparty reputation systems, and settlement rails are classic moats that survive model improvement. In an A2A world, reputation capital among agents may be the scarcest asset of all: a buyer’s homegrown agent starts with zero verified track record.

Examples

• Stripe — Agentic Commerce Protocol with scoped tokens and shared payment tokens, positioned as a protocol-agnostic commerce layer (Stripe).

• Mastercard Agent Pay — “Know your agent”: only registered agents can transact, governed by network tokens — defining who may transact at all (Mastercard).

• Pactum — negotiation agents occupying the seat between 60+ large buyers and their suppliers — a seat neither party’s own model can hold (Pactum).

Changing the game

5. Be structurally adversarial to the platforms. There are roles the foundation model vendors cannot credibly occupy: the neutral multi-model orchestrator, the buyer’s agent negotiating against AI vendors, the auditor of AI outputs, the cost-optimizer routing away from expensive tokens. Frontier models are eating budgets, the agent that verifiably reduces token spend has a value story the platforms will never tell. This is counter-positioning in Hamilton Helmer’s Seven Powers sense — the moat is that the incumbent’s business model forbids imitation.

Examples

• OpenRouter — $113M Series B; ~25 trillion tokens/week routed across hundreds of models. “The era of picking a single model is over” — a value proposition no lab can sell (SiliconANGLE).

• Vals AI — independent, in-house benchmarks grading the labs in finance, law, and healthcare; the business is being the referee (Vals AI).

• Tropic (again) — buyer-side price intelligence structurally opposed to every seller-side platform (Tropic).

6. Perishable, private, real-time information at the edge. Model training cadence, however fast, is still batch. Agents wired into streams the labs will never see — machine telemetry, market microstructure, a supply chain’s live state — occupy a temporal niche. The model gets smarter; it doesn’t get more present. The moat is the integration and the latency, not the reasoning.

Examples

• Dragos — 5+ petabytes of daily OT/ICS telemetry; “there is no larger, similar training dataset in the industry” (Dragos).

• Altana — live supply-chain graph of 140M buyer-supplier connections, with AI Product Passports recognized by customs at ports moving 70% of global trade — regulatory recognition stacked on private data (Altana).

• Augury — role-based industrial agents on an “Industrial Context Graph” of live machine-health signals (PR Newswire).

• CrowdStrike — Agentic MDR, “a closed-loop system that gets smarter with every engagement” on live threat telemetry (CrowdStrike).

7. Scarce complementary assets. Wrap the agent around something non-digital and rationed: capital (the agent that can commit funds), inventory, insurance balance sheet, licensed human experts on call for the 2% of cases requiring judgement and legal standing. Buyers can replicate the software; they can’t vibe-code a balance sheet.

Examples

• Crosby — a registered law firm “liable for each contract,” charging $250–$1,000 per contract instead of billable hours; $60M Series B. The scarce asset is legal standing plus malpractice exposure (Forbes).

• Corgi — AI-native insurer at a $1.3B valuation; the complement is balance-sheet underwriting capacity (FinTech Global).

• Basis — long-horizon accounting agents inside licensed CPA firms (~30% of the Top 25); the CPA who signs the return is the rationed asset (Business Wire).

• Flexport — agents layered on a licensed customs brokerage and physical freight ops, including an “Audit Your Customs Broker” agent (Flexport).

Anticipate shifts

8. Design so model improvement is a complement, not a substitute. The fatal architectures are the ones where a better Claude replaces the agent. The durable ones are where a better Claude makes the vendor’s outcome data, authority graph, and network position more valuable — every capability jump widens the gap between what the vendor can guarantee and what Do-It-Yourself can. This is the test that separates all of the above from process/prompt moats.

Examples

• Cursor — “all of our harness abstractions are model agnostic”; weeks of per-model harness tuning so each frontier release makes the product better, not obsolete (Cursor).

• Cognition/Devin — “model-agnostic by design,” routing across Anthropic, OpenAI, Google, and its own models per task (Devin).

• OpenRouter and Vals AI reappear here — routers and referees are the purest cases of appreciating with the tide.

A moat test for agent vendors

Four questions that you can use to test your differentiation strategy.

• Does the advantage strengthen with each additional customer? (data, network, actuarial)

• Does the next model release strengthen or weaken your differentiation? (complement vs. substitute)

• Are you stacking strategies? (Combining two or more strategies)

• To replicate it, would the buyer have to accept risk, acquire authority, or build a market — rather than write code? (structural vs. informational)

Anything that fails all four of these is trying to run along beside the Red Queen, which gets exhausting, and in the long run will fail. And note the pricing corollary: every one of the durable moats — risk transfer, outcome data, network position — is monetizable only through outcome- and credit-based structures, not seats or subscriptions. The moat and the pricing model are the same design problem.

The best defence is depth, and agents that combine two or more of these strategies are likely to build the strongest positions. That will be the theme of our next post.

Roger Martin’s strategic choice cascade is a powerful way to organise strategic thinking. It can be used at many level of resolution, from national innovation strategy (see Roger’s book with James Milway, Canada: What it Is, What it Can Be), to corporate strategy (it has been used to great effect by everyone from Proctor and Gamble to Lego). I use it to frame my personal learning plan each year. We applied it while developing the ideas in the Pricing for the Agent Economy, the book I am writing with Michael Mansard and Wolfgang Ulaga that will be published with INSEAD’s support this October.

The core resources for this are available on Roger’s website.

The basic idea of the strategic choice cascade is that you need to make choices in a certain order, that each choice level constrains the next. There is also a feedback channel back up. For example, I may have the Aspiration to Cure Cancer, but I lack the Capabilities that would let me do this (though I could make some contribution through donations etc.).

The five questions to answer are, in order …

1. Winning Aspirations: What are your winning aspirations (what does it mean to win)?

2. Where to Play: Given, your winning aspirations, where should you play?

3. How to Win: What do you need to do to win on the playing field you have chosen?

4. Capabilities: What capabilities are needed to execute on your how to win choices?

5. Systems: What systems will support those capabilities.

Trying to answer these questions out of order leads to confusion.

Let’s apply these questions to the choices made around the agent economy and the design of a credit based pricing system.

Note: Some of the terminology below references parts of the Credit Pricing System from the book.

Winning Aspirations

The first discipline is negative: adopting credits is not an aspiration. “We need credits because Salesforce and Adobe have them” is a Systems-level choice masquerading as a Winning Aspiration — It is an example of an ‘out-of-order failure’, and the most common one in the market today. Martin also cautions against over-polishing this box; the aspiration should get refined as you move through Where to Play and How to Win choices.

Sangeet Paul Choudary’s work in Reshuffle gives the aspiration its content. Generative AI has melted the constraints that organized B2B software economics — the human as the unit of value, the labor-cost ceiling on willingness to pay, the assumption that consumption happens at human pace and scale. In a reshuffle, power accrues to whoever manages the constraints that emerge in their place: attribution, trust and governance, and the machine legibility of commercial terms. A defensible winning aspiration is something like:

“Win the value conversation in our category as consumption shifts from humans to agents — be the vendor whose pricing is trusted by human buyers, legible to buyer-side agents, and provably aligned so that Value > Price > Cost on every transaction.”

This makes trust and alignment the definition of winning — every new pricing model is also a trust model. And it keeps the aspiration technology-agnostic: credits appear only later, as the mechanism that satisfies it.

Where to Play

This is the level where the agent economy most radically rewrites the traditional answer. Where to Play is a vertical position in the agent stack, and that position determines which pricing architectures are available. There are four nested choices:

1. Stack layer. Infrastructure prices on cost units and races toward lowest cost (tokens are an example); orchestration creates value it struggles to capture; the application layer is where credits do their real work; the outcome layer offers the highest theoretical margins but is gated on attribution. Choudary’s “follow the constraint” logic says the same thing from the other direction: value migrates toward the attribution and governance bottleneck, so position yourself where you can build toward it.

2. Archetype. Domain specialist, process automator, orchestration platform, outcome partner, data moat builder, trust infrastructure — each archetype is really a pre-packaged Where to Play choice with a pricing architecture attached.

3. Depth vs. breadth. Deep domain mastery and broad orchestration are incompatible positions at scale, and the choice is decisive for whether your credit system meters bounded outcomes or coordination flows.

4. Segments and metered surface. Building value models segment by segment is itself a where-to-play choice: which buyer economics you anchor to, and which inputs, actions, outputs, and outcomes you can make part of your pricing model. There is a new sub-choice with no SaaS precedent: you now play in front of two audiences — human procurement and buyer-side agents reading your value and pricing models. See The Value Project for open source JSON schema for value models and pricing models. These schema make these models visible to and computable by AI.

How to Win

Where to Play and How to Win choices are tightly coupled. For an application-layer company, where most credit adoption is happening, the How to Win choices aret o win by making the credit the most trustworthy claim about value in your market. Concretely:

• Credits as the variance absorber. Agent work varies enormously in complexity from one task to the next; a credit weight table absorbs that variance so neither side is underwater. Salesforce’s move from a flat per-conversation price to Flex Credits was a structural correction of this problem.

• Value-anchored, not cost-anchored, weights. Credit weights should derive from segment-level economic value models, with the effective price per action capturing a defensible share of the value delivered relative to the customer’s next-best alternative. This is the difference between credit-native design and credits-in-name-only — and since most implementations in the market today are the latter, with seat-and-subscription logic running underneath a credits label, genuine alignment is a real differentiator rather than table stakes.

• Two independent dials. Price per credit is the stable, public, market-level statement of what a unit of agent-delivered value is worth; credits per action is the calibration layer. Keeping them separate lets you move economics without redefining the unit your customers have learned to trust.

• Predictability as a feature. The credit wallet preserves the psychological safety of the subscription — I bought 100,000 credits and I know what I am buying — while enabling variable consumption underneath.

• The outcome bridge. Credits let you operate at the application layer while accumulating the attribution evidence that eventually unlocks outcome pricing. How to Win is a trajectory, not a static position.

• Machine legibility. Publish value models and pricing models in schemas that buyer-side agents can parse. An illegible pricing page is increasingly invisible to a growing share of the procurement layer. (See The Value Project)

Capabilities

The test at this level is can’t/won’t: competitors either can’t replicate your must-have capabilities, or won’t because doing so damages them elsewhere. Both branches are unusually strong for credit-native pricing:

• Can’t: the context moat. Segment-level value models, action-level cost models, and the accumulated interaction and outcome data that calibrate your credit weights compound with use and do not depreciate as foundation models improve. A competitor can copy your pricing page in an afternoon; they cannot copy the value-evidence corpus behind your weight table.

• Won’t: the incumbency trap. Seat-based incumbents are structurally reluctant to go credit-native because it dissolves their ARR reporting, their compensation plans, and their board narrative. This is a textbook “won’t” — matching your How to Win would hurt them elsewhere.

The must-have capability list:

• economic value modeling by segment

• variable-cost modeling at action granularity

• credit weight-table design and ongoing calibration

• consumption telemetry (instrument as if you were already pricing on outcomes),

• attribution infrastructure

• a go-to-market organization that can sell, defend, and adjust within the credit model rather than around it

Systems

The credit pricing system is literally an enabling management system — it builds and maintains the capabilities above rather than merely reporting on them:

• The pricing machinery. A correlation mechanism that keeps a credit worth roughly the same value however it is spent; the credit weight table; the price dial; the credit calculator buyers use to estimate consumption; the wallet that holds balances, rollover, and pooling. Connected properly, each burned credit becomes a small, auditable claim about value delivered and cost incurred. See post on the Mapper, which is where alignment between value, price and costs is designed.

• The metrics/measurement stack. Consumption-based pricing breaks the load-bearing assumptions of SaaS metrics: contracted revenue and consumed revenue diverge, churn stops being binary and becomes quiet utilization decay, and lifetime value becomes a distribution over usage scenarios rather than a point estimate. The replacement stack must track committed pool value against realized consumption, time-to-first-value, weight-table health, and value-capture ratios — tiered by audience, from board-level health metrics down to the pricing team’s weekly diagnostics. Skok’s Acquire–Retain–Monetize framework gains a fourth key — Govern — and that addition is the clearest signal that Systems has expanded in scope.

• Governance. Overage, rollover, and pooling policy; expiry rules; audit trails. Choudary’s point that power accrues to whoever manages the new constraint means governance systems are not back-office — they are where the moat is operationalized (Reshuffle).

• Organizational systems. Compensation plans that reward credit commitments and healthy consumption rather than seats; customer success triggers keyed to drawdown velocity rather than binary churn events.

Feedback loops

The upward feedback, or constraints, from lower boxes to higher ones — matter more here than in most applications, because the agent economy moves faster than annual planning. Three loops worth naming explicitly:

1. Systems → Where to Play. If outcome attribution stays weak, you cannot hold an outcome-layer position — the cascade pushes you back to the application layer with a credit bridge. Intercom’s Fin could price per resolution only because resolution was measurable; that is a Systems constraint determining Where to Play.

2. Systems → How to Win. When customers commit to credit pools but consumption runs well below commitment, the system is telling you that the How to Win promise — aligned, trustworthy consumption — is failing in practice. The diagnosis may reach all the way back up to weight-table design, packaging, or even segment choice.

3. Capabilities → Aspiration. The Cure Cancer example applies directly. A company may aspire to outcome pricing, but without attribution capability the honest aspiration is the credit-native intermediate position — which is precisely why credits are the pragmatic path to the agent economy rather than a compromise.

One closing observation: the canonical failure mode in the market right now is running the cascade bottom-up — developing metering infrastructure (Systems), relabeling usage units as “credits” (Capabilities, nominally), and never making the Where to Play and How to Win choices that give credits meaning. That is what produces the credits-in-name-only pattern now visible across the industry.

Conclusions

The strategic choice cascade does its most important work here by imposing order. Credits are the last choice you make, not the first. Almost everything that is going wrong with credit pricing in the market today traces back to running the cascade upside down — building metering infrastructure, relabeling usage units as credits, and hoping that a Winning Aspiration will emerge from the plumbing. It won’t. Systems can constrain aspirations; they cannot generate them.

Three insights are worth carrying forward.

Every pricing model is a trust model. In the agent economy this stops being a metaphor. When buyer-side agents read your pricing and value models directly, trust becomes a computable property of your commercial terms. The vendors who win will be those whose credits are the most defensible claim about value in their category — provably aligned so that Value > Price > Cost on every transaction.

Where to Play is now a position in the agent stack. Your layer — infrastructure, orchestration, application, outcome — determines which pricing architectures are even available to you. And the attribution constraint is the gate. Until you can attribute outcomes, the honest position is the application layer with credits as the bridge. How to Win is a trajectory, not a static choice.

The moat is the value-evidence corpus, not the pricing page. A competitor can copy your weight table in an afternoon. They cannot copy the segment-level value models, action-level cost models, and accumulated outcome data that calibrate it. This is a capability that compounds with use and does not depreciate as foundation models improve. Seat-based incumbents won’t follow you here — doing so would dissolve their own ARR narrative. Can’t and won’t, both working in your favor.

What to do about this? Five actions, in cascade order.

1. Write your winning aspiration without the word ‘credits’ in it. If you cannot, you have made a Systems choice masquerading as an aspiration. Start over.

2. Choose your stack layer explicitly and name the archetype you are playing. Each archetype carries a permitted pricing architecture — know which one is yours.

3. Anchor credit weights to segment-level value models, not to costs. This is the line between credit-native design and credits-in-name-only, and today it is a genuine differentiator.

4. Instrument as if you were already pricing on outcomes. The attribution evidence you accumulate at the application layer is what eventually unlocks the outcome layer.

5. Re-run the cascade on a cadence. The agent economy moves faster than annual planning, and the feedback loops — from Systems back up to Where to Play, from Capabilities back up to Aspiration — are where the real learning happens.

The companies that treat credits as a mechanism earned by strategic choices, rather than a label applied to usage meters, will own the value conversation in their categories. The rest will discover that a credit no one trusts is just a token.

TL;DR — The Mapper

What it is

• Credit based pricing has four jobs-to-do, the Mapper is a key enabler of all of these.

  • make it easy to buy

  • connect price to value

  • predict consumption for buyer and seller

  • support model adaptation over time

• The Mapper is the value-to-credit translation engine — the connector where the three Building Blocks (Agent Pricing Metrics, EVE Value Model, Cost Model) converge to assign credit weights to pricing metrics in the credit pricing system.

• The defining constraint: each credit has approximately the same economic value, whichever metric burns it — enforced as a fungibility tolerance band (default ±20%) around mean value-per-credit.

• There are four design principles:

  • The Value > Price > Cost relationship is maintained across scale and under different usage scenarios

  • Credit fungibility - credits can be used for any action (there is only one type of credit)

  • Traceability - credit pricing can be trqaced back to valeu and cost

  • Adaptability - the Mapper enables changes to the credit pricing system to keep it alsigned with change

• It is how value-based pricing gets implemented for credits

Key insights

• The Alignment Algorithm is a pipeline with six stages:

  • driver-to-metric mapping →

  • cost attachment →

  • neutral weight solve →

  • behavioral adjustments →

  • segment/scenario handling →

  • diagnostics

• Neutral baseline first, incentives second. Discounted credits and engagement credits (negative cost) are explicit, documented deviations from a neutral baseline — without that baseline, “discounts” are indistinguishable from arbitrary pricing.

• No master algorithm exists — but there is are heuristics. The invariants (inequality, fungibility, traceability, versioning) are universal; the solver algorithms are design-specific. Recommended hybrid default: EVE causal mapping (AI-assisted) → cost floors → solve for neutral weights → regression diagnostics on live burn → calendar for reweight governance.

• AI proposes, solvers verify, humans publish. AI handle the messy middle (driver→metric mapping, diagnostics narration, solver selection); numerical solvers test feasibility; publication is a controlled by humans.

• The Mapper is the module whose job is to create fungible economic meaning. The Weight Table stores it, the Price Dial monetizes it, Calculator and Wallet operationalize it, Governance constrains its evolution. Six feedback loops (margin, value, fungibility, prediction, behavior, adaptation) drive the system.

• Learning from similar systems: Snowflake’s doubling table (fungibility and legibility); IMF SDR quinquennial reviews (scheduled, transparent reweighting); airline miles (dual valuation, devaluation as the trust killer); telecom BSS (separate rating from charging from policy); carbon MRV (outcome metrics need to add up); Electricity (congestion adders under GPU scarcity). Anti-pattern: Databricks’ context-varying DBU price — keep one price per credit and express differences in weights.

Buried in the Pricing for the Agent Economy, by Michael Mansard, Wolfgang Ulaga and myself is the idea of a Mapper. The Mapper is the brains of the credit pricing system and is where value (from an EVE value model), costs (from a Cost Model) and the Pricing Metrics (the things that consume credits) get aligned.

Let’s go deep into the idea of the Mapper (this post goes into much more detail than we do in the book).

The Mapper is the connector that makes credit-based pricing a value-based system rather than a billing abstraction. Its job is to ensure that each credit has approximately the same economic value, regardless of which metric burns it, while preserving the core pricing relationship Value > Price > Cost across scale and usage scenarios.

The Mapper’s core is the Alignment Algorithm: a set of algorithms that produces neutral credit weights across heterogeneous metrics, then allows deliberate adjustments to support specific goals (discounted credits for encouraged actions; engagement credits that can be gifted). There is no universal master algorithm, at least not one that we have found. We use AI to discover and maintain the algorithm that fits a specific product design, then recalibrate as agents, costs, value models and data evolve.

What the Mapper Is

Position in the architecture

The jobs-to-be-done for a credit based pricing system:

• make it easy to buy

• connect price to value

• predict consumption for buyer and seller

• support model adaptation over time

The architecture is organised in three layers.

Building Blocks: Agent Pricing Metrics - EVE Value Model - Cost Model

Connectors: Mapper - Credit Weight Table

Managers: Price Dial - Credit Calculator / Predictor - Credit Wallet - Credit Governance Rules

The Mapper sits between the Building Blocks and the Managers. It is not metering, not billing, and not packaging. It is the value-to-credit translation engine: the place where economic value and operating cost are joined to the metrics that will consume credits.

Purpose and design principles

The Mapper’s purpose is to translate economic value into monetizable, credit-denominated pricing metrics. Four design principles are applied:

1. Alignment. For every mapped metric and target segment, the system must demonstrate Value > Price > Cost, with Cost as floor and value as estimated by the EVE model the ceiling.

2. Fungibility. A credit burned on a role, an input, an action, an output, or an outcome should represent approximately the same economic value to the seller (and, ideally, a menaingful slice of value to the buyer). Variance outside a tolerance band is a defect.

3. Traceability. Every credit weight must be traceable to specific value drivers and cost components. If “reduced support cost” is the driver, the metric should be credits per resolved conversation — not tokens per prompt.

4. Adaptability. Weights, mappings, and assumptions are versioned artifacts. Re-weighting produces a new immutable version with an explicit migration path; it does not silently mutate live contracts.

These principles extend Tom Nagle’s value-based pricing into a multi-metric, multi-agent operating system. They also match the design-choice framing in Design choices in credit based pricing: unit design is the foundation; everything downstream inherits from here.

Agent Pricing Metrics

These are the monetizable surfaces to which credit weights are assigned. The taxonomy used in the architecture is:

Role: Who/what has access (human seat, agent instance, agent role)

Capacity / Access: Reserved throughput, priority, SLA-backed access

Inputs: Data, documents, context objects submitted

Actions: Discrete operations the agent performs

Outputs: Artifacts produced (documents, decisions, records)

Outcomes: Verified business results attributable to the agent

(We are instigating a seventh surface, events, but are not ready to weave that in yet.)

Selection among these is a design decision, guided by COMPASS (Choice of Optimal Metrics for Pricing Agentic Systems & Solutions), as developed by Michael Mansard. COMPASS evaluates candidate metrics against value-metric alignment and attribution confidence. Not everything should be metered: charge for the work that matters economically and that can be tracked in the EVE value model.

EVE Value Model

Economic Value Estimation (EVE), introduced by Tom Nagle in The Strategy and Tactics of Pricing (first edition 1986 with Reed Holden; seventh edition 2023 with Georg Müller and Evert Gruyaert) is the standard way to estimate the model of B2B solutions. An EVE-style value model is a set of value drivers, each with a short description and an equation estimating impact on the customer’s P&L or balance sheet, relative to the next best competitive alternative (NBCA). For presentation purposes these can be recast as ROI (Return on Investment) or NPV (net Present Value), but for pricing work the granularity of an EVE model is required.

The six canonical value driver types are as follows:

Increase revenue: Powerful when validated; often underused (note that this is actually the gross margin, as $1 of revenue to a company with 80% margins is worth 80 cents, while a $ of revenue to a company with 20% margins is worth only 20 cents)

Reduce operating costs: Most common; over-relied upon if used alone

Reduce operating capital: Often overlooked; more important as cost of capital rises

Defer / reduce capital investment: Balance-sheet value; long-cycle buyers

Reduce risk: Growing importance in volatile environments

Increase optionality: Adaptive capacity; harder to quantify, strategically critical

The Mapper should ingest value models conforming to The Value Project open schemas (value_model.jsonschema, Apache 2.0).

Cost Model

Variable cost per priced use: tokens, API/MCP access, data use, third-party services, human-in-the-loop interventions. Sunk costs should be excluded from pricing decisions (The credit pricing system). Costs should be expressed per unit of each candidate pricing metric so they align cleanly with value drivers at the same granularity. In agentic AI, variable compute can reach a large share of delivery cost. The cost model sets the floor for pricing. More work is needed on a standard way to represent cost models for agents.

Telemetry (feedback input)

Observed credit burn by workflow, agent, metric, segment, and outcome. This is needed to keep the system aligned over time. It may require integrations with other agents and applications.

The Alignment Algorithm

The Alignment Algorithm is the Mapper’s analytical heart. Its job is alignment: ensure a credit has roughly the same value across different pricing metrics, providing a baseline for how many credits each metric consumes.

Conceptually, the algorithm solves for credit weights w_m (credits per unit of metric m) and a price-per-credit p such that:

where V_m​ / W_m is the economic value per unit of metric m, C_m is the variable cost per unit, p is the target value-capture band, v average is the mean value-per-credit across metrics, and r is the fungibility tolerance (default ±20% in the technical requirements).

Processing stages

Stage A — Driver-to-metric mapping. For each value driver: resolve its equation and variables; estimate annual (or other period, but be sure to use the same time scale for all parts of the analysis) economic value per segment (Customer Variables preferred; Improvement Claim medians as fallback; vendor-estimate basis flagged as lower confidence); identify which Agent Pricing Metrics causally correspond to the driver’s mechanism; record an auditable link: driver → EVE category → pricing metric → variable(s). Mappings are many-to-many: one driver may distribute across metrics; one metric may draw from multiple drivers. Judea Pearl’s causal graphs give clarity and structure here.

Stage B — Cost attachment. Join unit costs from the Cost Model to each metric, producing a Value/Cost pair — the basis for cost alignment checks (be careful to use the standard time period here). Note that this should only be variable costs and not sunk costs.

Stage C — Neutral weight calculation (fungibility pass). Compute proposed W_m​ such that (i) implied price per unit approximates the target capture ratio within band, (ii) price stays above cost, and (iii) value-per-credit stays within the fungibility band. Metrics outside the band are flagged for review or re-weighting.

Stage D — Behavioral adjustment pass. Once neutral weights exist, apply deliberate incentives:

Behavioural adjustments are deviations from a neutral baseline, not the baseline itself. Without a neutral reference, “discounts” are indistinguishable from arbitrary pricing.

Stage E — Segment and scenario handling. EVE models are segment and use-case specific. The Mapper runs per segment and must not collapse into a blended table unless explicitly instructed.

Stage F — Diagnostics. Calculate fungibility variance (e.g., coefficient of variation of value-per-credit), inequality violations, low-confidence mappings, and a delta view against the prior published Credit Weight Table.

Outputs

Relation to value-based framing

EVE answers: what is this worth relative to the alternative? The Mapper answers the operational sequel: how do we express that worth as a fungible unit across heterogeneous metrics, at a price that sits between value and cost, and that can be recalibrated as the product evolves?

SaaS and agent pricing should be model-driven — value models and pricing models are first-class artifacts in the system — this is what makes the Mapper more than a spreadsheet of arbitrary weights. The Value Project pushes this further: value models and pricing models as portable, computable, agent-ready JSON, so buying agents and billing systems can act on the same structure the Mapper consumes.

Credit-based pricing becomes value-based pricing when the Mapper’s alignment work is done. Otherwise credits are a cost-plus token with better marketing.

The Mapper and the Other Modules

Component roles (article taxonomy)

Using the actual module names from The credit pricing system:

How the Mapper differs

The Mapper is the component whose primary job is to create fungible economic meaning for the credit. The Weight Table stores that meaning; the Price Dial monetizes it; Calculator and Wallet operationalize it; Governance constrains its evolution.

Data flows and interfaces

Sequencing (design time)

1. Segment and use-case definition

2. EVE models and Cost Model

3. Metric catalog (COMPASS-informed)

4. Mapper run → draft Weight Table + ppp

5. Human approval → publish immutable version

6. Calculator and Wallet bind to published version

7. Governance Rules encode lifecycle and change policy

8. Packaging / GTM consume the same spine

This matches the DSM-informed order in Emerging patterns in credit based pricing design: Foundation choices (unit, trigger, period, price) before lifecycle, packaging, and GTM. The Mapper is the computational realization of Foundation × Pricing Architecture.

Sequencing (run time)

1. Buyer (or buyer agent) uses Calculator with customer variables → predicted credits

2. Purchase / allocation lands in Wallet

3. Agent work emits metered events against metrics

4. Wallet burns credits per Weight Table; Governance shapes edge cases

5. Telemetry streams to analytics and back to Mapper for drift detection

Feedback loops

Mapping components to the four jobs

Condensed from the source article’s mapping:

Implementing the Mapper

Reference architecture

Implement the Mapper as an independently deployable service with a clean API boundary — not embedded inside Calculator or Wallet (technical requirements in the Substack article).

Minimum API surface

• POST /value-models — ingest/validate TVP value model

• POST /cost-models — ingest cost model

• POST /pricing-metrics — register metric catalog

• POST /mapper/run — execute mapping; return draft table + diagnostics

• POST /mapper/simulate — sensitivity on claims, segments, capture ratio

• GET /credit-weight-tables/{version} — retrieve draft or published

• POST /credit-weight-tables/{id}/approve — promote to immutable published version

• POST /telemetry/burn — ingest observed burn for recalibration proposals

Data requirements

Even without realized-value feedback, the Mapper can still produce a theory-consistent table from EVE + cost; with feedback it becomes a learning system.

Candidate algorithms for the Correlation Algorithm

There is no single master algorithm. Below are practical families, with when to use them and failure modes.

A. Cost-based normalization

Idea: Set W_m∝C_m , pick p so margin targets hold.

Use: Cost floor and margin guardrails inside a value-led solve — never as the primary story.

B. Regression and correlation across usage metrics

Idea: From historical data, estimate relationships among metrics and between metrics and realized value/margin:

Then set W_m∝β^M_w​ (value loading), subject to cost floors.

Use: Mid-maturity products with Wallet history; detect when two metrics charge for the same underlying value.

C. Linear programming / multi-objective optimization

Idea: Solve explicitly for {W_m},p:

Decision variables: W_m > 0, p > 0, optional behavioral discounts d_m∈[0,1].

Constraints:

• Capture band: ρ_min⁡V_m ≤ wmp ≤ ρ_max⁡Vm

• Cost floor: w_mp ≥ (1+μ)C_m

• Fungibility: ∣V_m/w_m−vˉ∣ ≤ τvˉ

• Optional: total revenue / volume scenario constraints

Objectives (multi-objective or weighted sum): minimize fungibility variance; maximize expected margin under forecast mix; minimize distance from prior weights (change smoothness).

Use: Production Correlation Algorithm backbone for most B2B agent products.

D. PCA / factor analysis

Idea: Reduce collinear metering signals to latent factors; price factors rather than raw metrics; or use loadings to set relative weights.

Use: For diagnostic and metric-catalog hygiene; not a standalone approach.

E. Exchange-rate / currency-basket style

Idea: Treat metrics as “currencies” and the credit as an SDR-like basket unit. Weights reflect relative “trade” (usage volume) and “reserve” (strategic importance / value share) roles. Recalibrate on a fixed cadence (see §4.1).

Use: Large platforms with many agents and a need for predictable, political, multi-stakeholder reweighting.

F. Reinforcement learning / bandits for dynamic recalibration

Idea: Treat weight tweaks as actions; reward = margin + retention + engagement − complaint/churn proxies. Contextual bandits for behavioral discounts and engagement-credit levels.

Use: Only on the behavioral adjustment layer (engagement credits, exploration bonuses), inside guardrails set by the neutral solve. Never let an RL agent silently move the published neutral table.

G. Hybrid (recommended default)

1. EVE → value per metric (causal mapping, AI-assisted)

2. Cost floors attached

3. LP / multi-objective solve for neutral wm,pw_m, pwm​,p

4. Regression diagnostics on live burn for drift and collinearity

5. Bandit/rules for engagement credits

6. Basket-style calendar for formal reweight governance

AI / LLMs for discovering the Allignment Algorithm

The article is explicit: use AI to do this, especially as agents become more complex and workflows more variable (The credit pricing system).

Pattern: LLMs propose structure and narrative; numerical solvers own feasibility; humans own publication. This mirrors AI-assisted mapping in the technical requirements: AI suggestions visibly distinguished from approved mappings.

Pseudocode sketches

Neutral weight solve (LP-style)

function NEUTRAL_WEIGHTS(metrics M, values V[m], costs C[m],
                         rho_min, rho_max, tau, mu):
    # Choose numeraire: set mean value-per-credit target
    # Option: fix p from strategic Price Dial band, solve w
    # Option: fix w_ref = 1 for reference metric, solve others + p

    choose reference metric r with reliable V[r], C[r]
    p_lo = (1+mu) * C[r] / w_ref_candidate
    p_hi = rho_max * V[r] / w_ref_candidate
    p0   = clamp(strategic_p, p_lo, p_hi)

    for m in M:
        # credits so price captures ~ mid of band
        target_price_m = ((rho_min + rho_max)/2) * V[m]
        w[m] = target_price_m / p0
        # enforce cost floor
        w[m] = max(w[m], (1+mu) * C[m] / p0)

    v_per_credit[m] = V[m] / w[m] for m in M
    v_bar = mean(v_per_credit)

    # Iteratively rescale outliers into fungibility band
    for iter in 1..K:
        for m in M:
            if v_per_credit[m] > v_bar * (1+tau):
                w[m] = V[m] / (v_bar * (1+tau))   # more credits
            if v_per_credit[m] < v_bar * (1-tau):
                w[m] = V[m] / (v_bar * (1-tau))   # fewer credits
            w[m] = max(w[m], (1+mu) * C[m] / p0)
        recompute v_per_credit, v_bar

    flag any m still violating Value>Price>Cost or fungibility
    return w, p0, diagnostics

Behavioral adjustment layer

function APPLY_BEHAVIOR(w_neutral, policy):
    w = copy(w_neutral)
    for m in policy.discounted_actions:
        w[m] = w_neutral[m] * (1 - policy.discount[m])  # fewer credits charged
    engagement_grants = []  # not weights: credit mint events
    for rule in policy.engagement_rules:
        engagement_grants.append({
            trigger: rule.trigger,   # onboard, refer, explore
            credits: rule.amount,  # negative cost / grant
            expiry: rule.expiry,
            draw_order: "first" or "last"
        })
    # Assert: document delta vs neutral for every m
    return w, engagement_grants, delta_report

AI-assisted mapping loop

function MAP_DRIVERS(value_model, metric_catalog):
    proposals = []
    for driver in value_model.drivers:
        prompt = build_prompt(driver, metric_catalog, compass_hints)
        suggestion = LLM(prompt)  # metric_ids, weights_of_attribution, rationale
        validate suggestion against schema and causal heuristics
        proposals.append(suggestion with status=PROPOSED)
    human_review(proposals)  # approve / edit / reject
    return approved_mappings  # status=APPROVED only these enter solve

Tradeoff summary

Analogs and Lessons for the Mapper

The problem the Mapper is solving is not unique. Others have had to solve these problems and we can learn from them.

Each analog solves a version of the same problem: make heterogeneous things comparable under one unit of account, without destroying trust or economics.

IMF Special Drawing Rights (currency basket)

Problem. Create a stable international reserve asset when no single currency is neutral.

Mechanism. The SDR’s value is a weighted basket of USD, EUR, CNY, JPY, and GBP. The IMF Executive Board runs a quinquennial valuation review of composition and weights. The 2022 review kept the five-currency basket and updated weights effective August 1, 2022, with slightly higher weights for the U.S. dollar and renminbi and lower weights for the pound, euro, and yen; published weights included USD 43.38% and CNY 12.28%, with methodology tied to roles in international trade and finance (IMF SDR valuation review; IMF SDR factsheet).

Lessons for the Mapper

• Scheduled, political, transparent reweighting beats continuous silent drift.

• Separate weight formula (methodology) from weight values (this period’s numbers).

• Smooth transitions: change amounts/weights on a known effective date with transition calculations.

• Inclusion criteria (which metrics enter the “basket”) matter as much as weights.

Failure modes to avoid: opaque methodology; weights that lag structural change for too long; or the opposite — constant tinkering that destroys the unit’s meaning.

Central bank monetary policy (issuance and inflation)

Problem. Manage a unit of account so that money remains a stable claim on value while the real economy grows.

Mechanism. Inflation targeting, money-supply monitoring, and policy rates stabilize the purchasing power of the currency (IMF on monetary policy; IMF on inflation targeting).

Lessons for the Mapper

• Engagement credits are monetary issuance. Uncontrolled “free credit” printing is inflation: the same nominal credits buy less real product capacity or train buyers to expect devaluation.

• Track analogs of M1 (spendable credit balances) vs. total granted.

• Sinks and faucets (see game economies) must be designed: expiry, paid top-ups, and credit-consuming core actions are sinks; grants and bonuses are faucets.

• Price Dial increases are like nominal inflation; weight increases on actions are like relative price shifts — communicate which dial moved.

Failure modes: hyper-issuance of promotional credits; unclear expiry (money that never dies breaks revenue recognition and scarcity); sudden devaluation (repricing without notice).

Airline frequent flyer miles and loyalty currencies

Problem. One point currency redeems across heterogeneous inventory (routes, classes, partners) with different costs and values.

Mechanism. Airlines create a proprietary currency, sell miles to banks/partners at a wholesale rate, award miles for flying, and redeem against dynamic or chart-based award pricing. Co-brand banks often pay a premium to the airline’s internal valuation of a mile; loyalty programs can represent a large share of enterprise value (Airline loyalty program economics).

Lessons for the Mapper

• Dual valuation is normal: internal economic value of a credit ≠ partner/wholesale price ≠ customer-perceived value. The Mapper should track all three.

• Redemption dynamic pricing (award charts → revenue management) is the airline version of re-weighting — and a major trust flashpoint when devaluation is abrupt.

• Breakage (expiry of unused balances) is economically material — maps to credit lifecycle design.

• Opacity of redemption value is a chronic complaint: publish effective value bands where possible.

Failure modes: points devaluation; award unavailability (capacity) that makes the unit feel worthless; complex partners creating arbitrage.

Cloud credits (DynamoDB, Snowflake, Databricks, Cosmos DB)

Problem. Heterogeneous resource consumption (CPU, I/O, memory, instance types) must bill through one mental model.

SystemUnitEquivalence methodSourceAWS DynamoDBRCU / WCU (and on-demand request units)Normalize read/write capacity; provisioned vs on-demand modesAWS DynamoDB throughputSnowflakeCreditsWarehouse T-shirt sizes burn credits/hour on a doubling scale (XS=1, S=2, … 6XL=512 Gen1); per-second billing with 60s minimumSnowflake warehousesDatabricksDBUNormalized compute capacity; DBUs/hour by node type × cluster; dollar rate per DBU varies by cloud, tier, compute typeFlexera DBU guide; Databricks pricingAzure Cosmos DBRequest Unit (RU)“Performance currency” abstracting CPU, IOPS, memory; deterministic RU charge per operation; 1 RU ≈ 1 KB point readAzure Cosmos DB RUs

Lessons for the Mapper

• Determinism builds trust: Cosmos’s promise that the same operation on the same data costs the same RUs is exactly credit fungibility in engineering form.

• Two-part bills (Databricks DBU + cloud VM) warn against hiding a cost stack buyers rediscover painfully — surface cost drivers internally even if the buyer sees one credit.

• Snowflake’s legible doubling table is a masterclass in Weight Table design: simple, memorable, predictable.

• Databricks shows a subtle trap: a “unit” whose price varies by context (compute type, tier) is not fully fungible. Prefer one ppp and express differences in wmw_mwm​, matching Forth/Mansard guidance that credits should share a single price at a point in time (The credit pricing system).

• Provide a Cost Estimator / Calculator twin — every successful cloud unit has one.

Failure modes: unit sprawl (too many SKUs of “credits”); non-deterministic charges; rate cards that reintroduce the complexity the unit was meant to hide.

LLM token pricing (OpenAI, Anthropic)

Problem. Normalize billing across models, modalities, and token types (input, output, cache, reasoning).

Mechanism. Bill per million tokens with asymmetric input vs output prices; different models carry different rates; tools and modalities add line items (OpenAI API pricing). Practitioners note output tokens can cost several times input on flagship models.

Lessons for the Mapper

• Tokens are an excellent cost metric and a poor value metric for most business buyers — exactly why the Mapper must not stop at token pass-through.

• Asymmetry (input vs output) is a valid Weight Table pattern when cost and value differ by directionality (e.g., “credits per prompt token” vs “credits per generated artifact”).

• Model tiers map to metric variants (fast/cheap agent vs deep/expensive agent), not necessarily different currencies.

• Cached tokens / batch discounts are behavioral or cost-pass-through adjustments on a neutral baseline.

Failure modes: exposing raw token complexity to business buyers; margin collapse when output-heavy agents are sold at input-like effective rates.

Video game virtual economies (EVE Online, WoW-class MMO economies)

Problem. Maintain a functioning multi-good economy with player-driven prices, sinks, and faucets.

Mechanism. CCP Games hired real economists and published Quarterly Economic Newsletters with money-supply measures (ISK on accounts as M1-like), price indices (fixed basket vs chain), and faucet/sink analysis (bounties as major faucet; LP stores and other sinks). Early QENs documented tens to hundreds of trillions of ISK and explicit index construction (EVE QEN Q3 2007; EVE QEN Q3 2010).

Lessons for the Mapper

• Publish economic observability (internal QEN-style dashboards): credit supply, burn velocity, effective value-per-credit, inflation of promotional balances.

• Design sinks (core paid actions, expiry) and faucets (grants, referrals) deliberately; measure net issuance.

• Price indices of “what a credit buys” over time detect devaluation before customers revolt.

• Fixed-basket vs chain-weighted indices parallel neutral weights vs usage-mix-adjusted effective pricing.

Failure modes: gold inflation; duplex economies (RMT); patch-driven shocks without communication — all map to surprise weight changes and engagement-credit floods.

Locational marginal pricing (electricity)

Problem. One commodity (energy) has different economic value by location and time because of physics (losses, congestion).

Mechanism. LMP = energy component + congestion component + loss component; prices emerge from optimal power flow duals — the marginal cost of serving one more MW at a node given network constraints (ISO-NE LMP FAQ).

Lessons for the Mapper

• When capacity is constrained (GPU scarcity, priority queues), a single fungible credit may need a congestion adder — or a separate capacity metric — rather than pretending all burns are equal.

• Transparent decomposition (base energy vs congestion) is a model for showing buyers: base action cost vs peak/priority premium.

• Optimization duals are a rigorous way to derive “marginal credit cost” under constraints — advanced Correlation Algorithm territory.

Failure modes: uniform pricing under constraint creates shortages and shadow markets; opaque congestion charges create political backlash.

Telecom rating engines and interconnect settlement

Problem. Bill complex, real-time, multi-party usage (voice, data, roaming) with correct rates, bundles, and settlements.

Mechanism. BSS/OSS rating and charging systems (including 3GPP convergent charging) mediate chargeable events through rating engines: event → normalized chargeable units → price from tariff tables → balance management — often in real time (3GPP charging specs ecosystem; industry CCS platforms).

Lessons for the Mapper

• Separate rating (Weight Table × Price Dial) from charging/balance (Wallet) from policy (Governance) — telecom already learned this modularity.

• Chargeable event design = consumption trigger design (initiate vs success vs outcome).

• Interconnect settlement ≈ multi-agent / multi-vendor credit exchange — relevant as MCP and agent-to-agent commerce grow (TVP roadmap territory).

• Real-time balance and online charging are table stakes for agentic spend.

Failure modes: mediation errors; late-arriving events; tariff explosion; bill shock — the classic credit-model trust killers.

Carbon credit markets

Problem. Make heterogeneous reduction/removal projects comparable as “one ton CO₂e.”

Mechanism. Protocols define additionality (how credits add together), permanence, measurement, reporting, verification (MRV); quality varies; integrity initiatives tighten baselines (ICVCM / additionality literature).

Lessons for the Mapper

• Outcome metrics need additionality logic: would the business result have happened anyway?

• Verification lag means outcome-triggered credits need escrow, partial charge, or success-fee overlays.

• Quality tiers (high-integrity vs weak credits) warn against treating all “outcome credits” as equal without measurement standards.

• Over-crediting scandals = over-claiming value drivers in EVE models.

Failure modes: junk credits; double counting; permanence reversal — map to double monetization of the same value path and clawback policy design.

Index construction and basket weighting (finance)

Problem. Aggregate heterogeneous securities into one index level.

Mechanism. Price-weighted, equal-weighted, market-cap-weighted, free-float-adjusted, fundamental-weighted schemes — each with different rebalancing needs and factor tilts (CFA-style index weighting methods).

Lessons for the Mapper

• Rebalance cadence and turnover cost (customer change management) are first-class design variables.

• Cap-weighting popular metrics can underprice emerging high-value agents — a strategic error.

Mechanism design and token engineering (crypto)

Problem. Design endogenous supply, demand, and incentive systems for tokens.

Mechanism. Bonding curves and automated market makers link price to supply; parameter choices (curve shape, reserve ratios, fees) encode policy (bonding curve design parameters).

Lessons for the Mapper

• Bonding curves are a formalization of dynamic Price Dial behavior under scarcity or volume — use sparingly in B2B where buyers want predictability.

• Mechanism design forces explicit statement of incentive compatibility: will buyers and seller agents game weights?

• On-chain transparency culture is a useful aspiration for Weight Table publication.

• Most crypto failures are governance and incentive failures — not smart-contract syntax.

Failure modes: death spirals; reflexive inflation; governance capture — map to uncontrolled engagement issuance and stakeholder-driven arbitrary reweights.

Cross-analog synthesis

Implications

The Mapper as strategy, not plumbing

Forth and Mansard’s core claim is that credits are how Value > Price > Cost is expressed at scale (The credit pricing system). The Mapper is where that claim is either redeemed or falsified. Teams that treat credit weights as a finance spreadsheet exercise will reproduce cost-plus pricing with extra steps. Teams that treat the Mapper as product strategy — metric selection, value models, fungibility, incentive design, versioned change — will own the operating system of the agent economy.

Two dials, one conscience

Emerging-patterns writing describes two dials: credits per action, and price per credit (Emerging patterns). The Mapper owns the first dial’s conscience (and proposes the second). Moving dials without saying which one moved is how trust dies. Publish a neutral baseline; label behavioral deviations; version everything.

AI discovers the algorithm; humans own the constitution

There will not be one Correlation Algorithm for every credit system. There will be a constitutional framework (inequality, fungibility, traceability, versioning) and a family of solvers chosen per design. LLMs are uniquely suited to the messy middle — causal mapping from value narrative to metrics — provided publication remains a human constitutional act.

Open research questions

• Optimal fungibility tolerance τ by category (horizontal platform vs vertical agent)?

• When should outcome metrics enter the neutral basket vs sit as success-fee overlays?

• Formal settlement protocols for multi-vendor agent credit exchange (TVP v3–v4 direction)?

• Regulatory and revenue-recognition constraints on engagement-credit issuance and expiry?

Conclusion

The Mapper is the alignment engine of credit-based pricing. It takes Nagle’s Economic Value Estimation, Ibbaka’s operational value-modeling discipline, and the brutal cost reality of agentic AI, and produces a fungible unit of account — the credit — whose weights and price keep Value > Price > Cost true across metrics, segments, and time.

Its Correlation Algorithm is not a single closed-form law of nature. It is a governed optimization-and-learning system: causal mapping from drivers to metrics, neutral weights under fungibility and margin constraints, behavioral adjustments as explicit deviations, and continuous recalibration from Wallet telemetry. Cloud RUs and Snowflake credits teach determinism and legibility; SDRs and index committees teach scheduled transparent reweighting; airlines and games teach the dangers of issuance and devaluation; telecom teaches modular rating; carbon markets teach outcome integrity; LMP teaches scarcity; token engineering teaches incentive compatibility.

Build the Mapper as a versioned, auditable, AI-assisted service with a human constitution. Treat the Credit Weight Table as a published economic artifact, not a hidden tariff. Do that, and credits stop being a billing gimmick and become what the architecture claims they are: the operating fabric of value-based pricing in the agent economy.

TL:DR

• A credit-based pricing system has four non‑negotiable jobs: make it easy to buy, connect price to value, predict consumption for buyer and seller, and support model adaptation over time.

• Credits are the unit in which you express the core Pricing relationship
  Value > Price > Cost
  at scale; each burned credit should correspond to a slice of economic value and a slice of operating cost.

• The architecture rests on three foundational models—Agent Pricing Metrics, EVE value models, and Cost Models—connected by a Mapper that ties value drivers and costs to the metrics you actually charge for.

• The Credit Weight Table, Price Dial, Credit Calculator / Predictor, Credit Wallet, and Governance Rules together make credit burn legible, unit economics predictable, and buying psychologically safe.

• The mapping table shows that every component in the stack plays multiple roles: metrics and Mapper drive value connection and adaptation; the weight table and calculator drive prediction; the wallet and governance drive ease of buying and trust.

• For product and pricing teams, the key shift is to treat the entire credit stack as an integrated system, not a collection of billing features, with telemetry from the wallet and calculator feeding continuous refactoring of metrics, weights, and rules.

• In the next 90 days, you can: map your current pricing against the four jobs, build a first‑pass Mapper and Credit Weight Table, stand up a simple calculator and wallet, and design governance and metrics as versioned artefacts that anticipate agent evolution.

• Strategically, the winners in the agent economy will be the teams that make their credit architecture a core part of product design and positioning, and who share patterns and experiments before today’s designs ossify into tomorrow’s legacy.

Learn more about the Pricing for the Agent Economy book that Steven Forth and Michael Mansard are writing. This approach is used in the book.

The requirements for an effective credit-based pricing system are coming into focus. Michael Mansard and I discuss this in some detail in our forthcoming book Pricing for the Agent Economy, which we hope to have published in October this year with the support of INSEAD. We would like to spark a wider conversation about this framing, so we are sharing some of our current thinking here. Over time, this may evolve into a reference architecture for credit-based pricing, in the same way that subscription pricing converged on a recognizable pattern of seats, tiers, and add‑ons.

A credit-based pricing system has four jobs.

• Make it easy for the buyer to buy

• Connect price to value

• Predict credit consumption for buyer and seller

• Support pricing model adaptation

If it fails at any of these, the system will either confuse buyers, destroy margin, or trap you in a model that cannot evolve with your product and your agents.

We are assuming here that under the hood there is a map from credit consumption to costs, which can include token consumption, access to other agents through MCP and APIs, data usage, and other variable elements of your cost stack. It is important to track costs, and to make sure that prices are high enough to meet your costs, but also anchored to the economic value the agent creates in the specific use cases you are targeting. Pricing is not a number; it is a claim about value.

Building Blocks

Agent pricing metrics

These are the things to which credit weights are assigned. They are the roles, access and capacity, inputs, actions, outputs, and outcomes that you are monetising. Selecting these is a key step in pricing and monetisation design. In most cases, you do not want to charge for everything that a user or agent does: you charge for the work that matters economically, not for every token turned over. See the Agent Pricing Metric Taxonomy and the COMPASS framework for more systematic guidance.

EVE value model

This is the Economic Value Estimation (EVE) model for the solution you are pricing. It quantifies the economic impact of your agent relative to the next‑best alternative for a specific segment, use case, and customer profile. In practice, this means building segment-level value models and, increasingly, using AI agents such as valueIQ’s Value Sales to co‑create those models with buyers.

Cost model

This is the estimated cost for each of the priced uses of the agent plus the other relevant variable costs. Costs can include token use, API and MCP access, data use, third‑party services, and human‑in‑the‑loop interventions; do not include sunk costs in pricing decisions. The cost model provides the lower bound in the core pricing inequality: Value > Price > Cost.

Connectors

Mapper

This is where value-based pricing and credit-based pricing connect. Value drivers and the variables in the value driver equations get mapped to the pricing metrics. This mapping is not a one‑time spreadsheet exercise; it is a design task that needs iteration and telemetry. You will want to use AI to do this, especially as agents become more complex and workflows more variable. The six types of economic value driver in a standard EVE model are:

• Increase revenue (at the margin, not just top-line)

• Reduce costs

• Reduce operating capital

• Defer capital investment

• Reduce risk

• Increase optionality

Given the variable costs of operating agents, it makes sense to map costs to value and then to pricing metrics, so that the metrics you charge for scale with both value delivered and cost incurred. The Mapper should make sure that the core relationship in pricing is satisfied: Value > Price > Cost, and that each credit has approximately the same economic value, regardless of which metric burns it.

Credit weight table

This is the output of the Mapper and is used by the Credit Calculator and the Credit Wallet. It is basically a table setting out how many credits are consumed for each pricing metric: per role, per action, per output, per outcome, and so on. Designing this table is where fairness, transparency, and margin all collide; your weights should feel legible to buyers while still protecting you from the 100x variance in agent task complexity.

Managers

Price dial

This is where the price per credit is set. In most cases, all credits should have the same price at any given time; buyers are purchasing a fungible unit of future utility. One can also add an algorithm that adjusts the price per credit based on volume or scarcity—price per credit could go down as the volume of credits purchased goes up, or in a situation of compute scarcity the price per credit could actually go up with volume, reflecting capacity constraints. The price dial is the bridge between the value model, the cost model, and your strategic positioning.

Credit calculator / predictor

This is a tool that helps buyers estimate how many credits they may need for a period. Basically, estimates are needed for all the pricing metrics, translated into expected credit burn over a month, quarter, or project. The total cost for the period is also calculated so buyers can compare scenarios and avoid commitment anxiety. Advanced versions of the Credit Calculator include predictions: based on customer variables, use cases, data from similar customers, and observed drawdown velocity, the calculator predicts how many credits are needed under different scenarios.

Credit wallet

This is where credit consumption is managed. It is critical that credit consumption be transparent and that it is easy for a user (or an agent acting on their behalf) to see how credits have been used: by workflow, by agent, by outcome. Additional credits—top‑ups, upgrades, renewals, expansion—are all handled through the Credit Wallet. The Governance Rules are enforced by the Credit Wallet so that behaviours like pooling, rollover, and overages follow predictable patterns.

Governance rules

This is where rules about overages, rollovers, pooling, transfers, expiry, and credit sharing are defined. These rules are then enforced in the calculator and the wallet, and increasingly by buyer‑side agents who are managing spend across multiple vendors. Governance lives at the intersection of economics and trust; opaque rules are a trust toxin, transparent rules are a competitive advantage.

Mapping the architecture to the four goals

Now, let’s make the mapping explicit. Each of the four jobs of a credit system is supported by a specific subset of components, with some doing double duty.

Make it easy for the buyer to buy

The core components here are the Credit Calculator, Credit Wallet, Governance Rules, and the Price Dial.

• The Credit Calculator turns a complex set of metrics into a simple buying decision: “For these workflows, this segment, and this time horizon, you probably need N credits, at a total spend of X.” That reduces commitment anxiety and preserves the psychological safety buyers liked about subscriptions.

• The Credit Wallet decouples acquisition from consumption: buyers pre‑commit to a block of credits and then let human users or agents spend them without renegotiating price at every action. This is the arcade‑token effect, implemented for AI.

• Governance Rules define what happens when reality differs from plan—overages, rollovers, pooling, expiry—so buyers do not feel trapped or punished by edge cases.

• The Price Dial keeps the unit price legible: one clear price per credit at any point in time, rather than a thicket of micro‑fees.

Put differently: ease of buying is a behaviour outcome engineered by the Calculator (forecast), the Wallet (pre‑commitment), the Governance layer (safety rails), and a clean price dial (clarity).

Connect price to value

The heavy lifters here are the EVE Value Model, Agent Pricing Metrics, Mapper, Credit Weight Table, and again the Price Dial.

• The EVE Value Model defines the economic ceiling—the value created across revenue, cost, capital, risk, and optionality—at the segment and use‑case level.

• Agent Pricing Metrics decide where to attach price: role, access, input, action, output, outcome, or some hybrid. This is where COMPASS and the metric taxonomy come in.

• The Mapper translates value drivers into those metrics and ensures that what you charge for is causally connected to how value shows up for the buyer. If “reduced support cost” is a value driver, it should show up as credits per resolved conversation, not tokens per prompt.

• The Credit Weight Table embodies this mapping numerically: how many credits burn per action, per outcome, per role. Done well, each burned credit corresponds to a slice of value and a slice of cost.

• The Price Dial then sets the monetary value of a credit so that, on average, Price sits safely between Value and Cost for target segments.

In practice, “connecting price to value” means that when a buyer looks at a workflow—say, 10,000 resolved support cases—they can connect that workload to expected credit burn, then to expected spend, and then to an EVE model that says “this is still comfortably net‑positive.”

Predict credit consumption for buyer and seller

Prediction is a system property arising from the Credit Calculator / Predictor, Credit Weight Table, Agent Pricing Metrics, Cost Model, and Governance Rules.

• The Credit Weight Table defines the unit economics of each metric: how many credits for a given action or outcome. Without this, prediction is hand‑waving.

• Agent Pricing Metrics provide the behavioural inputs: number of tickets, documents, leads, workflows, etc., per period. Once you can estimate volumes by metric, you can estimate credits.

• The Credit Calculator / Predictor takes customer variables, historical usage, segment benchmarks, and planned workflows, and produces scenarios: conservative, expected, aggressive.

• The Cost Model turns predicted credit burn into predicted vendor margin and capacity load, which is critical for planning infrastructure and avoiding surprise losses.

• Governance Rules shape the tails of the distribution: how overages, rollovers, and caps behave under unexpected spikes or drops in usage.

For buyers, the goal is simple: they should know their likely spend envelope and have early warning if drawdown velocity is deviating from plan. For sellers, the same telemetry becomes a margin and capacity planning tool.

Support pricing model adaptation

Adaptation is delivered by the Mapper, Agent Pricing Metrics, Credit Weight Table, Governance Rules, and the Price Dial, all instrumented by usage data flowing through the Credit Wallet and Calculator.

• As agents evolve—from simple copilots to multi‑agent workflows to outcome‑layer services—the right pricing metric can and should change. The Agent Pricing Metrics and Mapper together are your “metric refactoring” engine.

• The Credit Weight Table can be re‑weighted over time as you learn where value concentrates and where costs spike, allowing you to rebalance the economics without throwing away the whole architecture.

• Governance Rules provide structured paths for change: how and when credit weights, expiry rules, or pooling rules can be altered without breaking trust with existing customers.

• The Price Dial lets you respond to macro factors—compute scarcity, competitive pressure, changes in customer willingness to pay—without touching the metric architecture itself.

• The Credit Wallet and Calculator supply the telemetry: credit burn by workflow, segment, and outcome, which tells you where your assumptions are wrong and where the model wants to evolve.

Adaptation is the difference between a credit system that survives one product cycle and one that becomes a platform. You design not just for the current shape of your agents, but for the agents and attribution infrastructure you expect to have three years from now.

Mapping table

To make the mapping fully explicit, here’s the architecture laid against the four jobs:

Conclusion

A well‑designed credit system is no longer a nice‑to‑have; it is becoming the operating fabric of the agent economy, and the teams who treat it as core product design—not billing plumbing—will set the terms of competition.

The core insight is that credits are not arbitrary tokens; they are the unit in which you express the Pricing Inequality Value>Price>Cost\text{Value} > \text{Price} > \text{Cost}Value>Price>Cost at scale. When you align Agent Pricing Metrics, the EVE value model, and the Cost Model through the Mapper, each burned credit becomes a small, auditable claim about value delivered and cost incurred.

Because of that, your credit architecture is a strategy choice, not a spreadsheet choice: it determines how you talk about value, how you manage margin, and how quickly you can adapt as agents, workflows, and infrastructure change.

What this changes for product and pricing teams

For product and pricing teams, the implication is straightforward and demanding: you need to design and operate the credit stack—Metrics, Mapper, Credit Weight Table, Price Dial, Calculator, Wallet, and Governance Rules—as a coherent system, not as disconnected features.

That means:

• Treat Agent Pricing Metrics as part of product definition, with a clear view of which behaviours and outcomes you want to monetise and which you deliberately leave “off‑meter.”

• Use the EVE model and Cost Model as live instruments, not static decks, feeding telemetry into the Mapper so that credit weights and unit prices stay anchored to segment‑level economics.

• Instrument the Credit Wallet and Calculator so that prediction, governance, and adaptation are based on observed burn by workflow, agent, and outcome—not on quarterly guesswork.

Actions to take now

If you are building or scaling agent‑based products, there are concrete steps you can take in the next 90 days.

1. Map your current pricing to the four jobs

   • Ask, for each component you have today (metrics, packages, dials, calculators, wallets, governance), which of the four jobs it supports and where you are flying blind: ease of buying, price–value connection, consumption prediction, adaptation.

   • Use the mapping table at the end of this post as a diagnostic: where do you already have structure, and where is your architecture implicit or missing?

2. Build a first‑pass Mapper and Credit Weight Table

   • Start from your EVE models and value drivers, and explicitly link them to 3–5 Agent Pricing Metrics that matter economically in your top use cases.

   • Design and test a draft Credit Weight Table that makes burn legible to buyers, protects you from 100× variance in task complexity, and can be re‑weighted without breaking existing contracts.

3. Stand up a simple Credit Calculator and Wallet

   • Give buyers a way to translate planned workflows into expected credit burn and total spend over a chosen horizon, with at least conservative and expected scenarios.

   • Implement a basic Credit Wallet with transparent Governance Rules for overages, rollovers, pooling, and expiry, so that you can decouple acquisition from consumption without eroding trust.

4. Design for adaptation from day one

   • Treat metric choice, credit weights, and governance as versioned artefacts with explicit rules for change; your agents will not look the same in 12–36 months.

   • Use telemetry from the Wallet and Calculator to identify where value concentrates, where costs spike, and where your current architecture needs refactoring.

Invitation

The agent economy will converge on a recognizable pattern for credit‑based pricing, just as SaaS converged on seats, tiers, and add‑ons—but that pattern is not yet fixed, and the most interesting work is happening now.

Our goal in sharing this architecture is to create a shared language that founders, pricing leaders, product teams, and buyers can use to debate and refine credit systems before they ossify into legacy. If you are experimenting with credits—whether at the workflow, outcome, or multi‑agent level—I would encourage you to:

• Stress‑test your design against the four jobs, not just against short‑term revenue.

• Share your own Mapper patterns, governance innovations, and credit calculators so that we can collectively discover what works and what fails in practice.

First Pass at Technical Requirements for The Mapper

The Mapper is in a sense the brains of the system where the hard work of aligning Value, Price and Cost is analysed to set credit weights and the price per credit so that the relationship Value > Price > Cost is maintained across different scales and usage scenarios.

Component of the Credit Pricing System — Value-to-Credit Translation Engine

1. Purpose and Scope

The Mapper is the connector component of the Credit Pricing System that translates economic value into monetizable, credit-denominated pricing metrics. It sits between three upstream systems of record — the EVE (Economic Value Estimation) value model, the Cost Model, and the catalog of Agent Pricing Metrics — and produces two downstream artifacts consumed by the Credit Calculator and Credit Wallet: the Credit Weight Table and the Price Dial’s price-per-credit setting.

This document specifies requirements for building the Mapper as a standalone, vibe-coding-ready application (target stacks: Claude Code, Replit, or Lovable). It assumes familiarity with Tom Nagle’s value-based pricing framework, Steven Forth and Michael Mansard’s extensions to B2B SaaS and AI agents, the COMPASS pricing-metric framework, and The Value Project (TVP) open JSON schemas for value models and pricing models.

The Mapper is explicitly framed by its source specification as an iterative design task with telemetry feedback loops, not a one-time spreadsheet exercise, and AI assistance is expected to be embedded directly into the workflow rather than bolted on afterward.

2. Design Principles

The Mapper must be built around four non-negotiable constraints drawn directly from the source specification:

• Pricing inequality preservation. For every mapped metric and every target customer segment, the system must be able to demonstrate Value > Price > Cost, with Cost as the computed floor and Value (from the EVE model) as the ceiling.

• Credit fungibility. Regardless of which pricing metric (role, capacity, input, action, output, or outcome) consumes a credit, that credit should represent approximately the same economic value to the seller. The Mapper must surface variance across metrics and flag outliers.

• Causal traceability. Every credit weight must be traceable back to a specific value driver and cost component, not assigned arbitrarily. If “reduced support cost” is the value driver, the corresponding metric should be “credits per resolved conversation,” not “tokens per prompt”.

• Versioned adaptability. Credit weights, mappings, and the underlying assumptions must be versioned artifacts that can be re-weighted as agents, workflows, and cost structures evolve, without breaking existing customer contracts.

3. Inputs

3.1 Value Model (TVP value_model schema)

The Mapper must ingest a JSON document conforming to The Value Project’s value_model.jsonschema (Apache 2.0 licensed, v1.0). Based on the reference implementation pattern, the value model contains:

The Mapper must treat the six EVE value-driver types as the canonical taxonomy for driver classification: Increase Revenue (at the margin), Reduce Costs, Reduce Operating Capital, Defer Capital Investment, Reduce Risk, and Increase Optionality. Every valuedriver.category/subcategory in an ingested TVP value model must be normalized to one of these six types during import.

3.2 Cost Model

A structured cost model enumerating the variable cost of each priced use of the agent: token consumption, third-party API/MCP access, data usage, third-party services, and human-in-the-loop interventions. Sunk costs must be explicitly excluded from any pricing calculation per the source specification. The cost model provides the lower bound of the pricing inequality and should be expressed per unit of each candidate pricing metric (e.g., cost per action, cost per output, cost per role-seat-month) so it can be joined against value drivers at the same granularity.

3.3 Agent Pricing Metrics (the six monetizable surfaces)

A finite list of pricing metrics representing the things to which credit weights will be assigned:

1. Role(s) — who or what is granted access (human seat, agent instance, or agent role)

2. Capacity Guarantee — reserved throughput, priority tasking, or SLA-backed access

3. Inputs — data, documents, or context objects submitted to the agent

4. Actions on Inputs — discrete operations the agent performs

5. Outputs — artifacts produced (documents, images, decisions, records)

6. Outcomes — verified business results attributable to the agent’s work

Selection of which of these to meter is itself a design decision governed by the COMPASS framework, which evaluates candidate metrics against value-metric alignment and confidence of attribution. The Mapper should surface COMPASS-style guidance (e.g., attribution confidence, gym-membership-paradox risk where per-unit pricing penalizes efficient usage) as advisory signals rather than hard constraints.

3.4 Target Value Capture Ratio

A range, expressed as a percentage, representing Price to Customer divided by Estimated Economic Value. The standard range runs from 2% to 20%, with the specific target set by commercial strategy, pricing power, and customer willingness to pay. This range functions as a governance constraint the Mapper must respect when proposing a price per credit.

4. Core Processing Logic

4.1 Driver-to-Metric Mapping Engine

For each valuedriver in the ingested value model, the Mapper must:

1. Resolve the driver’s equation and variablesused to compute an estimated annual economic value per customer segment, using Customer Variables where available and falling back to Improvement Claim Benchmark medians otherwise, flagging any use of vendorestimate-basis claims as lower-confidence.

2. Identify which of the six Agent Pricing Metrics causally correspond to the mechanism described in the driver (e.g., a “Reduce GIS Specialist Labor Cost” driver tied to annualgisorderinghours naturally maps to an Actions or Outputs metric counting completed tasking orders, not a flat per-seat Role charge).

3. Record the mapping as an explicit, human-readable link: driver → EVE category → pricing metric → variable(s) consumed, so the relationship can be audited and explained to buyers, not just computed.

4. Allow many-to-many mappings: a single value driver may distribute value across multiple pricing metrics (e.g., an SLA-risk-reduction driver may partly justify a Capacity Guarantee charge and partly an Outcome charge), and a single pricing metric may draw value from multiple drivers.

4.2 Cost Attachment

For each pricing metric, the Mapper must attach the corresponding unit cost from the Cost Model, producing a per-metric Value/Cost pair. This is the basis for the pricing inequality check.

4.3 Credit Weight Calculation

The Mapper computes a proposed credit weight for each pricing metric such that:

• The ratio of (credits consumed × price per credit) to estimated per-unit value approximates the target Value Capture Ratio, within the specified 2%–20% range.

• The implied price per unit of each metric remains above the per-unit cost floor (Price > Cost).

• Across all metrics, the effective economic value delivered per credit is held within a configurable tolerance band (default ±20%, adjustable) to preserve credit fungibility. Metrics whose implied value-per-credit falls outside the band must be flagged for manual review or re-weighting.

4.4 Scenario and Segment Handling

Because EVE value models are segment- and use-case-specific, the Mapper must support running the full mapping pipeline independently per customer segment (as defined by customercriteria and Customer Variables) and must NOT collapse segments into a single blended credit weight table unless explicitly instructed. Segment-level Credit Weight Tables may later be reconciled into a single published table, but the underlying per-segment economics must remain inspectable.

4.5 Sensitivity and Confidence Propagation

Because Improvement Claim values are given as min/median/max with a basis field, the Mapper must propagate this range through to the credit weight output, producing conservative, expected, and aggressive credit-weight scenarios rather than a single point estimate. This mirrors the three-scenario pattern already expected of the Credit Calculator/Predictor downstream.

5. Outputs

5.1 Credit Weight Table

The primary output, structured as records of:

This table is the artifact consumed directly by the Credit Calculator/Predictor and the Credit Wallet.

5.2 Price per Credit

A single scalar (or a small set of scenario-based scalars) denominated in a stated currency (ISO 4217, consistent with TVP pricing-model conventions), computed so that, in aggregate across the metric mix, the resulting Value Capture Ratio falls within the target range and Price sits between Value and Cost.

5.3 Diagnostic Report

The Mapper should emit a diagnostic report per run including: fungibility variance across metrics, any metric that violates Value > Price > Cost, any metric relying solely on vendorestimate-basis claims, and a delta view against the previous published Credit Weight Table version for change management.

6. Architecture Requirements

6.1 System Context

The Mapper is a Connector in the Credit Pricing System reference architecture, sitting between the Building Blocks (Agent Pricing Metrics, EVE Value Model, Cost Model) and the Managers (Price Dial, Credit Calculator, Credit Wallet, Governance Rules). It should be implemented as an independently deployable service/module with a clean API boundary, not embedded inside the Calculator or Wallet.

6.2 Suggested Technical Stack

• Backend: Node.js or Python service exposing a REST/JSON API; JSON Schema validation library (e.g., ajv for Node, jsonschema/pydantic for Python) to validate all inbound Value Model, Cost Model, and Pricing Metric payloads against the TVP schemas.

• Equation evaluation: A small, sandboxed expression evaluator to execute the equation strings found in valuedrivers (e.g., pfailedcollectstandard * costperfailedmission * redfastviewmissrate) against resolved variable values. Do not use unsandboxed eval.

• Data store: Document store (Postgres with JSONB, or MongoDB) to persist versioned Value Models, Cost Models, and generated Credit Weight Tables, with full version history.

• AI-assisted mapping layer: An LLM-backed reasoning module (callable via API) that proposes driver-to-metric mappings, flags weak causal links, and drafts human-readable rationale text for each mapping — reflecting the source guidance to “use AI to do this, especially as agents become more complex and workflows more variable”. All AI-proposed mappings must be surfaced as suggestions requiring human approval before being committed to a published Credit Weight Table version.

• Frontend: A review/approval UI (React/Next.js is suitable for Lovable/Replit-style generation) showing the driver→metric→credit-weight chain per segment, with inline editing of proposed weights and visualization of the fungibility band and Value Capture Ratio gauge.

6.3 API Surface (minimum viable)

• POST /value-models — ingest/validate a TVP-conformant value model

• POST /cost-models — ingest a cost model

• POST /pricing-metrics — register the catalog of metrics to be priced

• POST /mapper/run — execute mapping given a value model, cost model, metric catalog, and target Value Capture Ratio range; returns proposed Credit Weight Table + diagnostics

• GET /credit-weight-tables/{version} — retrieve a published or draft table

• POST /credit-weight-tables/{id}/approve — promote a draft to published, versioned and immutable

• POST /mapper/simulate — re-run with adjusted Improvement Claim values or segment filters for sensitivity testing

6.4 Non-Functional Requirements

• Auditability: Every credit weight must retain a full provenance chain back to source variables and their basis (vendorestimate vs. customerdata, etc.).

• Telemetry ingestion: The Mapper must accept observed usage/burn telemetry (from the Credit Wallet and Calculator) as feedback input for re-weighting proposals, since the mapping is explicitly designed to be iterative rather than static.

• Versioning and non-breaking change: Credit Weight Table versions must be immutable once published; re-weighting produces a new version with an explicit migration/governance path, consistent with the Governance Rules component’s role in structured change.

• Multi-segment concurrency: Must support running and storing mappings for multiple concurrent customer segments and product tiers without cross-contamination.

• Currency and localization: Follow TVP pricing-model conventions for currency declaration (ISO 4217) on all price and value outputs.

7. Acceptance Criteria

1. Given a valid TVP value model, cost model, and metric catalog, the Mapper produces a Credit Weight Table where every row satisfies Value > Price(implied) > Cost for its segment, or is explicitly flagged as a violation.

2. The Mapper computes and displays the resulting Value Capture Ratio, verifying it falls within the user-specified 2%–20% target range (or explicitly warns if it does not).

3. The Mapper reports the coefficient of variation of implied-value-per-credit across all metrics in the table and flags any metric exceeding the configured fungibility tolerance.

4. Every credit weight in the output table can be traced, via API or UI, back to the specific value driver(s), variable(s), and cost component(s) that produced it.

5. Re-running the Mapper with updated Customer Variables or Improvement Claim values produces a new, distinctly versioned Credit Weight Table without mutating the prior version.

6. AI-proposed mappings are visibly distinguished from human-approved mappings in both the API response and the UI, and cannot be published without explicit approval.

7. The system correctly rejects (with validation errors) any Value Model or Cost Model payload that does not conform to the expected JSON Schema structure.

8. Out of Scope (v1)

Consistent with The Value Project’s own roadmap, which places credit-based pricing formalization at v3.0 and an agent-to-agent transaction API at v4.0, this Mapper specification does not require: a fully standardized TVP credit-pricing schema (none is yet published), autonomous agent-to-agent negotiation of credit weights, or direct integration with billing/invoicing systems. The Mapper’s job ends at producing the Credit Weight Table and price-per-credit for consumption by the Calculator and Wallet.

(Except from Pricing for the Agent Economy
Chapter 5: How to Define Value in an Agentic World)

The EVE value modelling approach is not just about positive value drivers. It also takes negative value drivers into account. Traditional SaaS had negative differentiators that were well understood: switching costs, integration friction, performance gaps versus the incumbent, training requirements, vendor lock-in risk. Procurement teams understood all of these. They knew how to weight them.

The AI risk premium is new. Enterprises are not buying software that waits for a human to click a button. They are buying systems that act — retrieve information, update records, send communications, make decisions — without a human reviewing each step. That is a fundamentally different risk profile from anything that came before in enterprise software. You could call this the ‘autonomy risk.’

The autonomy risk discount is the implicit cost buyers assign to this. It’s not always made explicit in procurement conversations — buyers aren’t usually sophisticated enough about AI to articulate it cleanly — but it shows up in the behaviors that slow down or kill AI agent deals:

• Demands for extensive pilot periods before commitment

• Requests for detailed audit logs and explainability documentation

• Escalation to legal, compliance, and risk teams who weren’t involved in evaluating conventional SaaS

• Price negotiation anchored on risk rather than value

• Governance requirements that didn’t exist in the software procurement checklist

The autonomy risk premium is not irrational. Enterprises are right to price in the risk of delegating consequential decisions to systems they don’t fully understand. Your job, as a vendor, is to reduce that premium — not by dismissing the risk, but by investing in the governance infrastructure that genuinely mitigates it.

Four governance investments reduce the autonomy risk premium:

Audit trails. An agent that produces a complete, queryable record of every action it took — what it accessed, what it decided, what it changed, and when — is fundamentally less risky than one that doesn’t. The enterprise can review what happened. They can catch errors. They can demonstrate to regulators that they have control over the system. Audit trail quality is a pricing variable.

Scoped credentials. An agent with minimum necessary access — reads only what it needs to read, writes only where it needs to write, cannot access systems outside its defined scope — is less risky than one with broad credentials. Credential scoping is not just a security practice. It is a trust practice, and trust is a pricing lever.

Human-in-the-loop checkpoints. For consequential decisions — anything with significant financial, legal, or reputational stakes — an agent that pauses for human review before executing is worth more to a risk-conscious enterprise than one that barrels ahead autonomously. The HITL checkpoint is a governance feature that reduces the autonomy risk premium and commands a price premium of its own.

Rollback capability. If the agent made a mistake, can you undo it? An agent with rollback capability — the ability to reverse an action and return the system to its prior state — is materially less risky than one without. This is the fire extinguisher of agent governance. The presence of the extinguisher doesn’t mean fires are expected; it means the risk of fire is being managed responsibly.

Here’s the strategic logic in EVE terms: every dollar you invest in governance infrastructure reduces the autonomy risk premium by some multiple. If your governance investment reduces the buyer’s perceived risk by $50,000/year, and your governance infrastructure costs $10,000/year to build and maintain, you’ve created $40,000 in net differentiation value — and you can price to capture a share of it. Governance is not overhead. It is a value driver.

The companies that understand this in 2026 are building governance as a first-class capability, not bolting it on after the product is built. The enterprises that are buying AI agents right now — the early adopters who are genuinely deploying at scale — are buying trust as much as they’re buying capability. A legal agent without audit trails is not a product. It’s a liability.

Michael and I did not set out simply to write another book on pricing. We set out to write a book that reflects how we believe pricing for the agent economy should be practised.

From the beginning of Pricing for the Agent Economy, we made a conscious decision: the way we write the book should embody the same principles we argue for within it. In other words, the medium should reinforce the message. If we advocate for better systems of value exchange, then the book itself should be an example of this in action.

Five values, in particular, have shaped both the content and the process of this work: transparency, fairness, curiosity, community and learning. Together, they form a practical philosophy for how pricing systems—and increasingly, agent-mediated economies—should evolve.

Transparency as a Design Principle

One of the most consistent failure modes we see in credit-based pricing systems is opacity.

Buyers do not understand what a credit represents. They cannot predict consumption. They cannot map usage to value. And as a result, they distrust the system.

This is not a minor UX issue. It is a structural flaw.

Transparency is not a feature to be layered on after the fact. It is a design constraint. A well-designed credit system should allow a buyer to answer four questions clearly:

• What am I buying?

• How much do I need?

• What drives consumption?

• What value will I receive?

If those answers are not legible, the system will be resisted—regardless of how elegant it may appear internally.

This belief directly shaped how we wrote the book. We have tried to make our assumptions explicit, our models inspectable, and our reasoning traceable. Where there is uncertainty, we say so. Where trade-offs exist, we surface them.

It is also behind The Value Project, an open source set of JSON schema for publishing and sharing value models and pricing models in a machine readable format.

Fairness as Economic Alignment

Fairness is often discussed in moral terms. In pricing, it is also deeply economic.

A pricing system that is perceived as unfair does not scale. It generates friction, increases acquisition costs, and ultimately constrains expansion. Conversely, a system that aligns value between buyer and seller becomes self-reinforcing.

In the context of agent economies, this alignment becomes more complex—but also more important.

Buyers should not be nudged into over-purchasing credits they will never use. Nor should they be penalized by designs that obscure true consumption patterns. These are anti-patterns that may generate short-term revenue but erode long-term trust.

At the same time, agents need to be compensated in proportion to the value they create. Underpricing agentic work is just as destabilizing as overcharging for it.

In writing the book, we have tried to hold both sides of this equation simultaneously. Not as a compromise, but as a requirement for a functioning system.

Curiosity in a Non-Stationary World

We are writing about a landscape that is evolving in real time.

There is no stable “best practice” for pricing agents. There are only emerging patterns, partial frameworks, and a growing set of experiments.

This is where curiosity becomes essential.

Science fiction writer William Gibson’s observation that “the future is here, it is just not evenly distributed” captures the current moment. Elements of the agent economy already exist—in production systems, in edge cases, in internal tooling—but they are fragmented and unevenly understood.

Our goal is not to present a finalized doctrine. It is to offer a set of lenses, models, and design patterns that can evolve as the ecosystem matures.

Curiosity, in this sense, is not just intellectual openness. It is a strategic posture.

Community as a Force Multiplier

We did not write this book in isolation. It is the product of many conversations with people designing, implementing and managing pricing models, with buyers and procurement, and with other experts that we are in regular communication with.

We have invited people to follow along as we write and revise this book, to poke holes in our views and question our assumptions. If you would like to join on this journey please let us know in the comments below.

This approach is closely aligned with the principles of The Value Project, which emphasises shared understanding, open dialogue, and the co-creation of better value systems. The JSON Schema for publishing and sharing value models and pricing models across systems are open source and available on Github.

To extend that philosophy, we are publishing the book under a Creative Commons BY-NC-SA 4.0 license. Readers are free to share, adapt, and build on the work for non-commercial purposes, provided they attribute it appropriately. The full text will available online in a machine readable format for language models to index. We hope someone will even use this to create a small language model and put it on Hugging Face where it will join almost 3 million other models (the world is a lot bigger than just the big frontier models).

We believe this is the right model for a domain that is still being defined. If pricing for the agent economy is going to evolve, it will do so through collective iteration—not closed frameworks.

Learning as an Ongoing Process

Working on this book changed how we think about pricing. It forced us to revise our models, confront edge cases, and articulate ideas more precisely. And we expect that process to continue as people apply, test, and stress these concepts in real-world environments.

In that sense, the book is not an endpoint. It is a contribution to an ongoing conversation.

If we have done this well, the most valuable outcomes will not be the frameworks themselves, but how they are adapted, challenged, and extended by others.

That, ultimately, is the standard we are holding ourselves to: not just to describe the agent economy, but to participate in shaping it—through the values we choose to encode in both our systems and our work.

TL:DR

• Agents are economic workers, not seats; price them on roles, access, inputs, actions, outputs, and outcomes rather than headcount.

• The six agent pricing metrics are: Role (organisational function), Access (availability/retainer), Input (tokens and other raw inputs), Action (internal execution work), Output (tangible deliverables), and Outcome (business results).

• Use two or three metrics per agent (typically Role or Access plus Actions, Outputs, or Outcomes) to cover more of the value surface while keeping pricing legible to buyers.

• Design credits as value units, not cost units: map credits to meaningful actions across Input and Action layers, then tie credit price to economic value via an EVE-style value model; manage credits with pooling, rollover, top-ups, and PayGo.

• Decide explicitly who carries outcome risk (vendor, buyer, or shared) and use Outcome metrics selectively, backed by attribution infrastructure, as you evolve beyond pure Input/Action usage pricing.

Agents are becoming one of the key vectors for AI adoption. Co-pilots and enhancements to conventional functionality remain important, but more and more AI functionality is being bundled into agents. The shift is structural, not cosmetic — and it demands a new vocabulary for pricing.

What Is an AI Agent?

AI agents take a given goal, break it down into actionable steps, utilise external tools and persistent memory to execute those steps, and self-correct to achieve the desired outcome. Increasingly, agents act with other agents to achieve larger goals and coordinate actions and outcomes. They are not software in the traditional sense — they are autonomous workers, with the economics of workers, not tools.

This distinction matters enormously for pricing. A tool is passive; it does what you tell it. An agent is active; it decides, reasons, calls APIs, generates outputs, and adapts. Pricing a passive tool by the seat is defensible. Pricing an active agent by the seat is an error — it misaligns the price metric with the value metric, and eventually the customer notices.

Pricing agents correctly is going to be critical in the agent economy. Michael Mansard and I are working on a book that takes this challenge seriously: Pricing for the Agent Economy: How to Design, Implement, and Scale Credit-Based Pricing in the Age of AI Agents, with a foreword by Tom Nagle and a chapter by Wolfgang Ulaga (INSEAD) on credits beyond the agent context. This post extracts the core of what we are calling the Agent Pricing Metric Taxonomy — the foundational layer of that system.

The Six Metrics Unpacked

Agents are dynamic. They consume resources at the input stage, generate intermediate reasoning and API calls during execution, and produce outputs and outcomes at the end. A pricing architecture that can only meter one point in this chain will systematically misalign price with value. The taxonomy below names all six measurement points — and more importantly, establishes the strategic logic that governs when to use each one.

Role Metric

Pricing based on the organisational function the agent performs. The reference value is the human role the agent replaces or complements — a pricing analyst, a customer success manager, a regulatory reviewer. This establishes baseline value through FTE-replacement logic: the agent is worth at least as much as the fully-loaded cost of the human role it displaces, and potentially far more once positive differentiation value is added.

The Role metric is a starting point, not a ceiling. It anchors the conversation in the customer’s P&L — which is exactly where Tom Nagle’s EVE framework says the pricing conversation should begin. It also makes the “job to be done” legible to buyers, which reduces friction in enterprise sales cycles.

Access Metric

Subscription or retainer fees for guaranteed availability of the agent — the right to call it, use it, and rely on it being operational. The Access metric provides revenue predictability for vendors and budget certainty for buyers. It is the most common existing layer in SaaS, and it persists in the agent economy for good reason: always-on agents have business costs when they go down, and buyers will pay for uptime guarantees.

The Access metric is not, on its own, a complete agent pricing architecture. It captures availability, not value. An agent that sits idle in a subscription costs the same as one that resolves 500 tickets a day. When utilisation diverges sharply across customers, the Access layer alone produces severe value leakage.

Input Metric

Pricing based on inputs into the agent — most visibly, tokens consumed at the prompt stage. The Input metric maps directly to infrastructure cost for API-layer vendors, making it logical at the foundation model and LLM API layer: OpenAI, Anthropic, AWS Bedrock, and their peers all price primarily on tokens because that is their cost unit.

For application-layer agents, however, the Input metric has a critical weakness: it is invisible to business buyers. CFOs and line-of-business leaders do not think in tokens. An Input metric requires translation — and that translation gap is exactly the problem that abstract credits are designed to bridge. When input costs are 50–70% of delivery costs, as they are increasingly for complex agentic workflows, pricing purely on inputs forces a cost-plus logic that competes against the value-based pricing architecture vendors should be building.

Action Metric

Consumption-based pricing for what the agent does during execution — compute cycles, internal reasoning tokens, tool calls, API invocations, database queries. The Action metric is the default in the API economy and captures the variable cost of agentic work more faithfully than a flat subscription.dev

The strategic value of the Action metric is its granularity. Complex multi-step workflows that spawn dozens of sub-agent calls are priced differently from simple single-step executions. This is appropriate: the economic cost of executing a complex legal document review is genuinely higher than a simple form-fill. The challenge is making this legible — and here again, credits serve as the abstraction layer that converts raw action counts into meaningful price signals for business buyers.

Output Metric

Pricing based on what the agent produces: decisions made, reports generated, emails drafted, records updated, artifacts created, cases resolved. The Output metric aligns price to the tangible deliverable rather than the internal mechanics that produced it. It is a more buyer-friendly metric than input or action pricing, because the output is the thing the buyer actually wanted.

Output pricing is currently underused. The Tanso dataset, which captures pricing design choices across 73 products in 18 categories as of June 2026, shows that most agents price on usage (inputs and actions) rather than outputs — even when outputs are clearly definable and measurable. Vendors who move to output pricing before their competitors gain a durable advantage: they align with the customer’s mental model, they build toward outcome pricing without requiring full attribution infrastructure, and they create a more compelling value story.

Outcome Metric

Performance bonuses or penalties tied to measurable business results — revenue influenced, costs removed, risk reduced, decisions improved. The Outcome metric is the ceiling of value capture in the EVE framework: it prices against the economic impact the agent delivers, not against the inputs consumed or the outputs produced.

Outcome pricing is the aspiration. It is also, in mid-2026, largely aspirational. The three conditions that make outcome pricing viable — a clear and agreed outcome definition, demonstrable attribution of the agent’s causal contribution, and sufficient predictability to give both parties cost and revenue confidence — are not yet met for most agents. The attribution problem remains largely unsolved, though causal ML methods are providing a path forward. Michael Mansard, Edward Wong, and I are actively researching this. The implication is not to abandon outcome pricing, but to design for it from day one while pricing at lower layers today.

Why Most Agents Use Two or Three Layers — and How to Choose

No agent should be priced on a single metric alone. A single metric collapses the full dimensionality of agent value into one number — and that number will always be wrong for some customers, some use cases, or some phases of the engagement. The strategic logic of the layer cake is that combinations cover more of the value surface while keeping the pricing architecture legible.

The data confirm this. In June 2026, the dominant market pattern is two-layer pricing, usually combining a base layer (Role or Access) with a consumption layer (Usage or Action). Three-layer designs are emerging among the most sophisticated vendors. Pure single-layer outcome pricing exists but is rare — and where it exists, it is typically in high-attribution, high-value contexts where the causal chain from agent action to business result is defensible.

Here is the strategic logic for each combination, with field examples.

Role + Access: The Retainer Model

The most predictable revenue architecture for always-on agents. The Role layer establishes value reference (this agent replaces or augments a human function at a known cost) and the Access layer converts that reference into a recurring subscription.

Best for: agents where downtime has direct business cost — a 24/7 customer service agent, a compliance monitoring agent, a trading signal agent. The buyer is paying for availability, not just usage, and is willing to pay a premium for that guarantee. This model maps cleanly to enterprise budget cycles and is relatively easy to sell because it mirrors existing SaaS procurement patterns.

The risk: if the agent is underutilised, the buyer feels they are overpaying. Build utilisation reporting into the product to show the buyer what the agent is doing. If utilisation is consistently low, the agent is either underperforming or mispriced — and you need to know which before the renewal conversation.

Role + Actions: The Dominant Model

The most common architecture in mid-2026. The Role layer sets the reference value and frames the conversation (this agent does the work of a junior analyst); the Usage layer captures the variable cost of actual work done — actions taken, tokens consumed, outputs generated.

The appeal of this combination is its clean logic: the buyer understands what they are buying (a functional agent role) and pays in proportion to how much they use it. It aligns cost to activity without requiring the attribution infrastructure that outcome pricing demands. Most enterprise buyers will accept this model if the credit design is transparent.

The risk: if the usage metric is at the wrong abstraction level (raw tokens rather than abstract credits or actions), the buyer disconnects from the pricing and it starts to feel like a tax. Move the usage metric toward activity-level or abstract credits wherever possible.

Role + Outcomes: The Contingency Model

High risk, high reward. The Role layer establishes reference value; the Outcome layer captures upside when the agent delivers. This is the lawyer’s contingency fee structure applied to software.

This combination works when three conditions are met: the outcome is unambiguous (revenue closed, tickets resolved, risks identified), the agent’s causal contribution is attributable, and both parties are sophisticated enough to negotiate the risk allocation. In 2026, this is the structure of choice for high-value, high-confidence domains — legal AI platforms pricing on matters resolved, financial AI pricing on risk-adjusted returns.

Where attribution is strong and the outcome value is large, this combination creates the highest sustainable price ceiling of any two-layer architecture. The vendor captures a share of the value created rather than a fraction of the cost incurred — and that is a fundamentally different economics.

Access + Outcomes: The Floor and Ceiling Model

A structure built for the enterprise CFO and the enterprise Board simultaneously. The Access layer provides the floor — a predictable, budgetable recurring fee that the CFO can defend. The Outcome layer provides the ceiling — a performance component that the Board can point to as evidence of alignment.

This architecture is increasingly common in enterprise AI deals where procurement teams need budget certainty but executive sponsors want to demonstrate ROI. The floor protects vendor revenue; the success fee protects vendor margin. The buyer gets cost certainty plus an aligned incentive structure.

The practical challenge is negotiating the outcome definition and the attribution methodology before the contract is signed. This is where most Access + Outcomes deals slow down. Vendors who have invested in measurement infrastructure and can bring a defensible attribution model to the table close faster and at higher prices.

Actions + Outputs: The Value Chain Model

An underexplored but powerful combination. Pricing on Usage captures the cost of what the agent consumes; pricing on Outputs captures the value of what the agent produces. The ratio of Output price to Usage cost is the economic efficiency signal — and as agents improve over time, that ratio should improve too.dev

This combination is natural for agents where outputs are clearly defined and countable — documents generated, records processed, decisions logged — and where the vendor wants to align price to productivity rather than to infrastructure cost. As models become more efficient and the token cost per output falls, Usage + Output pricing rewards both vendor and buyer: lower input costs, same or higher output value, improved margins.

Actions + Outcomes: The Full Performance Model

The most ambitious pricing architecture currently in the market, and the rarest in 2026. Pricing on Usage creates a floor based on resources consumed; pricing on Outcomes creates a ceiling based on results delivered. The spread between floor and ceiling is where the performance story lives.

This model requires mature attribution infrastructure, significant trust between vendor and buyer, and agents with a proven track record. It is appropriate for Phase 3 deployments — agents that have been running in production for 24+ months, where outcome patterns are stable and attribution is defensible. The few vendors currently operating this model are commanding the highest prices in their categories. They earned that position by investing in measurement and attribution infrastructure long before the contract conversation.

Credits as the Bridge

There is a structural problem at the heart of the Usage layer: the natural unit of consumption — tokens, API calls, compute cycles — is an infrastructure metric, not a value metric. Technical buyers understand tokens. Business buyers do not. And as AI becomes a boardroom conversation, the pricing architecture needs to speak to both audiences simultaneously.

This is the design problem that credits solve.

A credit is a vendor-defined unit that sits between raw infrastructure (tokens, GPU seconds, API calls) and business outcomes (tickets resolved, leads qualified, revenue influenced). Each time an agent performs a priced action, it consumes some number of credits; revenue is realised as those credits are consumed, not simply when a subscription is signed. In this architecture, credit-based pricing becomes the default monetisation pattern of the agent economy: you sell pools of agent capacity (credits) that map to meaningful work done by agents, rather than seats or flat monthly entitlements.

Credits absorb three kinds of variance that make agent pricing difficult:

• Cost variance: agent workflows vary 100x in compute cost between simple and complex executions. A credit system absorbs this variance so the buyer’s spend is predictable even when the underlying infrastructure cost is not.

• Value variance: different actions have different economic value to the buyer. A credit system weights actions by value rather than cost — a decision on a $10M contract consumes more credits than a form validation, because the economic value is higher.

• Time variance: agent workloads are bursty. A credit wallet with rollover and top-up mechanisms smooths the buyer’s experience across the period.

The key design insight — and the one most frequently missed in the market — is that credits must be abstracted from infrastructure cost and anchored to economic value. One credit should not equal one thousand tokens. A credit is a vendor-defined value unit. The price of a credit needs to align with the economic value of consuming that credit, calibrated by segment using an EVE-style value model.

The Tanso June 2026 data make this concrete: only 23 of 73 companies (31%) score 4 or 5 on a credit-native index, and these are overwhelmingly API-layer infrastructure vendors. Most AI application-layer vendors are still in transitional or “credits in name only” designs — they have adopted abstract credits as a label while retaining subscription-seat lifecycle logic underneath. The result is credits that behave exactly like feature quotas, with hard caps, no rollover, no pooling, and no PayGo. This is the most common implementation error in the market today, and it is worth naming explicitly: adopting abstract credits without redesigning the lifecycle core produces credits in name only.

The most credit-native designs in the dataset — Anthropic (Claude API), Snowflake, Databricks, ElevenLabs, Replit, Clay, Windsurf — share a consistent architecture: pooled allocation, soft caps or rollover, Pay as you Go, top-ups, and abstract credits. These designs set the template. They are not coincidentally credit-native; they are credit-native by design, because their authors understood that the credit unit, the lifecycle policy, and the governance layer are a single system.

Who Bears Outcome Risk — The Three Positions

The Risk Question is the most consequential commercial negotiation in agent pricing. It cannot be resolved by pricing mechanics alone — it is a strategic choice that shapes contracts, product investment, and competitive positioning.

Three positions are available:

Vendor Absorbs Risk: Pure Performance Pricing

The vendor is paid only when the agent delivers. This is the highest-customer-appeal structure and, when it works, the highest-margin structure for the vendor. A vendor who can confidently take on performance risk is signalling — credibly — that they believe in their agent’s ability to deliver. That signal is itself a differentiation value driver.

The requirement is attribution confidence. Vendors cannot responsibly absorb outcome risk unless they can measure the agent’s causal contribution to the outcome with enough precision to defend it in a renewal conversation. Without that confidence, pure performance pricing is not value-based pricing — it is a lottery.

Shared Risk: Hybrid Floor + Success Fee

The most common enterprise structure in mid-2026. The vendor receives a base fee (Access layer or Role layer, providing revenue floor) plus a performance component tied to outcomes achieved. This reduces friction for both parties: the vendor has predictable revenue; the buyer has cost certainty; and there is a shared upside that aligns incentives.

The key design decisions in a hybrid model are the floor-to-ceiling ratio (how much of total contract value is base vs. performance) and the outcome definition. These are negotiated, not algorithmic, and the vendor who comes to that negotiation with a quantitative value model — a real EVE built for the customer’s segment — will command better terms.

Customer Bears Risk: Usage-Based

The most common structure overall, because it is the easiest to sell. The customer pays for what the agent consumes, regardless of what it delivers. This is the familiar API economy model. It is easy to operationalise, easy to explain, and easy to budget. It is also the model that leaves the most value on the table for the vendor.dev

Usage-based pricing from a risk perspective means the customer bears all the outcome uncertainty: if the agent underperforms, they have still paid for the tokens. If the agent dramatically overperforms, the vendor captures none of the upside. This is the structural reason why vendors who can move toward shared or vendor-absorbed risk models — even incrementally — tend to capture higher long-run margins.

Role-Based vs. Task-Based Agent Design: The Pricing Dimension

This is a distinction that most product teams think of as an architecture question. It is equally, and perhaps primarily, a pricing and positioning question.

Role-Based Agents

A role-based agent occupies an ongoing organisational function. It is the pricing analyst, the customer success manager, the compliance reviewer. It shows up to work every day, maintains persistent memory of the context it has accumulated, and is evaluated on the performance of the role, not on individual task completion.

The pricing logic follows naturally from the role definition. The reference value is the fully-loaded cost of the human role being replaced or augmented. The Access layer captures ongoing availability. The Role layer captures the function being performed. Expansion economics come from adding agents (scaling headcount) and from upgrading to more capable agents as the vendor improves the underlying model. This is a predictable, recurring revenue architecture that maps cleanly to enterprise budget processes.

The risk of role-based design is that it anchors the conversation in labour cost replacement rather than value creation. A role-based agent priced at 80% of human FTE cost is a compelling efficiency story. A role-based agent priced at 300% of FTE cost — justified by dramatically higher quality, speed, and capability — requires a much more sophisticated EVE conversation. Vendors who design for role replacement often underprice the transformational value they are actually delivering.

Task-Based Agents

A task-based agent executes discrete, bounded jobs. It does not have a persistent organisational identity; it is called when needed and priced per invocation. The economics of a task-based agent are grounded in the economics of the task itself — which may be dramatically different from the FTE cost of the role that would otherwise perform that task.

A human analyst might spend a day preparing a competitive intelligence report at a cost of $500. That report might inform a $5M strategic decision. A task-based agent that produces the same report in 20 minutes, at a direct cost of $15, is not worth $500. It is worth a share of the $5M it helped to protect or create — which is a very different number. Task-based agents can reach deeper into the Outcome layer precisely because the task-to-outcome connection is often more direct and more measurable than the role-to-outcome connection.

The practical implication: vendors who design agents as tasks and price them against task EVE — rather than against role labour cost — have access to a higher price ceiling. But this requires investment in outcome definition and attribution infrastructure, and it requires sales teams comfortable with value-based selling rather than competitive substitution selling.

The design choice between role and task is not permanent. Many successful agent products begin with role-based design (because it is easier to position and sell) and evolve toward task-based pricing as attribution infrastructure matures and the customer’s trust in the agent’s capabilities grows. The Layer Cake provides the architecture for this evolution: start with Role + Access, add Usage credits as volume grows, and layer in Outcome pricing as attribution becomes defensible.

Conclusion

Pricing agents is no longer a peripheral question; it is now one of the core design choices that will determine who actually makes money in the agent economy. The teams that treat pricing as part of agent architecture — not as a billing afterthought — will be the ones that compound learning, capture value, and build defensible positions over the next decade.

From taxonomy to design decisions

The Agent Pricing Metric Taxonomy is useful only insofar as it changes what you do next. Every agent team should be able to answer four concrete questions:

• What is the primary role our agent plays, and how explicit is our Role metric in the pricing story?

• Where do we charge for access, and where do we charge for actions, outputs, or outcomes?

• How will our pricing architecture evolve over the next 24 months as attribution improves?

• Where, precisely, do credits sit in this stack, and what do they mean economically for our buyers?

If you cannot answer these with specificity for your current product and next two releases, you do not yet have a pricing architecture; you have a billing schema.

Actions for product and pricing teams

Three actions follow directly from this taxonomy.

1. Map your agents to the six metrics.
   For each agent, define the Role, Access, Input, Action, Output, and Outcome layers and decide consciously which two or three you will monetize now. This exercise surfaces misalignments quickly: agents priced only on seats with no reference to actions or outcomes, credits that mirror feature quotas, or outcome bonuses grafted onto usage pricing without an attribution model.

2. Design credits as value units, not cost units.
   If you already use credits, pressure-test them against a value model built in Tom Nagle’s EVE framework. If one credit is still “roughly a thousand tokens,” you have an infrastructure metric masquerading as a value metric. Redesign credits so that each unit corresponds to the smallest meaningful action a buyer understands — a case resolved, a decision logged, a document reviewed — and then make the lifecycle (pooling, rollover, top-ups, PayGo) explicit and machine-readable.

3. Decide who carries outcome risk — and why.
   Make your position on outcome risk a strategic choice, not an accident of history. If you stay in pure usage-based pricing, be explicit that the customer carries outcome uncertainty and that you are choosing margin simplicity over upside capture. If you move to shared or vendor-absorbed risk, invest ahead of time in attribution infrastructure and outcome definitions; these are assets, not costs, and they unlock Role + Outcomes, Access + Outcomes, and Actions + Outcomes architectures that your competitors will struggle to imitate.

Build your agent pricing roadmap

The practical way to operationalise this is to treat agent pricing as a roadmap with three horizons.

• Horizon 1 (0–12 months): Stabilise on Role + Access + Actions or Actions + Outputs, with credits abstracting away raw infrastructure and giving buyers predictable spend against clear units of work. Publish machine-readable pricing pages and usage dashboards that make the mapping from credits to actions legible to humans and agents alike.

• Horizon 2 (12–24 months): Add Output layers where deliverables are clear, and begin instrumenting outcomes even if you are not yet pricing on them. Build internal causal models, run A/B experiments, and create the measurement spine that will support future Outcome layers.

• Horizon 3 (24+ months): Introduce Outcome components — initially as success fees or bonuses — in segments where attribution has matured and trust is high. Move selectively into hybrid risk structures, starting with customers who are willing to co-design outcome definitions and share data; this is where the highest sustainable price ceilings live.

None of this is speculative. The most credit-native and outcome-attuned companies in the Tanso dataset — Anthropic, Snowflake, Databricks, ElevenLabs, Replit, Clay, Windsurf — are already operating along this ladder, using credits, pooled allocation, rollover, and Pay as you Go to translate complex agent work into understandable units of value. The agent economy will not converge on a single “right” model, but it will converge on architectures that make value computable, portable, and negotiable.

If you are building or pricing agents today, the invitation is simple: treat the six-layer taxonomy, credits, and risk positions as design primitives, not as optional optimisation. Choose your layers, define your credit unit, decide your risk stance — and then publish those choices so that both humans and agents can read, reason about, and act on them.

This post is part of the series building toward Pricing for the Agent Economy (October 2026), by Steven Forth and Michael Mansard with Wolfgang Ulaga (INSEAD). Tom Nagle is writing the foreword. To follow the build in public, subscribe to Pricing Innovation.

In October, Michael Mansard, Wolfgang Ulaga and I will publish our first book together.

If you want to follow the build in public, leave your name and a way to reach you in the comments.

Pricing for the Agent Economy: How to Design, Implement, and Scale Credit-Based Pricing in the Age of AI Agents

We are fortunate to have Wolfgang Ulaga (INSEAD) contributing a chapter on “Credits Beyond Agents,” and Tom Nagle writing the foreword, grounding this work in the broader tradition of value-based pricing.

This project emerged from several years of collaboration, crystallizing in spring 2026 during a working session in Paris. At the same time, Michael and Wolfgang have been teaching at INSEAD on pricing, subscriptions, and the shift to services—work that now extends directly into the role of AI agents in the wider economy.

Over the past two years, AI—particularly deep learning and generative models—has fundamentally changed three things: what we price, how we price, and how pricing itself is executed. These shifts converge in credit-based pricing.

At its core, credit-based pricing converts access, capacity, and usage into a common unit: credits. Customers purchase credits upfront or on demand, then spend them as actions are triggered or outcomes are produced—guided by a calculator before purchase and a wallet after.

Despite growing adoption, the concept is widely misunderstood.

Some equate credits with tokens—the unit used by model providers—reducing pricing to cost-plus mechanics. Others treat credits as a temporary bridge to outcome-based pricing. The result is a wave of poorly designed systems: credits disconnected from value, unpredictable consumption, and opaque usage patterns.

We take a different view.

Credit-based pricing is not a stopgap—it is emerging as the most effective way to organize, communicate, and operate pricing in the agent economy.

In this world, autonomous and semi-autonomous agents—not human seat holders—become the primary producers and consumers of digital work. Credits fit this model because they can:

• Price heterogeneous actions, capabilities, and access.

• Support granular, high-frequency transactions.

• Map cleanly to both cost and value.

More importantly, they enable adaptive, resilient pricing systems—capable of tracking value and cost at any level of granularity.

Our goal with this book is practical: to provide the foundations and design process required to build credit systems that actually work.

We treat credits not as a pricing tactic, but as a system—one that must be coherent, maintainable, and built from reusable design patterns. The book approaches credits through this systems and pattern language lens.

There is no single way to design a credit system. Our approach is grounded in a set of principles: transparency, fairness, curiosity, community, and continuous learning. These values shape both the book and how we are building it—openly, with input from the community.

Here is our current draft table of contents.

Front Matter

Foreword by Tom Nagle — Connects the book to the larger value-based work.

Preface — How three pricing thinkers — drawing on value-based pricing research, enterprise monetization deployments, and INSEAD executive education — came together to define credit-based pricing for the age of AI.

How to Use This Book — Three reading paths: the Practitioner who needs to act Monday morning, the Executive navigating a seat-to-credit transition, and the Student of Pricing building a rigorous foundation.

Part I — The Structural Shift

Chapter 1: Your Pricing Model Was Built for Humans
The flat-rate subscription — seats, annual contracts, binary churn — was designed for humans operating software. AI agents violate every assumption simultaneously. Salesforce’s mid-course correction from $2-per-conversation to Flex Credits is the opening proof.

Chapter 2: The Agent Economy — A Field Guide
A structured map of the agent stack: four layers, six competitive archetypes (from Domain Oracle to Trust Infrastructure), and the most consequential shift of all — by 2026, buyer agents are screening vendors before humans engage.

Chapter 3: The Long Road to Credit-Based Pricing
From perpetual licenses to SaaS subscriptions to usage-based models — and why credits emerged as the pragmatic middle path that absorbs the 100x variance in agentic workloads while preserving the value alignment that tokens never could.

Part II — Strategic Choices

Chapter 4: Where to Play — Stack Position and Competitive Architecture
The most durable decision you will make in the agent economy is which layer of the stack to occupy. That choice determines which pricing models are available to you and what margins are achievable — and the window for making it consciously is closing.

Chapter 5: How to Define Value in an Agentic World
Nagle’s EVE framework extended for the agent context: six positive value driver categories, the autonomy risk premium as a new negative differentiator, and the conditions under which outcome-based pricing is actually viable (most agents in mid-2026 cannot yet meet them).

Practitioner Interview: Elena Verna — Credit-Based Growth at Lovable
How a credit-native design transformed growth motion, expansion revenue, and the metrics the team now tracks — from the architect who built it.

Chapter 6: Choosing Your Pricing Architecture — The Layer Cake
Four pricing layers — Role, Access, Usage, Outcome — and the strategic logic for combining two or three of them. Credits are the bridge that makes the Usage layer legible. Most importantly: design for Phase 3 economics from Day 1, even if you charge Phase 1 prices today.

Part III — Design

Chapter 7: The Credit Unit — What One Credit Represents
The most consequential design decision in the entire system. Five unit types on the abstraction spectrum — from input-based tokens to outcome-based results — and why anchoring credit weights to customer economic value, not infrastructure cost, is the difference between a pricing system and a billing system.

Chapter 8: Connecting Value and Credits — The Two Dials
Credit-based pricing has exactly two adjustment mechanisms: price per credit and credits per action. Knowing when to turn each dial — and why conflating them destroys customer trust — is the operational core of value-based credit design. Introduces the Value-to-Burn (VtB) ratio as the strategic compass.

Chapter 9: Lifecycle Design — How Credits Behave in Period
The five coupled lifecycle choices — overage policy, rollover, pooling, on-demand credits, and engagement incentives — and the evidence from 73 companies on which combinations build trust and which quietly destroy it. Hard caps without PayGo remain the single most common and most damaging design choice in the dataset.

Chapter 10: Design Patterns from the Field — Analysis of 73 Companies
The first empirical map of credit-based pricing in practice: five coherent design archetypes, co-occurrence rules, structural tensions, and six inferences about where design will move by 2027. The Tanso June 2026 dataset in full.

Practitioner Interview: TBD — Enterprise Credit Transition
The organizational change management, finance, and GTM challenges of the seat-to-credit migration from a large-platform perspective.

Part IV — Operations and Governance

Chapter 11: Credit Pricing Metrics — A New Stack for a New Economy
SaaS Metrics 2.0 was designed for contracted recurring revenue. Credit-based pricing breaks all three foundational assumptions. This chapter provides the replacement: three metric tiers organized by audience, from CCARR and CN-NRR for the board to CWAS and VPG for the pricing team — with a full translation table mapping every Skok Metrics 2.0 concept to its credit-economy equivalent.

Chapter 12: Operationalizing Credit Pricing — From Design to Revenue Engine
Packaging patterns, governance tooling, change management protocols, and GTM alignment — including the sales compensation structures that make or break a credit-based motion. The Tanso anti-pattern audit: score your current design against the five most common implementation errors.

Chapter 13: Protocols, Skills, and APIs — Integration in the Agent Economy
In the agent economy, pricing logic lives in protocols and APIs, not just packaging pages. MCP as commercial infrastructure, Claude Skills as priced capability units, and the critical distinction between a tool call and a value call — the decision that separates firms that capture value from those that leak it.

Chapter 14: Credit Pricing Governance — Trust as a Pricing Lever
Governance is not compliance overhead — it is positive differentiation value. The autonomy risk premium as a quantifiable EVE input, machine-readable pricing as GTM infrastructure, and why the organization that controls the ecosystem credit wallet becomes the platform.

Practitioner Interview: Brandon Hickie at LinkedIn — Pricing Transformation in a Platform Business
How a platform at scale manages the seat-credit hybrid, the data moat as pricing power, and what a pricing leader at a large platform should do differently than a startup.

Part V — Looking Forward

Chapter 15: The Future of Credit-Based Pricing — Outcomes, Agents, and Wallets
Phase 3 is 24–36 months away: outcome attribution becomes practical, agent-to-agent commerce becomes material, cross-vendor credit wallets emerge. Companies designing for Phase 3 today avoid repricing trauma tomorrow. Nagle’s core insight — that value, not cost, should anchor price — becomes more relevant, not less, as the agent economy matures.

Chapter 16: Credits Beyond Agents — How this will affect the rest of the world
(by Wolfgang Ulaga)

The subscription economy had an impact well beyond software with subscription models being introduced for everything from meals, to lighting, to industrial equipment. How will agents and credits impact business in the larger economy?

Back Matter

Appendix A: The Credit Design and Management Process - How to Execute

Appendix B: Credit Pricing Design Pattern Library (18 patterns in Gang-of-Four format: name, context, problem, solution, trade-offs, field examples)

Appendix C: The COMPASS Framework — A Reference Guide (Full documentation of Mansard’s synthesis framework for credit pricing design in agentic AI)

Appendix D: Credit-Based Pricing Glossary (The authoritative taxonomy — from A2A Commerce Readiness Index to Workflow Credit)

Appendix E: How We Used AI in Developing This Book (A transparent account — what agents did well, what required sustained human judgment, and what this means for practitioners using AI in their own pricing design work)