The Deployment-Size Trap

Per-user pricing reads like the simplest line on the vendor slide. Rate times people. Forty dollars a user, fifty users, two thousand a month. The trap is in the second number. Which people? When an AI agent touches more than one tool in your stack, the population that sets your bill is not the team you piloted with. It is the largest tool the agent compresses, and our engine prices it exactly that way on purpose.

How the engine sizes a per-user agent

When we compute the cost of a per-user agent against a stack, we do not ask you how many seats you intend to buy. We look at every tool the agent actually compresses, find the one with the most active seats, and price the agent across that count:

const activeSeatsOnTargetedTools = agent.impacts
  .filter((impact) => impact.compressionPct > 0)
  .map((impact) => tools.find(...)?.activeSeats ?? 0)
  .filter((n) => n > 0);
const deploymentSize = Math.max(...activeSeatsOnTargetedTools);

The logic is that a per-user agent serving a workflow serves everyone who lives in that workflow. If the agent compresses your data-analytics stack, the team that deploys it is as big as the biggest analytics tool's user base, not the smallest. Above the vendor's enterprise-volume threshold, the engine switches to the discounted enterprise rate, but the seat count is still the maximum across targeted tools. The full engine walkthrough is in how we calculate seat compression.

Notice the filter on the first line: compressionPct > 0. That filter is not decoration. It is the fix for a bug that produced one of the ugliest numbers this product ever showed a user.

The bug that named the trap

Early on, our catalog carried adjacency rows: an agent would list a tool it sat near but did not actually deploy against, with a compression of zero, as documentation. An HR sourcing agent called Findem was adjacent to Workday. Workday was in a demo stack at 500 seats. The old cost code counted every targeted tool's user base when sizing the deployment, including the zero-compression Workday row. So Findem got priced as if all 500 Workday employees had deployed it. The result was a phantom $2.4 million loss verdict, and a recommendation to skip an agent over economics that existed only as an artifact of counting the wrong seats.

Workday was never a tool Findem compressed. It was a tool Findem was filed next to. Counting its 500-seat user base as Findem's deployment inflated the agent's cost by the entire population of an unrelated system. The fix was the filter above: only tools the agent genuinely compresses (compression above zero) enter the deployment-seat pool. Adjacency rows document the relationship without ever touching the bill.

For a CFO the lesson generalizes past our demo. When a vendor quotes per-user pricing, the seats that matter are the ones where the agent does real work. But the ones where it does the most work, on the biggest tool, are the ones that set your number.

Worked example: buying an analytics agent for the wrong seat count

Take an enterprise with 20,000 employees. Its business-intelligence stack has two tools that overlap in what an agentic-analytics product can do:

• Tableau: 600 active seats at $75 per seat per month
• Power BI: 5,000 active seats at $14 per seat per month

You want ThoughtSpot Spotter, the agentic-analytics layer, because your 600 Tableau creators are expensive and Spotter can answer a chunk of their ad-hoc questions in natural language. Spotter compresses Tableau at 50% and Power BI at 35%. Its per-user rate is $25, dropping to $20 above the 100-seat enterprise threshold.

Here is the pilot math a procurement team runs first. Scope Spotter to the 600 Tableau users, pay the enterprise rate of $20, and the cost is 600 x $20 x 12, or $144,000 a year. Against $270,000 of theoretical Tableau compression (300 seats at $75 for twelve months), that pencils to a positive $126,000. Clean deal. Sign it.

Now here is what the engine returns, because Spotter does not only compress Tableau. It compresses Power BI too, and Power BI has 5,000 active seats. The deployment size is the maximum across both, which is 5,000. The honest cost is 5,000 x $20 x 12, or $1,200,000 a year.

The compression side does grow, because Power BI now contributes:

• Tableau: 300 seats compressed at $75, $270,000 a year
• Power BI: 1,750 seats compressed at $14, $294,000 a year
• Gross compression: $564,000 a year

But $564,000 of compression against $1,200,000 of agent cost is a net of negative $636,000. The same agent that looked like a $126,000 winner scoped to Tableau is a $636,000 loser once you price it across the tool it also touches. Nothing about the agent changed. The seat count that pays for it did.

Pilots on the small tool do not stay small

The reason this trap catches good finance teams is that the pilot really does cost $144,000. You can genuinely run Spotter with your 600 Tableau users for a quarter and see a clean number. The problem arrives at rollout. The value case for an agentic-analytics tool is that it serves self-service BI across the company, and the company's self-service BI lives in Power BI at 5,000 seats. The moment the deployment follows the value case, the seat count follows Power BI, and the bill follows the seat count. A per-user agent that touches a cheap, widely-deployed tool gets priced across that tool's entire population the day it stops being a pilot.

This is the opposite failure from the flat-fee agents, where the risk is paying a big fixed number at small scale. Per-user agents have linear unit economics, so there is no "unlock at N seats" threshold to wait for. The unit math is either good or bad at every scale, and for a per-user agent that touches a large cheap tool, the math is usually bad. We keep the flat-fee versus per-user distinction visible on every agent for exactly this reason.

What the CFO asks in the room

Three questions turn the trap into a term sheet you can defend.

Which population actually uses this? Make the vendor name the deploying team and put the seat count in the contract. If they quote per-user, the count is the whole negotiation.

What is the biggest tool this agent touches? List every tool the agent compresses and find the one with the most seats. That is the number your per-user price multiplies by if the deployment ever matches the value case. If the biggest tool is cheap and broad (Power BI, a collaboration suite, a low-cost documentation tool), a per-user agent priced across it rarely clears.

Would a flat-fee competitor be cheaper at my real deployment size? At 5,000 seats and $20 a user, Spotter costs $1.2 million. A flat-fee analytics agent at a fixed monthly rate might deliver the same compression for a fraction of that, because its bill does not scale with the biggest tool in the stack. Run both through the same engine before you decide the per-user option is the cheap one.

The questions to ask an AI agent vendor demo covers the rest of the room, and why deploy realization is 0.4, not 1.0 covers what the compression side actually returns in year one. But the deployment-size question is the one that decides whether a per-user quote is the bargain it looks like or the trap it usually is. The biggest tool sets the bill. Ask which population deploys it before you sign anything with a per-user line.