| name | agent-labor-pricing-function |
| description | Design a pricing/packaging function for variable-cost agent labor: pick a pricing model (per-seat, usage/metered, credits/premium-requests, hybrid, outcome-based), align a value metric to delivered value that the buyer can predict, build a cost floor from real unit economics, and add guardrails (spend caps, budget preview, transparent metering) that prevent bill shock. Use when unblocking Port Daddy's Phase 2 pricing function, packaging a new agent-labor feature or tier, reviewing a draft plan against Cursor/Copilot pricing-trust incidents, or deciding what a buyer should be billed per task. NOT for implementing the billing/invoicing/payment system (use webapp-paywall-implementation), for real-time cost accrual telemetry during execution (use cost-accrual-tracker), or for runtime budget enforcement mid-DAG (use cost-optimizer). |
| license | Apache-2.0 |
| allowed-tools | Read,Write,Edit,Bash,Grep,Glob |
| metadata | {"category":"Agent & Orchestration","tags":["pricing","unit-economics","agent-labor","bill-shock","guardrails"],"provenance":{"kind":"first-party","owners":["port-daddy"]},"pairs-with":[{"skill":"mechanism-design-for-agent-labor","reason":"Once a pricing model is chosen, bond/escrow/settlement mechanics price marketplace-traded agent labor."},{"skill":"cost-accrual-tracker","reason":"Real-time accrual telemetry supplies the actual unit-cost numbers this skill's cost floor depends on."},{"skill":"cost-optimizer","reason":"Runtime budget enforcement (downgrade/skip/stop) is how the spend-cap guardrail gets enforced during execution."},{"skill":"agentic-coding-product-research","reason":"Buyer persona and trust-threshold research grounds the value metric and guardrail choices before pricing."}],"io-contract":{"kind":"deliverable","consumes":["[Truncated]","[Truncated]"],"produces":["[Truncated]","[Truncated]"]}} |
Agent Labor Pricing Function
Design a pricing function for agent labor that never sells below cost and never surprises the buyer.
Use This For
- Unblocking a stalled pricing lane for an agentic dev-tools product (e.g. Port Daddy Phase 2, idle 85+ days).
- Choosing between per-seat, metered, credits/premium-requests, hybrid, and outcome-based models for a new agent-labor feature.
- Designing a value metric that scales with delivered value but stays predictable to the buyer before they run anything.
- Building a cost floor from real unit economics (model token cost + tool/compute + overhead) before any price is set.
- Stress-testing a draft plan against buyer personas (solo founder, staff engineer, enterprise admin) for both bill-shock risk and margin erosion.
Do Not Use This For
- Implementing the actual billing, invoicing, or payment-processor integration.
- Live per-request cost telemetry during a running DAG (that is accrual tracking, not pricing design).
- Runtime spend enforcement inside an execution loop (that is budget/cost optimization, not the pricing function itself).
Pricing Design Loop
flowchart TD
A[Identify buyer + candidate value metrics] --> B[Match value metric to a pricing model]
B --> C[Build unit-cost floor from real usage]
C --> D[Draft price points per tier]
D --> E[Attach guardrails: spend cap, preview, receipt]
E --> F[Stress-test against buyer personas]
F --> G{Negative margin or\nhigh bill-shock risk?}
G -->|Yes| D
G -->|No| H[Ship pricing decision brief]
- Name the buyer for each tier (solo founder, staff engineer, enterprise admin) and list candidate value metrics each buyer already tracks — seats, completed tasks, resolved tickets, merged PRs — before considering raw infra metrics like tokens or tool calls.
- Match the value metric to a model using
references/pricing-model-decision-guide.md: per-seat when usage is roughly uniform per buyer, metered/credits when usage varies widely, hybrid when a seat floor plus overage protects margin without full metering exposure, outcome-based only when the outcome is verifiable and atomic.
- Build the unit-cost floor from
references/unit-economics-and-guardrails.md: blended model token cost across every call in the task, tool/compute cost, and amortized overhead. This floor is a price you must clear, not a target.
- Draft price points per tier: base price, included units, and (for anything but pure per-seat) an explicit overage rate. An included allotment with no overage rate is an unbounded cost commitment, not a feature.
- Attach guardrails before launch, not after a bill-shock incident: a hard spend cap, a budget preview shown before the buyer commits, a per-task cost estimate, and transparent line-item metering after the fact.
