Quick answerBefore deciding how to charge for a new AI agent capability, answer the more fundamental question of whether to charge for it at all: bundle it free into the core product when it primarily increases retention and adoption of what customers already pay for, and sell it as a distinct paid add-on when it creates standalone value a meaningful subset of customers would pay for on its own, carries a materially different cost structure than the core product, or is being built to serve a narrower segment than your whole base. Usage metering and tiering only matter once this upstream decision is made.
Why this has to come before the pricing mechanics
It is easy to jump straight to "how do we price this," pulling in usage-based metering like How to Price an AI Agent Feature: Usage-Based, Seat-Based, or Flat? or an enterprise-versus-self-serve split like How Should Enterprise Contract Pricing Differ From Self-Serve Pricing for an AI Agent Feature. Both of those posts assume the decision to charge has already been made. The question here is the one upstream of both: should this capability generate its own line of revenue at all, or does it earn its keep by making the product you already sell stickier and more valuable.
Signal 1: does it primarily retain, or does it primarily create new value
If the capability mainly reduces churn or increases usage of a product customers are already paying for (a better search experience inside an existing tool, a quality-of-life automation), bundling it free usually beats monetizing it directly, since the revenue impact shows up in retention and expansion of the core plan rather than a new line item, and a paywall on something that mainly protects existing revenue tends to suppress the adoption that makes it valuable in the first place. If it creates a genuinely new, standalone job to be done that a meaningful segment of customers would pay for even without needing anything else you sell, that is a signal it can support its own price.
Signal 2: does it carry a materially different cost structure
A capability with a cost profile similar to your core product (mostly fixed engineering cost, low marginal cost per use) is easy to bundle without breaking your unit economics. A capability with meaningfully higher marginal cost per use, heavier inference load, more expensive tool calls, or higher support burden, is much riskier to bundle free, since heavy users of the new capability will erode margin on customers who barely touch it. This is where usage metering and cost-basis thinking becomes directly relevant, but only after this bundling decision has already leaned toward "distinct offering."
From the team
We build production AI systems for startups.
LLM pipelines, RAG, and agent workflows that hold up under real traffic — not just in the demo.
Signal 3: does it serve everyone, or a narrower segment
A capability nearly every customer benefits from is a strong candidate for bundling, since a paywall just creates adoption friction across your whole base for something almost everyone would use anyway. A capability that serves a narrower segment (a compliance feature only regulated customers need, an advanced workflow only power users touch) is a stronger candidate for a paid add-on, since bundling it free means the whole base subsidizes a feature only some of them value, without gaining broad adoption in return.
Revisit the decision, do not treat it as permanent
A capability launched as a free bundle to drive adoption can reasonably move to paid once usage patterns and cost data are clear, and one launched as a paid add-on can move into the core bundle once it proves out as a retention driver rather than a standalone revenue source. Treat the initial bundle-or-add-on call as a hypothesis to revisit with real usage data, not a permanent packaging decision made once at launch, the same way Pricing an AI Agent Feature by the Labor Hours It Saves, Not the Capability It Adds argues for anchoring a price to real measured value rather than a launch-day guess.
FAQ
What if we are not sure which signal applies? Default to bundling for an initial launch if the cost structure is close to your core product's, since it is far easier to move a free feature behind a paywall later, once you have real usage data, than to walk back a paywall that suppressed adoption from the start.
Does this decision affect how we tier the feature later? Yes, it determines whether tiering questions apply at all; a bundled feature typically becomes a tier-differentiator (available on higher plans) rather than a separately metered add-on, while a paid add-on usually gets its own usage-based or seat-based pricing.
Who should own this decision, product or finance? Both need to weigh in: product owns the retention and adoption signal, and finance owns the cost-structure signal, and the decision is weakest when made by only one side without the other's data.