The Revenue Decision Agent: Simulate the Quarter Before You Commit

Hold the starting state fixed and vary the action: +5% versus +7% versus +10%, each rolled forward and compared on bookings, churn, and margin, with the recommended option marked.

A price rise that took a quarter to decide

A global manufacturer with dominant market share planned a significant price increase across its most valuable segment. Sales, product, GTM, supply chain, and marketing were all engaged so every perspective could be accounted for. Each team ran its own analysis of several price scenarios: impact on growth, on churn, on deliverability. The exercise took a full quarter of meetings, analysis, more meetings, and more analysis. Reaching agreement within three months was considered a great outcome. The previous price rise took six, albeit at the height of COVID.

Nothing in that quarter was wasted effort. The teams were doing, by hand and in parallel spreadsheets, exactly what the decision required: imagining alternatives, tracing consequences, and negotiating trade-offs across functions. The problem is that the work took three months and produced answers that were stale before the decision landed.

That's the state of the art for consequential revenue decisions. It's also the gap.

What revenue AI does today

Revenue teams already run on AI. Conversation intelligence transcribes and scores every call. Forecasting tools grade the pipeline and flag deals at risk. Intent platforms score accounts. Clari, Gong, and 6sense built real businesses on this, and the output is useful.

But look at what these tools have in common. Every one of them describes. They tell you the state of the pipeline, the health of a deal, the intent of an account. They answer what is happening and sometimes what happened last time.

The decisions that move revenue don't live there. Should we raise prices 7% in the enterprise segment? Should we redraw territories before the fiscal year starts? Should we shift our ICP toward mid-market? Each question is counterfactual. Each asks what the world would look like under an action nobody has taken yet. A deal score can't answer it, because a score conditions on the past, and a consequential decision changes the system the past was drawn from.

When a scoring tool is wrong, a rep wastes a call. When a pricing decision is wrong, the miss shows up simultaneously in bookings, churn, margin, and the supply plan behind the demand you just created. The blast radius is the reason these decisions take a quarter of meetings.

A world model for revenue

An Enterprise World Model is a live, executable model of how a system operates: its state, and the transitions that carry it from one state to the next. Point that machinery at a revenue engine and the two parts look like this.

A revenue world model holds the state of the go-to-market engine and the transitions that move it, so a pricing decision runs forward as a quarter you can watch, not a debate you have to settle.

State is the current configuration of the revenue operation. Pipeline by stage and segment. Accounts, their health, their contract terms. Rep capacity and territory assignments. Current pricing and discount policy. Signals from the market: competitor moves, demand indicators. Including variables no dashboard carries directly, like the deliverability risk sitting behind a demand spike.

Transitions are the causal functions that describe how the engine responds to action. How a price change moves win rate and churn in each segment. How coverage moves pipeline creation. How a discount policy shift propagates into margin and renewal behaviour. These are learned as mechanisms rather than correlations, which is why they hold for a 7% increase even if the business has only ever tried 3%.

Combine the two and the pricing question stops being a quarter-long negotiation and becomes a simulation you can run. Set today's state, apply the action, propagate the consequences.

The decision agent on top

A decision agent grounded in the revenue world model runs the same loop for every question.

It contextualises: this pipeline, these accounts, this discount policy, today. It simulates: apply the 7% increase and roll the engine forward, producing a causal chain rather than a single revenue number. It cascades: trace the n-th order effects. A 10% price cut may spike demand, but can manufacturing absorb the volume? Is the order surge new revenue or a pull-forward of sales that would have happened anyway? It compares: 5% versus 7% versus 10%, each with its effect on churn, margin, and bookings, each with a confidence range. And it recommends: a plan that is constraint-consistent and auditable, with the decision trace attached.

Analysis that took a quarter of cross-functional meetings compresses into minutes, and every function's concern is inside the same model instead of in a separate spreadsheet.

The constraint check matters as much as the simulation. A revenue decision agent can't promise a discount below a contractual floor, book implementation capacity that doesn't exist, or assign accounts to a territory that was just dissolved. Actions that violate business reality are blocked before they reach a system of record. The blast radius of a wrong recommendation is a rejected plan.

What changes for the CRO

Three things, concretely.

The forecast becomes an experiment you can run. Instead of arguing about whether the number is right, you ask what the number becomes under each scenario you're considering, and you see which lever moves it.

Decisions stop waiting for the analysis cycle. The manufacturer's three-month pricing exercise is the honest cost of counterfactual reasoning done by hand. Done against a world model, the same war-gaming runs on demand, and the meeting starts from simulated consequences instead of competing decks.

And recommendations arrive with their reasoning attached. When the agent proposes holding price in one segment and raising it in another, the decision trace shows why: which accounts, which churn mechanism, which margin effect. You can inspect it, change a constraint, and ask again. It's an input to judgment, not a mandate.

Start with revenue, expand the world

The world model architecture doesn't care that the domain is revenue. State, transitions, and constraints describe a supply chain or a plant as readily as a pipeline. That's the expansion path: the same model that simulates your pricing decision can grow to simulate the supply plan that has to absorb it, which is precisely the cascade question the pricing decision raised in the first place.

Start where decisions carry the most consequence and the payback is quantifiable. For most companies, that’s revenue or operations. Do one well and the next domain gets easier: the same model, the same loop, more of the business.

FAQ

How is this different from Clari or Gong? Those tools describe the revenue engine: they score deals, transcribe calls, and grade pipeline. A world model simulates it. Scoring answers "how healthy is this deal"; simulation answers "what happens to Q4 if we reprice, reassign, or change ICP."

What data does a revenue world model need? CRM and pipeline history, pricing and contract data, and the operational signals behind delivery. Operational discovery infers the causal structure from these traces, and priors learned across other enterprise deployments cover thin or missing history.

Can it handle a decision the business has never taken before? That's the point of causal transitions. Because they describe mechanism rather than history, they hold under interventions that have never occurred, with the model honest about its confidence range where knowledge is thin.

Does this replace RevOps? No. It replaces the quarter of parallel spreadsheet analysis with a shared simulation, and gives RevOps the decision trace behind every recommendation to inspect and challenge.