Tier Design

In traditional SaaS, tiers are often “features + seats.” Agent product tiers also have to package unstable runtime cost into customer-legible capacity and promises.

A good tier should answer more than “which features unlock?” It should answer:

1. How much work can be completed?
2. How hard can that work be?
3. What happens on overage or high-risk tasks?

Four Tier Dimensions

Dimension	Meaning
Capacity	Task volume, token budget, runtime, concurrency, storage, or connector limits
Capability	Default model routing, context length, complex-task handling
Permissions	Tools, connectors, execution environments, team management, audit
Service	SLA, human support, compliance, dedicated deployment, or data region

Feature differences still matter, but if tiers do not control capacity and overage behavior, margin is exposed to a small number of heavy users.

Choosing Capacity Units

Do not expose tokens as the only customer-facing unit. Tokens are useful for internal controls, but not always for procurement.

Common combinations:

Capacity unit	Good fit
Task count	Clear workflows with relatively stable task size
Successful task count	Clear success criteria and outcome-oriented buyers
Budget pool	Enterprise customers sharing capacity across many task types
Runtime / session	Browser, sandbox, or hosted execution cost is meaningful
Tokens	Engineering/API customers who understand technical billing

Many products use a two-layer expression: customers see tasks or budget pools; the system accounts internally with tokens, model routing, and runtime.

Budget And Model Routing

Tiers can bind default models, or they can bind budget only.

Design	Advantage	Risk
Tier binds default model	Cost control and simple explanation	Users feel artificially constrained
Tier binds budget; model selectable	Strong user control, better for complex tasks	Must show how different models consume budget
Automatic routing	Users do not need to understand models	Must be explainable or customers distrust cost changes

A durable design is automatic routing by default, with advanced overrides and a clear explanation that stronger routes consume budget faster.

Capacity Ladder

Tier steps need to feel meaningfully different, or upgrading feels pointless. But if the gap is too large, customers get stuck between tiers. Instead of chasing a fixed multiplier, watch three signals:

• Can customers easily see what more work the next tier enables?
• Does the current tier often approach limits without converting to overage?
• Does the next tier feel like a forced large upgrade for a small increment?

Capacity usually widens with customer maturity: entry tiers prove value, middle tiers cover stable workflows, and higher tiers support harder tasks, more teams, and stronger service commitments.

Overage Behavior

Overage rules need to be visible before they happen. Common strategies:

Strategy	Good fit	Risk
Hard stop	Free, trial, and budget-sensitive customers	Interrupted work hurts experience
Soft degrade	Routine tasks tolerate lower capability	Users may notice quality decline
Ask for confirmation	High-value tasks and enterprise users	Adds friction
Automatic overage billing	Signed hybrid or enterprise contracts	Requires very transparent billing
Upgrade suggestion	Users repeatedly approach limits	Can feel pushy if poorly timed

The worst design is no warning, continued execution, and an end-of-month bill the customer cannot explain.

Example Structure

The following is synthetic, not recommended pricing:

Tier	Main promise	Typical limit	Overage behavior
Free	Try the core workflow	Small task volume, low concurrency, limited tools	Hard stop
Team	Stable daily work	Medium budget, standard routing, shared team capacity	Confirmation or soft degrade
Business	High-intensity team use	Higher budget, more connectors, audit and admin	Explicit overage billing
Enterprise	Contracted capacity and service	Custom budget, permissions, compliance, and SLA	Contract-defined

The point is not the names. Each tier explains capacity, capability, permissions, and overage together.

Naming And Presentation

Tier names should help customers identify themselves, not make them decode your cost structure.

Good presentation:

• Explain capacity with typical monthly work.
• Explain capability with task complexity.
• Explain enterprise differences with team, audit, permissions, and support.
• Explain overage with progress bars, alerts, and bill forecasts.

Avoid:

• Listing model names directly as the pricing page’s main structure.
• Making tokens the only external quota.
• Hiding overage rules in terms of service.
• Showing Enterprise as only “contact us” without saying who it is for.

Cross-section Connections

• Cost budgets: economics/controls-and-roi
• Unit economics: metrics/unit-economics
• Pricing model choice: subscription-vs-usage