Redesign seat-based pricing for the agent era — when one human runs ten agents, per-seat models collapse.
SkillScore82Maintained
Automatic
◆Product Management pack
Last verified 8/14/2026
What it changes
Passed 18 of 22 test cases with the skill, and 14 of 22 without it.
Without skill64%
With skill82%
Checks it passed that the model alone missed
Specifies metric tripwire thresholds that trigger plan repricing.
Specifies an explicit grandfathering decision along with its estimated long-term cost.
Establishes a phased rollout starting with new customers before moving existing customers.
and 3 more in the full report
5 fixed13 passed either way3 still failing1 broke
Pass-rate lift
+18 pp
Tokens
+38%
Agent turns
0%
Response time
+11%
Model gemini-3.6-flashMeasured 8/14/2026v118 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 5
Prompt
Our fintech company provides invoice processing software billed at $80 per finance user monthly. Customers are building automated workflows that process ten times more invoices while trimming seat counts. Costs are around $5/user/month and $0.03 per invoice processed. Our sample customer tiers are:
- Small Business: 2 seats, 300 invoices/mo
- Mid-Market: 10 seats, 4,500 invoices/mo
- Enterprise: 30 seats, 50,000 invoices/mo
Please generate a redesigned monetization plan that shifts away from pure seat billing. Include a diagnostic review of our revenue exposure, selection of a resilient metric evaluated for predictability and neutrality, a tiered platform and work pricing matrix, feature fences including potential workarounds, cannibalization impact calculations for our cohorts at current and expanded usage levels, a staged migration roadmap with grandfathering costs, and key tripwire thresholds for repricing.
What was checked, without and with the skill
Checked
Without skill
With skill
Evaluates invoice processing against whether the metric scales with customer-received value rather than internal server costs.
Passed
Passed
Structures the model into a platform layer for humans/access and a work layer for invoices processed.
Passed
Passed
Specifies metric tripwire thresholds that trigger plan repricing.
Missed
Passed
case-03 · gemini-3.6-flash · 8/14/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md65 linessingle file
Agent Era Pricing Skill
Seat pricing quietly assumed the user was a human who logs in. Agents break the assumption from both sides: your customers need fewer seats (one operator, ten agents), and your product gets more usage than ever. This skill redesigns the model around a value metric that survives non-human users — without torching existing revenue on the way.
What This Skill Produces
A value-metric decision: what you charge for when seats stop proxying value
Agent-tier design: how agent/API usage is packaged, fenced, and priced
Cannibalisation math: what happens to current revenue under the new model, computed on real cohorts
A phased migration plan for existing customers, with the grandfathering decision made explicitly
Required Inputs
Ask for (if not already provided):
Current model: plans, price points, seat definitions, current API/automation pricing if any
The evidence of pressure: seat contraction, API traffic growth, customer asks, competitor moves
Unit economics: cost to serve a seat vs an API call/agent action (rough is fine, labelled)
3-5 representative customer profiles with seat counts and usage (the cannibalisation test set)
Method
Find the value metric that survives agents. Test candidates against three questions: does it scale with the value the customer receives (not your costs)? · is it counted identically whether a human or agent drives it? · can the customer predict their bill? Strong candidates are usually outcomes or work-objects (invoices processed, tickets resolved, campaigns run, records enriched) — not raw API calls (unpredictable, punishes retries) and not seats (dying assumption).
Price the human and the agent differently, deliberately. The durable pattern is a hybrid: a platform/human layer (flat or few-seats — access, admin, support) plus a work layer priced on the value metric, agnostic to who did the work. Decide where agents authenticate: agent traffic on a user's token counted as that user's work, not as a "seat".
Design the fences. What separates tiers now that seats don't: volume bands on the value metric, rate/concurrency limits, SSO/audit/compliance (still human-org fences), model/automation quality tiers. Every fence must be measurable and hard to game — name the gaming vector for each and why it's acceptable.
Run the cannibalisation math on real cohorts. For each customer profile: current annual price vs new-model price at current usage, at 2× automation, at 5×. Sum to a revenue bridge. If the new model loses money on your best cohort, the metric or the bands are wrong — fix the model, don't hide the row.
Phase the migration. New customers first (cleanest signal) → opt-in for existing (with a calculator showing their number) → forced migration only with long notice and a cap ("no more than X% increase in year one"). Grandfathering is a decision with a cost, not a default: state what perpetual legacy plans cost in five years.
Set the tripwires. Which metrics reprice this model: value-metric inflation/deflation, gaming detected, agent share of traffic crossing thresholds. Pricing in the agent era is a program, not a project.
Output Format
Agent-Era Pricing Plan: [product]
Diagnosis: [the seat-erosion evidence, quantified]
Value metric: [chosen metric] — because [the three-question test, answered]. Rejected: [runner-up + why].
Audit whether AI agents can actually use your product — docs, APIs, onboarding, errors, and discoverability, evaluated from a non-human user's perspective. Use when asked if a product is agent-ready, to audit a site or API for AI usability, to prepare for agentic traffic, or when agents keep failing against your product. Produces a scored readiness report with per-surface findings and a prioritised fix list. For optimising a single article for AI citation use aeo-optimizer; for designing the MCP