Two trends are running straight at each other.
Software companies are hiding their prices. Among B2B companies with average contracts under $5k, 60% publish pricing. Above $50k of annual contract value it is 8%, and 62% publish nothing at all, not even a plan list. The direction matters more than the level: transparency is down year on year.
The logic is sound locally. Not publishing preserves optionality, and three in four software companies changed pricing or packaging in the last twelve months. If you reprice that often, a public price page is a liability.
And the buyer is becoming a machine. AI agents already recommend products and are beginning to buy them. They do not buy like people. They prefer transparency, they handle complexity comfortably, and they want documentation a machine can read.
Sit with the inversion. Humans tolerate opacity and hate complexity, which is why "Contact sales" works on a person and a four-dimensional rate card does not. Agents are the exact reverse. An agent will happily parse model tiers, cached input discounts, priority classes and volume breaks. What it cannot do is fill in a form and wait three days for a callback.
What "Contact sales" means to an agent
It means you are not in the consideration set.
Not rejected. Absent. An agent evaluating options builds its comparison from what it can retrieve. If your price is not retrievable, you are not a premium option or an expensive option. You are a missing row.
That is a different failure from the human version. A person who hits a contact form might still convert, so the friction is a cost. An agent that cannot retrieve your price experiences no friction at all. It moves on and returns a recommendation without you in it, and nothing on your side registers the loss. There is no form abandonment to measure.
The uncomfortable part: the segment hiding prices hardest, above $50k ACV at 8% published, is the segment where one missed evaluation is worth the most.
Agent-readable is not the same as public
The usual objection is real. Enterprise pricing is negotiated, bundled, and deal-dependent, and publishing it costs you leverage.
That objection answers a question nobody asked, because a machine-readable rate card is not a price page.
A price page is a marketing artifact: three tiers, some checkmarks, a number designed to anchor. It is not what an agent needs, and it is not what you would build for one. An agent needs three things, and only the first resembles a price page at all.
1. A retrievable rate card
Structured, versioned, queryable. Units, dimensions, tiers, and an explicit definition of what counts as one unit of the thing.
It can sit behind an API key. It can be per-customer. Agents are entirely comfortable with authentication. What they cannot work with is prose that has to be interpreted.
2. An entitlement endpoint
What is this customer allowed to do, how much balance is left, and what does the next call cost?
This is the question a purchasing agent actually has, and no price page answers it. It is also the question an agent operating inside your customer's account needs answered before it spends their money.
If you have entitlements with metered balances, you already hold the answer. The work is exposing it as something the caller can ask rather than something your dashboard renders.
3. A way to transact
A quote, a commitment, a credit top-up. Through an API, not a calendar link.
None of that requires publishing your discount schedule. It requires your pricing to exist as data rather than as a slide and a conversation.
Why this is infrastructure, not marketing
Here is the trap. The reason most companies cannot publish a price is not strategy. It is that they do not have a canonical machine-readable price to publish. The real rate card is spread across a spreadsheet, a CPQ tool, some contract language, and one senior rep's judgement.
You cannot expose to an agent what you do not have internally.
Which makes this the same problem as everything else in usage-based monetization. Rate cards have to be data, versioned and queryable, before any agent-facing work is possible. And once they are, two useful things arrive together:
- You can reprice without a deploy, because a price change is a new version rather than a pull request. This is the same capability that lets a no-code product catalog move pricing out of engineering.
- You can answer an agent, because there is finally something to answer with.
Notice that the optionality argument inverts here. Companies stay opaque to keep the freedom to change prices. If pricing is data you have that freedom anyway: you version the rate card, grandfather existing customers, and expose the current one without committing to it forever. Opacity was a workaround for pricing being hard to change. Fix the second problem and the first one stops paying for itself.
Three things to do this quarter
Make the rate card a queryable object. Not a page, not a spreadsheet. A versioned structure with units, dimensions and tiers, owned by one team. If you cannot answer "what was the price of one unit of X on date Y" with a query, start there.
Expose an entitlement answer. For each customer: what they can use, what is left, what the next call costs. Start internal. Your own support team and your own usage dashboards need it before any agent does, and it is the same endpoint.
Write documentation for a reader that cannot ask a follow-up question. The cheapest of the three and the most neglected. Define your units explicitly. Say what counts as one conversation, one run, one resolution. Publish the conversion between credits and units and keep it stable. Every ambiguity you leave in prose is a place an agent guesses wrong, and where a person would have emailed you, an agent just picks somebody else.
All three live at the same place: the API surface the agent is already talking to. Which is convenient, because that is also where the meter and the entitlement check sit.
Transparency stopped being a marketing posture. It is becoming an interface.
