Quick answerWhen you're adding an AI agent capability to a product that already sells on a per-seat basis, the packaging decision is separate from the free-vs-paid decision: even once you've decided to charge for it, you still have to choose whether it's a per-seat surcharge (every seat that wants it pays more), a per-seat-tier gate (only seats on a higher plan get it, no incremental charge), or a usage overlay sold independently of seat count (since AI usage doesn't scale linearly with headcount the way per-seat features usually do). Default to a usage overlay layered on top of the seat price when the capability's cost scales with volume of use rather than number of users, because forcing a volume-driven cost into a flat per-seat surcharge either underprices heavy users or overprices light ones.
Why this is a distinct question from "free or paid"
Deciding whether a new AI agent capability belongs free in the core product or as a paid add-on answers whether to charge at all. This question starts after that decision is made in favor of charging, and it's specifically about the packaging mechanics inside a plan structure that already exists and that customers already understand. Get this wrong even after correctly deciding to charge, and you either confuse existing per-seat customers about what their existing seats already include, or you build a parallel pricing system that conflicts with the one sales and billing already run on.
Match the pricing mechanic to the cost driver, not the org chart
Per-seat pricing works because seat count is a reasonable proxy for value received in the core product — more people using the tool, more value. AI agent capabilities frequently break that proxy: a five-person team running the AI agent constantly can generate far more underlying compute cost than a fifty-person team using it occasionally. If you bolt a flat per-seat surcharge onto the capability anyway, you'll either price out your heaviest, most bought-in users or leave money on the table with light users who'd happily pay less for less use. A usage overlay — a metered add-on billed independently of seat count, but still sold and provisioned through the same per-seat account — keeps the underlying pricing logic honest without forcing customers into an entirely separate contract.
Where tier-gating still makes sense
Tier-gating (the capability is included at no extra charge, but only on plans above a certain tier) works better than a surcharge when the capability functions more as a retention and upgrade lever than as a standalone revenue line — similar to how enterprise pricing diverges from self-serve pricing by bundling more into a negotiated package rather than itemizing every feature. Use tier-gating when you want the AI capability to pull mid-tier customers up to your top tier, and use a metered add-on when the capability is valuable enough on its own that customers on any tier would pay for it independently.
Don't let this quietly become a renewal-time surprise
However you package it, the terms need to survive contact with your existing renewal cycle. If per-seat customers are mid-contract when you launch the add-on, decide up front whether it's available to add mid-term or only at renewal, and make sure the answer doesn't contradict what you'd otherwise negotiate in a multi-year contract renewal repriced after the model landscape shifts. A capability that shows up as an unannounced line item on a renewal invoice creates more account friction than the revenue is worth.
FAQ
Should every seat on an account get access, or can it be per-seat opt-in? Per-seat opt-in usually works better for a new capability, since it lets you charge based on actual adoption rather than assuming every seat wants it, and it gives you real usage data before you decide whether to fold it into the base plan later.
What if the capability makes existing seats more valuable without direct usage-based costs? Then tier-gating is the better fit than a surcharge — you're selling access to a capability, not metering consumption of it, so pricing it like a metered add-on would create billing complexity with no matching cost justification.
How do we avoid this looking like a bait-and-switch to existing customers? Communicate the add-on as new functionality being introduced, not as something being carved out of what they already had. If any part of the new capability overlaps with something previously included free, grandfather existing customers into continued free access rather than retroactively gating it.