/Catalogue/Prompt/mohitagw15856/mohitagw15856-pm-claude-skills-agent-era-pricing

Origin: github

agent-era-pricing

Redesign seat-based pricing for the agent era — when one human runs ten agents, per-seat models collapse. Use when agents are eroding seat counts, when asked to migrate to usage- or outcome-based pricing, to price an agent/API tier, or to defend revenue as customers automate their own usage. Produces a pricing migration plan: the new value metric, fences, agent-tier design, cannibalisation math, and a phased migration for existing customers. For general pricing and packaging strategy use pricing-strategy.

by mohitagw15856 · updated 3h ago · imported from GitHub

Installs0+0/7d
Security score75/100
Retention 14d0%
GitHub stars1.4K

Skill logic

Execution graph
User message
Prompt rewrites behaviour
Response

SKILL.md

View on GitHub ↗

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

  1. 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).
  2. 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".
  3. 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.
  4. 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.
  5. 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.
  6. 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].

The model

LayerWhat's includedPriced onTiers/bands
Platform (humans)
Work (human or agent)

Fences: [fence → what it separates → gaming vector → why acceptable]

Cannibalisation bridge

CohortTodayNew @ current usageNew @ 2× automationΔ

Migration: [phase → who → when → the cap/grandfather decision, stated] Tripwires: [metric → threshold → action]

Quality Checks

  • The value metric passes all three tests (customer value · human/agent-agnostic · predictable)
  • Cannibalisation is computed on the provided cohorts, not asserted — assumptions labelled
  • Every fence names its gaming vector
  • The migration includes an explicit grandfathering decision with its long-run cost
  • Agent authentication/attribution is specified — whose usage is whose bill

Anti-Patterns

  • Do not price raw API calls as the value metric — unpredictable bills punish exactly the automation you want to encourage
  • Do not bolt an "agent seat" onto seat pricing — an agent is not a discount human; the assumption is what broke
  • Do not present only the happy cohort — the bridge shows the losers or it isn't math
  • Do not force-migrate loyal customers without a year-one cap — churn from pricing anger costs more than the uplift
  • Do not skip tripwires — a static price in a shifting usage regime is a slow leak in one direction or the other

Discussion

No comments yet — start the thread.

Sign in to join the discussion.

/More from mohitagw15856/pm-claude-skills

mohitagw15856· 3h agoSandbox
agent-readiness-audit

Prompts · HTML · v0.1.0

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 server itself use mcp-server-spec.

#agent-skills#agents#ai-agents

0 1.4K
mohitagw15856· 3h agoSandbox
agm-in-a-box

Prompts · HTML · v0.1.0

Run a club, PTA, or association AGM that finishes on time and holds up later — the notice and agenda done right, a quorum plan, minutes that capture decisions not conversations, elections without awkwardness, and the follow-up that makes decisions real. Use when a volunteer says 'I have to run the AGM', 'what goes in the agenda', 'nobody comes to our meetings', or 'our elections are a mess'. Produces the notice, agenda, chair's script, minutes template, and quorum rescue plan.

#agent-skills#agents#ai-agents

0 1.4K
mohitagw15856· 3h agoSandbox
ai-eval-plan

Prompts · HTML · v0.1.0

Design an evaluation plan for an LLM or AI feature before shipping it. Use when asked how to evaluate a prompt/model/agent, set up an eval harness, define quality metrics for an AI feature, or build a regression gate. Produces an eval plan — task definition, datasets, metrics & rubrics, baselines, automated + human evals, a pass bar, and a regression gate.

#agent-skills#agents#ai-agents

0 1.4K
mohitagw15856· 3h agoSandbox
ai-feature-prd

Prompts · HTML · v0.1.0

Write a PRD for an AI-powered feature, covering the things normal PRDs miss. Use when asked to spec an AI/LLM feature, write a PRD for a feature that uses a model, or plan an AI capability (assistant, summarizer, generator, classifier). Produces an AI feature PRD — problem & UX of uncertainty, model approach, eval criteria, guardrails, fallback behaviour, the data flywheel, and cost/latency budget.

#agent-skills#agents#ai-agents

0 1.4K